How Scrum destroyed Agile
Scrum lacks technical craft and fails to compensate for natural organisation tendencies to prioritise short-term product and management priorities, so teams adopting it are generally not getting the benefits agile is meant to provide. Couple that with the fact that it is, de-facto, the only agile methodology in use today, agile as a way of improving software development is being destroyed by Scrum.
(Of course, there are agile teams using Scrum and successfully running good software projects. Unfortunately, they're succeeding largely in spite of Scrum, not because of it.)
In this series, I’ll briefly describe the history of Scrum and agile. I’ll then cover what I see as the three main issues with Scrum: it is too process-oriented; it is too management centric; and it lacks technical craft. I’ll look at where it all went wrong and how Scrum’s own popularity has turned into a cargo-cult of itself. Finally, we’ll have a look at what’s next.
So, without further ado, I present the short, probably incomplete and certainly biased history of Agile and Scrum.
An abridged history of Agile
Interestingly, the methodologies that were later termed agile were invented before the Agile manifesto was written. The Agile manifesto actual came out of a collaboration between the inventors of Scrum, extreme programming, and other agile methodologies in the late 90’s. It says:
“We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.”
That’s it. If you’re valuing the items on the left more than the right, you’re doing agile.
What's interesting about the manifesto is that, if you look at the signers of the original Agile manifesto, you can see that Scrum and Extreme Programming (XP) were the main methodologies represented:
Kent Beck
Mike Beedle
Arie van Bennekum
Alistair Cockburn
Ward Cunningham
Martin Fowler
James Grenning
Jim Highsmith
Andrew Hunt
Ron Jeffries
Jon Kern
Brian Marick
Robert C. Martin
Steve Mellor
Ken Schwaber
Jeff Sutherland
Dave Thomas
Author annotations from my own research; if you happen to know Greening or Kern’s affiliation, let me know!
If you weren’t around in the 90’s and early 2000’s, you’d be forgiven for not having heard of XP, as it has basically sunk without a trace in the intervening years, while Scrum has marched ever onwards. For example, look at the Google Search Trends from 2004 onwards.
Anyway, XP was no panacea. It suggested twelve interlocking practices, all at the extreme of what was considered possible for software development at the time (hence the name). As Matt Stephen once put it, “XP is like a ring of poisonous snakes, daisy-chained together.” The practices it espouses do seem to work powerfully together, but dropping any of them is risky as each practice covers for a weakness of another.
However, this is a criticism of Scrum, not XP (maybe we can do that another time). So why am I mentioning XP? Well, looking back at the affiliations of the manifesto authors, we have three Scrum, four XP, one representative each from four other methodologies, two people I couldn’t classify as supporters of anything in particular, and four people who advocate craft. Of those four other methodologies, at least DSDM, Crystal, and MDA all have specific technical practices.
Craft: The Pragmatic movement, exemplified by The Pragmatic Programmer book, sees software as a craft, for example in subtitling that book "From journeyman to master". It's an excellent (if slightly dated) book with 46 chapters, each giving challenging ideas to consider in your practice and exercises.
Not to jump ahead, but compare that with Scrum, which you can call yourself the master of in just two days of training.
So, to summarise, almost every method and technique that was represented at the Agile manifesto was concerned with technical craft. XP is a methodology for software development, and as such, seven of the twelve practices are about how the software is written (pair programming, TDD, continuous integration, refactoring, simple design, system metaphor, coding standards). The craft/Pragmatic contingent weren’t designing a methodology for a team per se; they were concerned with how the software was written. But Scrum? Go read the Scrum Guide. It’s not long, I’ll wait. Alright, I’ll quote the relevant bits:
“Scrum has been used to develop software, hardware, embedded software, networks of interacting function, autonomous vehicles, schools, government, marketing, managing the operation of organizations and almost everything we use in our daily lives, as individuals and societies.”
It’s not a software methodology. Or even a technical methodology. It’s aimed at project managers who have this amorphous “development team” that they are trying to make develop what they want, faster. Scrum could be used to design HelloFresh menus (it isn’t, to my knowledge) or apparently to prepare a ship for war. If you search for the word software in the guide, that quote above contains the only two mentions!
So, to summarise, when the Agile manifesto was signed, many or all of the signatories were at least as concerned with the craft of writing software and how that could be done well, as they were with the wider process. But since then, Scrum has lost any technical requirements.
This lack of technical craft means Scrum can’t deliver the benefits of agile long-term, both directly in terms of technical quality, but there are also indirect effects. Next time, we’ll look at one of those indirect effects: Scrum subtly disempowers programmers through the language it uses and the structure of the process. Just to whet your appetite (quoting from the Scrum guide again):
"Scrum recognizes no titles for Development Team members, regardless of the work being performed by the person"
So Scrum has a master, product has an owner, but no-one is empowered to advocate for development priorities. We’ll see the impact of this disempowerment next time.