As your environment isn’t suited for it
I love Scrum. This framework offers a solution to deliver value in small steps. It also comes with endless possibilities. Empiricism is the beating heart of Scrum. With it, Scrum is brilliant in helping teams deliver value while tackling uncertainty.
Scrum is popular. At the same time, many teams and organisations struggle with it. They do their best to fit Scrum into their product environment, ticking all the boxes. They take Scrum seriously. They won’t let go off it even though they are not able to get the benefit out of it they expect.
The inconvenient truth is that many teams are better off without Scrum. Scrum is not ideal for them.
A framework for complex product environments
Thing is, Scrum is a framework for specific environments:
“Scrum (n): A framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value.” — Scrum Guide 2017
All rules, roles, events and artifacts exist to deliver products of the highest value in a complex product environment. This is why the Scrum Guide says that it only works in its entirety. If you drop aspects like the Sprint Review, Daily Scrum or Sprint Goal, you remove a spoke from the wheel of Scrum.
Misuse of Scrum
Teams and organisations misuse Scrum in all kinds of ways. Often they do this unintentionally. Here are a few examples:
Some teams use Scrum to deliver small increments. The Sprint Review is to inform stakeholders about their progress on their planning. They don’t use the Sprint Review to inspect the Increment and adapt accordingly.
There are teams that are part of a SAFe Agile Release Train. or them, it is ok to revisit part of their assumptions on a product, but major overhauls would disrupt the whole train. They can’t allow fully embracing empiricism.
Other teams know exactly what they need to do for a product, even several Sprints in advance. They don’t need to revisit their assumptions.
Then some teams have to meet velocity targets. These teams don’t have the luxury to have the Sprint Goal as the North Star of the Sprint. They are pre-occupied with meeting their targets.
What these teams have in common is that they don’t use Scrum at its fullest. They partially or totally ignore empiricism. Some teams don’t need it and other teams can’t commit to going all-in on empiricism. But without empiricism, they don’t truly use Scrum.
Working with Scrum in these examples is like using a Lamborghini to buy groceries or mountain shoes to go rock climbing. You can do it, but there are better options.
Where Scrum doesn’t work
Scrums purpose is to create products of the highest value in a complex product environment. This is its sweet-spot. When your environment doesn’t meet these criteria, Scrum loses its power. The trick is to recognize when this is the case for you. This is far from easy. Especially when Scrum has benefits for teams struggling with delivering products of value. Scrum can function as ‘Agile training wheels’. For example, it can help you:
Learning to work as a cross-functional unit;
Embracing the concept of self-organisation;
Breaking work into small chunks;
Working in a cadence.
But in a rather predictable environment, you will hit a glass ceiling at some point. The Daily Scrum and the Sprint Review will not bring the expected value. You don’t need to verify if you are still on track or if your Increment meets expectations. They will become obnoxious mandatory exercises. You don’t have to adjust course all the time, don’t have to verify if what you built meets the expectations. You have the events ‘because Scrum says so’.
Scrum isn’t intended to be Agile training wheels. It is deceptively hard to master and disruptive for your organisation. But Scrum is also not for every environment.
Despite its enormous popularity, Scrum isn’t everybody’s friend.
Note that there’s another situation where Scrum is suboptimal. The product environment is complex, but no-one wishes to accept the consequences of complexity. People still wish to be able to plan beyond a Sprint based on assumptions rather than on what they know. The wish to make promises to stakeholders beyond one Sprint.
It’s important to help the organisation understand the nature of their environment. This includes accepting the consequences of embracing uncertainty. But there’s a limit to that. If people don’t want to buy into it, it is more helpful to offer them an alternative that is less disruptive for them. Will it be as effective as Scrum? Most probably not. But keep in mind that Scrum only works when teams can embrace it.
Alternatives to Scrum
There are many other approaches to develop iteratively and incrementally. Here are some suggestions as great alternatives for Scrum:
Heart of Agile — Heart of Agile relates to Scrum. But the nice thing is that it allows for alternatives fitting your situation. You can create your framework that goes less far than Scrum.
Kanban — Starting with your existing situation, Kanban helps to constantly take steps to improve your process.
DevOps — Aiming for continuous delivery and higher quality.
Scaled Agile Framework — SAFe allows for planning beyond one Sprint. It also works with feedback loops, but the intervals aren’t as short as with Scrum. With that, SAFe suits a more predictable environment.
Note that both Kanban and DevOps can also work perfectly with Scrum. But when Scrum is unsuited, these practices can be alternatives too.
SAFe is a solution for multiple teams. Scrum can work for multiple teams too, but SAFe assumes a more predictable product environment.
Is Scrum for you?
Scrum is a great framework for a specific environment. It helps organisations to deliver products of the highest value in complex product environments.
Many product environments are complex. Complexity may come from many different factors (technology, market, organisational structure to name a few). But if you are not in a complex product environment, consider alternatives to Scrum. Other approaches will suit you better. The same applies if you are not willing to accept the impact of such an environment.
Scrum is a means to help you achieve a goal. Scrum should not be a goal in itself.
Who knows, you may re-discover Scrum at a later stage, when your environment is in Scrum’s sweet spot.
If a developer’s sole problem is Scrum then they are either purposefully not focusing on actual engineering problems or are working on marginally compelling projects.
The times when Scrum bothered me were the times when I was a junior and didn't have much to say about other topics.
Over time, a person realizes that Scrum is just a tool, and the real problem is, and should be, the product and the challenges it poses.
Weekly grumbling (it's hard to put it any other way, these discussions aren't progressing anywhere) about Scrum is the equivalent of arguing about the background color in the terminal, as if that matters.