Countless teams have moaned over Scrum being too rigid and not really suited for their particular domain. As an agile coach responsible for countless agile transitions I strongly disagree.
Why do teams claim Scrum would be too rigid?
There are several reasons and the behavior we encounter in the wild during an agile transition is usually a mix of many of these.
Resistance to change
One reason is surely the natural resistance to change. Teams who haven’t used Scrum before or who are inexperienced with an agile style of working can often reject Scrum. This psychological phenomenon is well studied and can be tackled. In short, people shy away from the unknown, even if it can make things better – they’d rather stick with the worse system they got, because at least they know its flaws and how to handle them. Other aspects of resistance to change can be the fear of loosing benefits or power, lapses being exposed or simply the fact that they (co-)created the existing processes. All of this can be tackled with traditional change management techniques (I will not go into the details in this article).
Failed changes in the past
Another reason to resist Scrum is a the feeling of change coming along every couple of months or years. People get tired of the next “new thing” and simply resort to either fighting it, ignoring it or simply playing along without adopting it. For this aspect it can be handy to show that Scrum (and agility in general) is not another set of processes, but a whole new way of thinking and looking at other human beings. Scrum itself might come and go, but agility is much more fundamental than frameworks and processes. I build my coaching heavily on the long-term transformational aspects of agility, because they’re far more important than the frameworks you use.
ScrumBut
Calling Scrum too rigid has teams often end up with the infamous “ScrumBut“:
“ScrumButs mean that Scrum has exposed a dysfunction that is contributing to the problem, but is too hard to fix. A ScrumBut retains the problem while modifying Scrum to make it invisible so that the dysfunction is no longer a thorn in the side of the team.” – scrum.org
In another article I compared Scrum to a Geiger counter. If your Geiger counter starts clicking a lot, would you expect to solve the problem by turning it off? Sometimes the things that hurt or annoy us are the best devices to push us towards improvement.
The funny thing is that Scrum works as it is in so many vastly different domains, that claiming you’re the only team or company it would not fit is frankly a little ridiculous. Of course we always think our domain is more complex than so many others out there. But that comes from our intricate knowledge of our domain, not from its inherent incompatibility with Scrum. If this objection is raised, I sometimes describe the product or service the company is offering through the eyes of a naive customer: you’re a mobile network provider with complex technologies? For your customer you’re just a commodity data pipe to build more complex and valuable services upon! That change of perspective, while painful, can somber you and show that even your company will be seen as simple by others.
Scrum is not a buffet from which you pick what you like. With Scrum you either take the whole thing or you simply don’t do Scrum. With Scrum being fully described on less than 20 pages in the Scrum Guide, it shouldn’t be that hard to adopt all of it.
A skeleton is rigid
A big concern of teams can be that Scrum is very strict and prescriptive: you have a fixed sprint length, you have fixed roles, you have events happening regularly like clockwork. While that sounds stifling at first, it is actually a liberating rhythm. After all Scrum will not tell the team how to do their work – Scrum merely establishes checkpoints to reflect and improve (“inspect & adapt”). Scrum is the skeleton in your body to allow you to move flexibly and agile. Imagine how much a body without a skeleton – it would not be able to move at all! Consider Scrum the skeleton of your work.
Trying all the shiny new things
Nowadays I often hear people proposing Kanban instead of Scrum, because Kanban would be more flexible. And while there is some truth to that, Kanban is in other aspects harder to do well. The clear set of rules and suggestions from Scrum are often preferable to Kanban especially for teams with little experience in agility. For an agile transformation, Scrum is often a perfect solution. A good agile coach must consider many aspects to decide on whether to start with a soft flavor of Kanban or with Scrum. And sometimes you have to experiment with both. Just don’t discard any of the agile frameworks too early without honestly trying to make them work.
If you were wondering whether Scrum would be too rigid for your company, I hope I could give you some help to make a more informed decision. It is totally fine to not go with Scrum (or Kanban or x), but you should do it for the right reasons.
If you need support with agility in your company or if you just have questions, feel free to chat at me on LinkedIn.