Why Scrum sucks

It's an open secret that Scrum sucks. There are no shortage of luminaries who are calling for developers to abandon agile or speaking out against the “faux agile” of the so-called agile-industrial complex. So why bother with another article on this topic?

Because I’m an optimist. Because I hold out the (admittedly slim) hope that we can learn from and prevent future disasters like Scrum, if only we understand what went wrong and why.

A good thing in theory

Scrum, in theory, is a method for new product development based on the Toyota Way, adapted by agilistas for software development. Scrum, in practice, is the drum major leading the death march parade. But I’m getting ahead of the story.

If you go back to the original article introducing Scrum in 1986, the “New New Product Development Game,” by Hirotaka Takeuchi and Ikujiro Nonaka, you find a holistic approach with an emphasis on speed and flexibility and a rejection of silos and sequential handoffs. That sounds like an agile approach, doesn’t it? It was, and at the time it was fairly radical if not heretical.

The authors, excited by some stunning successes, even claimed that “the new approach can act as a change agent: it is a vehicle for introducing creative, market-driven ideas and processes into an old, rigid organization.”

Sorry fellas, the old, rigid organizations are survivors, and they will absorb you like the Blob. Today, Scrum is the agile overcoat that corporations buy to drape over their old waterfall processes.

Scrum didn’t change old, rigid organizations. Old, rigid organizations changed Scrum.

Scrum is not agile

Scrum was so strongly associated with agile projects in the beginning that the community failed to see them as separate. Scrum’s scientific approach and enthusiastic promotion swayed many into a false sense of security.

Scrum's emphasis on empirical management is logically sound. When circumstances and priorities change rapidly, conventional planning and execution fail, so you must instead continuously observe and adapt.

This is precisely what agile software development approaches accomplish, though they arrived at the similar practices from a different perspective.

Scrum is all about the project management, not the software. Therefore, Scrum per se is not an “agile” software-development method—because it is not a software-development method at all. How did this confusion occur?

If you look at the case studies in the original book, Agile Software Development with Scrum, you'll note that:

• There was strong leadership support for the team’s autonomy and flexibility.
• Experienced agile practitioners (the authors) were leading the effort.
• Some variant of agile (typically Extreme Programming) was used as the software development method.

The book title even says that Scrum is in addition to agile, not a substitute for it.

Hubris and enthusiasm

The authors’ excited intention for Scrum to be a “wrapper” around any kind of new product development method was well meaning but ignored a fatal logical flaw: If you wrap a non-agile method, the whole thing is no longer agile. This is the hubris that causes so many Scrum projects to sow the seeds of their failure.

The fatal flaw with Scrum is that it sees itself as hollow; it has no opinion on how software “should” be developed. It’s as if Scrum’s association with agile was seen as circumstantial rather than intrinsic. Agile is described by a set of principles and values, not ceremonies and processes. Agile is governed by a manifesto, not a process manual. These are two very different things, yet even today many people are still confused by the conflation.

Scrum’s need for agile is further reinforced—perhaps accidentally—by one of its founders in the article “Spotify’s Secret for Competing with Apple, Amazon, and Google.” Jeff Sutherland states that “Spotify insists that its Scrum masters also be experienced Agile coaches.” This implies that the “secret” to Spotify’s success with Scrum is ... agile training!

To reiterate: Scrum is not about the software; Scrum is all about project planning and execution, emphasis of which is generally considered harmful. In this light it’s pretty easy to see how Scrum became a bloated, corrupted, fragile, anti-agile monster loathed by developers worldwide. 

When businesses were beset with pressure to “do agile” (as opposed to being agile), they went looking for something to buy to take away their pain—and they found Scrum.

By failing to have a strong opinion on how software should be developed (i.e., using agile methods), Scrum allows anti-agile methods to be incorporated and cloaked in agile terminology. This was a profound disservice to agile and to developers, and inevitably led to today's proliferation of agile-sounding, morale-destroying, pseudo-agile nonsense.

Don't blame the so-called Agile Industrial Complex; it just delivers what businesses want, and businesses do not typically want to change how they do things, even if they say otherwise (if they did, they’d adopt lean enterprise practices). What they wanted was a quick cosmetic “fix” that let them continue doing things the way they've always done them: renaming.

Ideas so good they had to be imposed

The fact that Scrum is usually imposed on teams is blatantly anti-agile, yet rampant. The Scrum master is now treated as a project-management role, though it was originally a shared, rotating responsibility within the development team. When this happened, the backlog became a sideways Gantt chart, and Scrum as intended ceased to exist. May it rest in peace.

Steve Denning says it best in “Understanding Fake Agile,” that “without an agile mindset, agile remains an inert, lifeless set of ceremonies.”

How might Scrum be redeemed?

Honestly, it’s probably too late to redeem Scrum. Things like SAFe demonstrate that the situation is already out of control. The best we can do is recognize that without agile, Scrum is a disaster. To stop pretending that Scrum alone is sufficient. To promise ourselves to never practice Scrum without agile.

Even better would be to just abandon it—keep some useful bits if they work for your team, but please, please return control to the teams and away from project managers. Kent Beck’s Extreme Programming approach to agile works well, has stood the test of time, and requires no certifications or ceremonies. It does require the team to be autonomous, trusted, reflective, and empowered, with access to and control over the resources that they need to succeed. Which, of course, is much more difficult than hiring a certified Scrum master.

So what can teams do?

The best alternative is to think, not blindly follow someone else’s “best” practice. To connect your teams to customers and business-value generation directly. To focus on products, not projects, and create an environment in which the team is not just allowed but encouraged to adapt, try, fail, learn, and grow. No canned process can replace the wisdom of the team, or inject "agility" into a hostile and stagnant culture.

Remember: You don’t need Scrum to be agile; Scrum needs you to be agile!