The practice of adapting Scrum is not as bad as you think — but you need to make sure your modified approach works.
“We are doing Scrum, but …”
Some people snort if they overhear a sentence starting like this. They think to themselves: “Oh no! Yet another person who hasn’t understood Scrum and is cherry-picking“. By many, it’s considered an anti-pattern to adopt only some tenets of Scrum. In contrast, people are taking a pragmatic stance. They might say: „It’s all about the results, and if we have to change everything about scrum to achieve that — so be it.“
There are even people who think that the so-called ScrumButs are the best about Scrum.
I tend to the position: everything about Scrum can change if it serves your needs.
After all, being agile is about uncovering better ways of working by doing it. It is about individuals and interactions over processes and tools. Seeing it like this, Scrum cannot be the holy grail that you have to guard by all means. Yet, there is a key point to consider that is often overseen despite its importance:
Your process needs to work.
It doesn’t matter what worked for the inventors of Scrum, Ken Schwaber and Jeff Sutherland. Neither does it matter what the trainer in your Scrum training thinks. It is all about what helps you deliver with your team, in your specific context and for the specific tasks at hand.
Scrum’s roles, events, artifacts, and rules are immutable and although implementing only parts of Scrum is possible, the result is not Scrum.
(Quote from the Scrum Guide)
First, it makes sense to have a look at why Scrum is the way it is.
In the Scrum Guide, it says that the roles, events and artifacts are immutable. It goes on to say that it’s possible to put in place only parts of Scrum, but the result is no longer Scrum. Some people want to see dogmatism in this statement – and they are wrong. It doesn’t mean that you can’t deviate from Scrum for good reasons. No one would criticize you for doing so if you have done your homework. All it is saying is that Scrum is the way it is on purpose and that its parts build upon each other. Of course, omitting some of these parts results in something else.
Every role, artifact and event in Scrum serves a purpose in the framework. They serve that purpose best when served together. All in all, it’s about working empirically, starting in relative uncertainty, and gain insights as you go. You can use these insights to improve the collaboration in your team, the process and the product. Above all, these insights can help you deliver better results.
For that purpose, the often-criticized events help, as much as the roles do:
- A Product Owner can help to maximize the value of the product for the customers. For that reason, he must be able to focus on customers, their needs, and explaining them to the team.
- A Development Team can deliver quality work more likely if they can focus on doing things right. Their time is best used if they don’t have to do guess-work about requirements and priorities.
- A Scrum Master can help the team improve their collaboration and processes when he can focus on that job.
The Sprints create rhythm and limit the risk of walking in the wrong direction and not noticing it. The events serve as checkpoints to evaluate if the team is still on the right track. They give an opportunity to gain and incorporate feedback and to learn and adapt.
In Scrum, you will recognize the idea that learning is an integral part of work. If we practice Scrum, we don’t relentlessly follow a plan. We plan in shorter cycles to realize early if some premises have changed in the meanwhile. We won’t wait for our plan to fail. We create opportunities to inspect and adapt before it’s too late.
Let’s assume your team is pretty successful. The team and the customers are happy and your business is profitable.
It could be there is no dedicated Scrum Master in the team. Instead, people in the team step in this role in turns. It could be that works because the team has been working together for so long. Or there is nobody who can perform the task right now. Still, your teamwork and processes improve over time.
It could be your team isn’t cross-functional. Or that it at least misses a few competencies for independence from other teams. Instead, you have to fall back to other departments for certain tasks. But you have found a way to work with them and aren’t blocked while waiting.
Or it could be you don’t do a Daily Scrum because the members of the team are scattered around the globe. Nonetheless, they still coordinate their efforts, identify and overcome roadblocks.
It requires trade-offs to design a process for your context. Some decisions result in a process that makes it something else than Scrum. The name is not important, though. You should ensure that you don’t leave out parts of Scrum that solve problems you actually have.
It could be there are other tenets where you don’t stick to Scrum by the book — and that’s okay.
The point is not whether I practice Scrum exactly by the book. We can embrace the idea of empiricism. At the same time, we can discard the idea we should create a process suitable for every team in the world. We can understand that Scrum might not apply to everyone. For some teams only some practices are. Others might want to add practices. The world is complex and there are no instruction manuals for complex situations. Scrum in its entirety helps to deal with the complexity of the world. Yet, it is not such an instruction manual either.
We can only discover the right way forward as we go. Complex situations call for emergent practices. Seen in the right light, this is exactly what Scrum is about.
We can conclude that some practices of Scrum are not suitable for us. If we conclude that while working in an iterative, empirical process, Scrum in fact did its job. We need to make an informed decision, though, based on facts rather than on our gut feeling. Not for convenience but for a reason. Tools and processes are there to help us — not the other way round.
When we discover a way to collaborate and deliver value that works for us, we already gained a lot.
Do we inspect that our approach still works on a regular basis? Does it, when people come and go, if market conditions change or when our priorities shift? In that case, we can only shrug our shoulders over a statement like the one in the Scrum Guide. If we keep collaborating in a good way and solve problems when they arise — why should we give a damn about the endnote in the scrum guide?
We need to make sure our approach works. We do this by trying out and discovering what works best for us.
If we stay curious and reflect on a regular basis we are on a good way. We are on the right track for real, if we get comfy with the thought that sooner or later we have to change our processes. After all, change is inevitable and if we are able to adapt to it, we ensure the resilience of our company.
So it may not be Scrum then, but we don’t need to care.