Not every story about Scrum is a success story. Scrum can fail.
One of the reasons why many teams don’t get the value out of Scrum they were hoping is that they are trying to use it in a situation or environment where it is not appropriate. No set of practices will work in every single context and Scrum is no exception.
Let’s look at some examples where Scrum will either be very hard to make work or provide little value compared to a simpler process.
1. When the requirements are not allowed to evolve
Scrum is aimed at solving complex problems. The kinds where we are unable to judge up front exactly what will be the best solution. That’s why Scrum takes an iterative approach, building something, getting feedback and adjusting the course.
Requirements emerge. Rather than working towards a fixed specification and scope, we learn what do deliver. If we’re used to having a detailed specification up front, Scrum will be a big change. Basically, we’re saying we don’t know quite what we will build or how much of the functionality we will be able to complete within the timeframe but believe us, it will be the best thing possible we could have done! That requires a large amount of trust.
Certainly, a fixed product specification may be no guarantee a project will be successful but it can give us a sense of reassurance that is hard to let go of. Not least for the customer signing a contract!
If we have no interest to learn what to deliver, and think we have it all mapped out already, Scrum won’t be of much use.
2. When the organisation is unwilling to adapt itself to Scrum
Scrum comes with a set of practices that work well together. Leave some out, however, and the result can be very different. Some of these practices are easy for most teams to adopt. Others can take a lot more effort to implement and have impacts outside the team. Some even make it necessary to make changes to the organisation itself.
Not only does Scrum bring with it new job roles in the form of the product owner and the scrum master. We also need cross-functional teams, meaning they need team members who together have all the skills needed to deliver the work from start to finish within a sprint.
Being cross-functional is how the team can reach a potentially shippable increment by the end of the sprint. Doing so allows them to adjust quickly to the emerging requirements, without needing to go back to other teams to request changes.
Cross-functional teams require people with skills who may not be part of the team today, e.g. skills in business analysis, user experience design, database administration, testing etc. This can be a fairly big organisational change.
If not willing to make that change, we won’t be able to get the full value out of Scrum.
3. When looking for a one-stop solution to all our problems
Scrum won’t solve all our problems. In fact, the State of Scrum survey from 2015 states that 38% of all Scrum projects fail (that is still a lot better than the average for software projects, though).
Some of those projects would have been doomed regardless of which approach they took. However, there will be a good few that could have been successful projects, where Scrum was both suitable and followed 100% but the project failed.
Scrum by itself won’t solve any of the following issues:
- No product vision
- Lack of good technical practices
- Conflict in the team
At best, it can help making these problems more visible.
To create a good product, we need to add other, more hands-on practices on top of Scrum. On the technical side, it is for example common to combine Scrum with various practices that are part of Extreme Programming, XP.
4. When frequently needing to respond quicker than a sprint allows
Scrum assumes that we can plan what to do in a sprint. When building a brand new product, this is often fairly straightforward. Once the product goes live, though, we tend to start getting requests from stakeholders and users that are affecting the live system and real users, right now. These can be bugs or requests for changes or additions. Some of them, we can simply add to our backlog and deal with in a future sprint. Others, though, are urgent and we need to address them. Now!
On a mature product, where we will have delivered a lot of functionality over a long time (or even several different products!), these kinds of requests can end up consuming a large proportion of the team’s time. Our sprints will no longer have the nice, clear focus we were able to have at the beginning and we need to allow for unpredictable, unplanned work popping up in the middle of the sprint. It’s just not good enough to say that we’ll schedule a bug fix for the next sprint if it prevents the users from using the product!
One common workaround is to set aside an amount of time in the sprint for these kinds of fixes, for example 20%. Another is to rotate the responsibility amongst developers to deal with the disruptive requests. Both these methods can work well, up to a point.
However, some teams find that a large part of their work ends up consisting of little tasks with no coherence. The problems they are solving are no longer complex and responding quickly is more important than creating innovative solutions. In these cases, planning work into sprints the Scrum way will no longer give us much benefit. In fact, it would rather add unnecessary overhead.
5. When people have had bad experiences with Scrum already
Finally, let’s also acknowledge that a lot of weird stuff happens the name of Scrum. With so many people practicing it, many will have had experiences of Scrum not working. They might go as far as saying that Scrum sucks.
The reasons for their experiences may vary. Perhaps they were forced to use Scrum in an environment where it wasn’t appropriate. Maybe they did it wrong. Or they used something else that work better for them than Scrum did.
In these cases, it is useful to understand where the distaste for Scrum is coming from. Is it based on some misunderstanding we can clarify? However, forcing Scrum upon someone is unlikely to be very successful. After all, a self-managing team decides how to do the work. The ultimate consequence of this is that they can decide whether to use Scrum or not.
Let’s not limit ourselves to one framework
As scrum masters, it is important to understand that Scrum won’t work in every situation. We shouldn’t be tempted to introduce it wherever we can, without considering its suitability. Neither should we hang on to Scrum at all cost when it isn’t working.
In many cases, Scrum is an excellent framework. When it isn’t, let’s try to understand why it’s not working in that situation. Maybe people need a bit of training or there are impediments that can be removed? In some cases, however, Scrum just won’t the best solution.
After all, other frameworks are available.