One of the most common complaints I hear and read about Scrum is about Scrum being very strict and inflexible. Is that true?
Well, the Scrum Guide, which lists the rules of Scrum does say:
Scrum’s roles, artifacts, events, and rules are immutable and although implementing only parts of Scrum is possible, the result is not Scrum. Scrum exists only in its entirety
That is pretty clear, isn’t it? Follow the rules or you’re not doing Scrum!
Scrum seems to be out of line if one of the principles of the Agile Manifesto is “People and interactions over tools and processes”?
Let’s take a look and see.
There are good reasons to stick to the rules of Scrum
The reason why we should follow the rules of Scrum laid out in the Scrum Guide isn’t as trivial as “The Scrum Guide says so!”. There are much better and more important reasons.
The rules of Scrum are there for a good reason
The first thing to understand is that the rules of Scrum exist not despite the Agile Manifesto but because of it.
For example, the various events exist because we believe that individuals and interactions are more important than processes and tools. Sure, these events are part of a process but one that focuses on individuals and interactions. Each event is an opportunity to interact, as well as to inspect and adapt.
Similarly, we do sprint planning because responding to change is more important than following a plan. That’s why we only plan a little bit at a time and not in great detail, so that we can be flexible and respond to change.
Many problems are due to misunderstandings
Unfortunately, many people have peculiar ideas what is or isn’t Scrum and there are a lot of misconceptions out there. In fact, even having a Scrum Master certification is no guarantee for understanding Scrum.
Scrum actually offers a great deal of flexibility. Some examples:
- Sprints are not rigid and don’t “fail” if we are unable to finish each and every backlog item we thought we would. Yes, we do have a goal for the sprint but this should not be a list of backlog items. A sprint goal, as the Scrum Guide points out, “can be any other coherence that causes the Development Team to work together rather than on separate initiatives”.
- Story point estimation and “an obsession with estimating” are not part of Scrum. Many teams do use story points and many find it useful. However, we might just as well use another forecasting method like #noestimates. The rules of Scrum say nothing about this.
- The team doesn’t “commit” to delivering the backlog items in the sprint. They simply forecast what they believe they will be able to deliver. Pressure to stick to the plan at any cost will just tempt people to take shortcuts.
Don’t shoot the messenger
When implementing Scrum, issues are likely to surface that were there all the time and only became visible through the transparency of Scrum.
One example are those who claim that “in real life”, there will be a lot of urgent issues the team need to deal with so it’s just not possible to plan for a period as long as a sprint. Is dealing with these requests genuinely more valuable than delivering new functionality? It might be. If so, that’s perfectly fine! Scrum probably isn’t the best framework in this case. Otherwise, try to solve the root cause of why these urgent requests keep coming in so that you can focus on your product delivery. You will be getting a much better return of investment that way.
Others claim that they can’t deliver working software in a sprint. Their product is “too complex for that”. Well, Scrum can be used to deliver complex systems. In fact, that is where it excels. For example, the systems for the Swedish fighter jet Saab JAS 39E Gripen are delivered in three-week sprints. Instead of hiding behind your complexity, look at why your cycle time is so long.
Sure, it may be easier to “change Scrum” than to solve the actual problem. Unfortunately, that won’t help you deliver more value quicker.
Still, there are cases where breaking the rules makes sense
If the rules of Scrum are all there for a good reason, are there never cases when breaking them is the right thing to do? Sure there is.
Typically, these cases fall into two categories:
- We can’t follow the rules right now
- We have a better way of doing something
We can’t follow the rules right now
Sometimes, we will have to accept a compromise.
Let’s say, for instance, that we’re introducing Scrum to a new team. Unfortunately, they rely on a separate team of database administrators to make the necessary updates to the database. This means our team isn’t fully cross-functional, as they can’t complete all the work needed to deliver new functionality.
Does this mean we can’t go ahead and use Scrum? No, that shouldn’t stop us. Let’s do what we can now. Doing Scrum without a cross-functional team is probably better than doing waterfall without a cross-functional team.
However, let us not accept this compromise as “that’s just how things are here”. We need to keep trying to make the team cross-functional. Perhaps we can train up someone in the team or get a database administrator to join the team? If they hesitate, we can always call it an experiment!
We have a better way to do things
Once we have been using the artefacts, events and roles of Scrum for a while and fully understand their intentions and we spot a case where we think something else would work better to fulfil those intentions in our context, who can stop us from giving it a go?
More often than not, these changes will be fairly small. A common and trivial example is how many teams move from each team member answering the standard three questions in their Daily Scrum (“What did you do yesterday? What are you doing today? Do you have any impediments?”) to “walking the board”, discussing each backlog item instead.
Ultimately, our goal is to deliver the most value we can, not to do Scrum. It is possible to be agile without doing Scrum and without the right mind-set, it is certainly possible to “do Scrum” without being agile.
As agilists, we believe there are always better ways to do things. Scrum isn’t “done”. It evolves. For instance, the release plans and burn-downs, which were part of the original Scrum Guide, are no longer considered part of Scrum. If no one ever bends the rules, Scrum would stagnate.
The important thing is to not change Scrum because it is easier than solving our actual problem.
What do you think, do we have to stick to the rules? Which rules do you break? Share your experiences in the comments below.