7 reasons not to use Scrum
Scrum is not fit for all
Some see Scrum as solution for all problems. Many have jumped on the Scrum bandwagon. However Scrum isn’t suited for every environment. Here are 7 reasons why Scrum might not be suited for you.
1. Your environment isn’t complex
Here is the definition of Scrum:
“A framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value.” — Scrum Guide 2017 by Ken Schwaber and Jeff Sutherland
In a complex environment you will not be able to predict the not so near future. Teams change, technologies change, requirements change, the market changes. It is hard enough to plan a Sprint. You probably have an idea what will be important to work on within two or three Sprints. This is why in complex environments you wish to take small steps and then inspect and adapt. The latest Increment and latest insights on what will bring the highest value next will determine the goal and plan of the next Sprint.
Do you know what will happen in the coming months? Is your environment predictable? Then you are not working in a complex environment. This means that Scrum is not for you.
2. The environment of the Scrum Team doesn’t accept the consequences of empiricism
OK, your environment may be complex. But is your organisation more concerned over sticking to the plan instead of adapting the plan when new things come to light? Does it see newly discovered complexities as a ‘risk’ instead of ‘valuable learning’?
Two situations come to mind:
- Stakeholders don’t accept changes to the Sprint Backlog, regardless if these changes will increase the chances to reach the Sprint Goal;
- Stakeholders don’t accept that the things you learned during a Sprint will impact the work for the next Sprint.
If you are impeded by your stakeholders to work in an empirical way and if there’s no chance that this will change in the future: don’t try Scrum. It will only hurt you in the end.
3. There is no way to deliver a potentially releasable Increment of “Done” product at the end of a Sprint
“The heart of Scrum is a Sprint, a time-box of one month or less during which a “Done”, useable, and potentially releasable product Increment is created. “ — Scrum Guide 2017 by Ken Schwaber and Jeff Sutherland
If there’s no way to deliver a useable and potentially releasable product Increment in a month or less you have nothing to inspect. This means that there’s no way you can adapt your Product Backlog based on the Increment. With that it makes no sense to Scrum.
Having said this: many have claimed that they weren’t able to deliver a working product Increment, especially in the first Sprints. Often these people need to radically change their way of thinking. I am quite sure that more often than not there IS a way to create a working Increment, however small it may be.
4. It’s impossible to let the teams self-organise
“Scrum Teams are self-organizing and cross-functional. Self-organizing teams choose how best to accomplish their work, rather than being directed by others outside the team.” — Scrum Guide 2017 by Ken Schwaber and Jeff Sutherland
If the organisation doesn’t allow teams to determine how they can best do their work then Scrum is not for you. Scrum is not intended to have teams receiving instructions on when to do what.
There’s another thing to consider too: if teams aren’t enabled to work together towards a Sprint Goal — for example because they are working/sitting in silos and don’t have the technical means to work together — then you also can’t possibly have a self-organising team.
Teams should be empowered to decide how to reach the Sprint Goal and should be enabled to closely work together.
5. The Scrum Master isn’t allowed to help the organisation to change
“The Scrum Master serves the organization in several ways, including […] Causing change that increases the productivity of the Scrum Team” — Scrum Guide 2017 by Ken Schwaber and Jeff Sutherland
One of the key aspects of Scrum is that teams can continuously improve their way of working together. Often these improvements can only be achieved by changing things that come from outside the team, like:
- Procedures that hold a Scrum Team back;
- Behaviour from people outside the Scrum Team that have a negative impact on the team;
- Technical issues that could improve the team’s performance.
When a Scrum Master — or anyone else of the Scrum Team — can’t or isn’t allowed to help realise these changes, then Scrum is not for you.
6. The Scrum Team can’t freely embrace the Scrum Values
“When the values of commitment, courage, focus, openness and respect are embodied and lived by the Scrum Team, the Scrum pillars of transparency, inspection, and adaptation come to life and build trust for everyone.” — Scrum Guide 2017 by Ken Schwaber and Jeff Sutherland
There are many ways how not embracing the Scrum Values can negatively impact the team. Here are some examples:
- People can’t commit to the goals of the Scrum Team because they are not allowed to focus on the Sprint Backlog;
- The Development Team is punished for having the courage to bring forward impediments that hinder the team;
- Individuals are not welcomed to be open about their challenges to finalise the items on the Sprint Backlog;
- The Scrum Team doesn’t get the respect that they are capable of doing their job.
Scrum Teams should (be able to) embrace the Scrum Values. Without it it’s impossible to have a well functioning team.
7. Stakeholders will never join your Sprint Reviews
During the Sprint Review, the Scrum Team and stakeholders collaborate about what was done in the Sprint. — Scrum Guide 2017 by Ken Schwaber and Jeff Sutherland
It is essential to have stakeholders at the Sprint Review. They are the people that can give valuable feedback on what you have done during the Sprint and they will be providing ideas on what to do next. This moment of inspection and adaptation is essential in a complex environment, where Scrum shines.
If you are in a situation where you never have stakeholders at the Sprint Review, what is the point of having these events? And if a Sprint Review is pointless, what’s the point of doing Scrum?
“Scrum is a framework for developing, delivering, and sustaining complex products.” — Scrum Guide 2017 by Ken Schwaber and Jeff Sutherland
If this is not your situation — if your environment isn’t complex — , then Scrum is not your framework of choice.
Also: Scrum has a set of roles, artifacts, events and rules. They are all required if you wish to “Scrum”. Scrum can be disruptive for your organisation. It introduces a very different way of working. If you are willing and able to address the concerns mentioned in this article, then you will slowly but surely notice how Scrum helps you to succeed. However, if you are not committed to address this you are better off without Scrum.