Did you know that Bill Gates always eats two hard-boiled eggs in the morning? Surely if you do the same, you will also become a multi-billionaire. Sadly, it doesn’t work like that. But judging by most self-help books, we really like to believe that a ready-made, full-fledged solution to success is out there, waiting for us to discover it. Scrum is one such example.
Scrum is a destination, not a path
The problem with Scrum is that it’s a description of how successful software teams operate. It’s not particularly helpful in explaining why successful teams operate that way, and I would even argue that for many teams, it actively discourages learning so. The gap that is left behind by phrases such as “simple to learn, hard to master” and “it’s a framework, you are required to fill in the blanks” leads to commercial certifications, expensive consultants, “scaling” and the agile industrial complex.
There is nothing particularly wrong with Scrum itself, when you take it as an observation. But to do Scrum well, you need to learn and understand a host of other things. You can indeed be quite agile without doing Scrum, and you can certainly do Scrum without being agile. Scrum is neither sufficient nor required to be agile.
The recipe
One argument for scrum is that its prescriptive nature makes it easy for inexperienced developers and immature teams to learn. The meetings, roles, cadence and artefacts make it obvious for teams what to do. When you’re a beginner, or so the reasoning goes, you need a recipe. Once you get the hang of the recipe, you can start experimenting on your own. This sounds reasonable enough, but in practice, most companies, most of the time, seem to make a mess of scrum and never do “get the hang of it”. How are teams to “grow into” scrum, if good examples of its application are scarce?
In my experience, the role of a scrum master in an immature scrum team is to explain why scrum requires us to do things in a certain way. It’s a race between growing frustration with process-heavy workflows and building understanding and positive feedback loops. Try coaching a team into taking “ownership” of its own workflow, when the outcome is pre-determined by the company’s agile transformation policy. It’s easier for development teams to conclude that scrum is pointlessly heavy process – let’s just get to programming already! – or too loose, giving you waterscrum, scrum-but, or (gasp!) a monstrosity like SAFe.
Understanding the problem before applying the solution
The best way to build understanding for scrum and its behaviours and principles is, in my experience, to not do them and let the teams themselves experience the pain that scrum aims to alleviate. Once you understand the problem, you can take ownership of the solution. Admittedly, this only works if teams are not already in a deep state of learned helplessness, accepting inefficiency and low quality as an unavoidable reality of software development. I have found that most are.
The clearest sign of the hollowness of scrum is the standard advice of scrum masters and agile coaches when things don’t work out well: you’re just not applying enough of it. Double down on the time-box for the daily stand-up meeting; guard the seams between your roles even more sharply; and insist even more on delivering a potentially shippable product increment at the end of the iteration. If only you add more scrum, surely, in the end, it will work out. After all, so it is written in the scrum guide scripture.
Between do and do not
Kanban takes a different approach than Scrum: it starts with what you’re doing now. While scrum teams can (and often do) debate at length on what is and is not the correct interpretation of the scripture, Kanban teams start with a few basic values and develop their process from there. It is not uncommon for mature Kanban teams to end up with something strongly resembling scrum, proving that scrum might be a correct observation of how mature teams operate, but also that it is at best a lacking or at worst a harmful guide in the journey to agility.
It goes without saying that organisations that are capable of eradicating all agility from scrum are equally capable of making a mockery of Kanban. Still, I have found Kanban to make it more obvious that the emperor has no clothes.
Moving forward
For me, the way forward is a Kanban-style iterative approach to the software development process, where organisations choose a set of principles that will take them to an unknown final destination in a journey toward agility. That means investing in breaking down silos, coaching and personal development. The risk and uncertainty that implies is unacceptable to many organisations who distrust their own staff and would prefer an off-the-shelf solution with certifications and consultants to go along with it. They will have a hard time reaping the benefits of their agile tranformation initiatives, because scrum is neither sufficient nor required to be agile.
