But there’s a way out of the misery
I feel for all the developers that have to work with Scrum. Or rather, I feel for all developers in the world. But, even more for the developers who are let down by Scrum.
Scrum (and Agile as a whole) promised to liberate the developers. It was supposed to be a new way of working that would break with the traditional approaches to delivery. It was an acknowledgement that software development isn’t the same as building a house or a car. Which calls for a different approach altogether.
But nowadays, many developers hate Scrum. It’s very easy to find reports of people who have suffered under the pressure of being part of a Scrum Team.
How can this be? How can an Agile framework like Scrum be so detrimental for so many people? Let’s uncover this together.
![](https://substackcdn.com/image/fetch/w_1456,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fbucketeer-e05bbc84-baa3-437e-9518-adb32be77984.s3.amazonaws.com%2Fpublic%2Fimages%2F732092c6-f644-4ba4-8495-390b449a4bd7_800x533.jpeg)
Good intentions
Scrum was one of the approaches that led to the Agile Manifesto. And all the promises it brought, with principles like:
“Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.” — 5th priciple behind the Agile Manifesto
and:
“Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.” — 8th priciple behind the Agile Manifesto
but also:
“Continuous attention to technical excellence and good design enhances agility.” — 9th priciple behind the Agile Manifesto
and:
“The best architectures, requirements, and designs emerge from self-organizing teams.” — 11th priciple behind the Agile Manifesto
This showed so much promise. Finally, there was the recognition that software development is different. At long last, there was the recognition that it isn’t the same as manufacturing goods. 100-year-old management notions don’t apply to modern-day software development. Things had to change.
The harsh reality
Fast forward 20+ years.
Agile is everywhere these days. It is here to stay. The vast majority of software developers have worked with agile approaches. Most of them experienced Scrum. And many of them despise Scrum to its core.
How can this be?
That’s a long story. I could write a book about that. In fact, I might have done this already. Because most of the articles I have written in the past 4 years are about the dreadful implementations of Scrum, the real reasons to use Scrum, about how you should use Scrum properly to succeed, and how everyone in the company should be engaged.
Cogs in the delivery machine
But Scrum has largely been used as a tool to deliver software increments at regular intervals. It has been used as a mere delivery tool. As one of the cogs in the machine of the delivery of goods, the software, to the clients.
Scrum Teams became cogs in the machine of the delivery of goods, the software, to the clients.
And the thing is, on the surface Scrum has been pretty effective as a delivery framework. Scrum allowed companies to respond to priority changes because of new developments or customer requests. Almost everyone has embraced the aspect of constant replanning to deliver the features deemed important most.
Scrum misuse
But meanwhile, many developers have suffered. Because people with power misused Scrum to add more pressure on developers. The pressure of delivering items according to plan every Sprint. Having crunch time every two weeks to ensure they meet external expectations. In the good old days of Waterfall projects, teams had to deal with this far less frequently, mostly at the end of the project. These days, many developers feel constant pressure to deliver.
For most teams, the goal of sustainable pace is an illusion. But the other principles of the Agile Manifesto that I just discussed are under pressure too. How to keep motivation high when you are under constant pressure? How to uphold technical excellence when you need to deliver “NOW”? How to be a self-organizing team when all you need to focus on is faster and faster delivery?
Some of you may nod in agreement now. Others may disagree. Because what I described, has nothing to do with the true nature and intentions of Scrum. Scrum is about discovery through delivery. Discovery is key. Scrum Masters should ensure Scrum is established as intended, helping people within and outside of the team to understand the framework.
Levels of Scrum misuse
Some of you may have great experiences with Scrum. You may be using it as intended and you may have stakeholders who know and play their role well. From my experience, and what I have heard from countless colleagues and peers, you are an exception.
Others may have the autonomy to work in a fully-fledged self-managing Scrum Team that calls the shots and is empowered to withhold undesired external pressure. They are Agile islands in a mostly traditional company. As soon as they have to address impediments outside of their influence, they see no way to have them removed. Because the company doesn’t want to change. This is a situation I have seen more often.
But many teams don’t even have this luxury. They continue to be seen as cogs in the machine. As part of the delivery process. Ignoring that software development largely is creative work.
Scrum is almost thirty years old. The Agile Manifesto is more than twenty years old. Scrum and Agile are everywhere. But mostly misused. People suffer because of Scrum. Or rather, the misuse of Scrum. This is the terrible situation we are in.
Should we abandon Scrum?
So, Scrum has failed many developers. It didn’t do what was promised. Admittedly, this is largely due to the fact that Scrum has been misunderstood. But does that matter in the end, whether Scrum is misunderstood or not?
What happens when teams would abandon Scrum? Are there other approaches or frameworks that teams can use that would free them of the issues of external pressure and artificial deadlines? Is Kanban an answer to this? SAFe perhaps?
I’m afraid not. It’s not the frameworks or the methodologies that cause the misery. It’s the environment that the developers are in. As long as the working environment of the developers doesn’t change, every approach will fail to bring them relief.
As long as the working environment of developers doesn’t change, every approach will fail to bring them relief.
The real way forward
Abandoning Scrum certainly is a way to get out of this mess. When there’s a valid alternative. Kanban may be an alternative, but it also serves different needs. Perhaps XP is a way forward. Or Lean Startup. To name a few. Don’t get me started about SAFe. Suffice it to say it will not bring relief for developers.
There’s an alternative. The environment of developers and their team(s) should gain an understanding and appreciation of Scrum as it has always been intended. They should learn why Scrum exists and what problem it intends to solve.
Raising stakeholders' understanding of Scrum may be a daunting task. But an important one. Not necessarily to be able to benefit from Scrum as intended. But more fundamentally because software development calls for a different way of collaborating, both for the teams and their stakeholders.
If you wish to create value in a complex environment — which is true for the majority of software development environments — then you need to give teams the trust to find the best ways to achieve the goals, to self-organize, and work at a sustainable pace. To allow the creative juices to flow.
Only when you ensure that the stakeholders of the Scrum teams understand their role — and enact upon it — will you allow teams to make the best of Scrum. Which benefits everyone.
Often overlooked, but oh so important is the Scrum Master’s accountability in this. They should help the Scrum Teams(s) and their stakeholders on this journey, by:
“Helping employees and stakeholders understand and enact an empirical approach for complex work” — Scrum Guide 2020
And
“Removing barriers between stakeholders and Scrum Teams.” — Scrum Guide 2020
The Scrum Master has such a vital role to play. But should be empowered to do so. When this isn’t the case, then the Scrum Team is in trouble. But when empowered, many Scrum Masters need to step up their game.
But when all of this doesn’t help -or will not happen-, you are better off dropping Scrum. Scrum can only work when certain prerequisites are met. Without them, it is terrible torture.