Scrum is a wonderful Agile method with a huge amount to commend it. And Scrum is a liability for the Agile paradigm.
Why I love Scrum
There’s no doubt at all that Scrum is a fantastic Agile method. Not the be all and end all, but just look at the tools it’s given us:
- Short iterations
- Project Manager as Servant Leader
- Prioritised backlog
These alone should cement its place in Agile thinking.
Scrum also provides a consistent, compelling and simple model (single Product Owner, no external dependencies) that makes it a powerful sell to teams. Inspect and Adapt at all levels:
- Inspect and Adapt your product: Sprint Reviews
- Inspect and Adapt your process: Retrospectives
- Inspect and Adapt your daily progress: morning Scrum
- Even the backlog and its user stories undergo revision in the light of ongoing work
Scrum has also had excellent marketing. A host of user-friendly terms - Scrum, Scrum Master, Backlog, Product Owner, Sprint &c. And in selling training, the Scrum Alliance and Scrum.org continue to spread Agile understanding and uptake.
These have all made Scrum a fantastic first step into Agile for new teams. It remains the backbone of my Agile practice (and I suspect many of ours) even when I want to mix-and-match with tools from other methods.
There’s an awful lot to love in Scrum.
Why I hate Scrum
Agile is bigger than Scrum
I met a senior manager this week who worried that Agile’s insistence on a single Product Owner simply didn’t fit the realities of his business. This isn’t a feature of Agile at all - it’s specifically a feature of Scrum.
Of course this is a downside of that marketing I was praising a minute ago. And this confusion reaches its nadir in job advertising:
ugh! Agile isn’t Scrum. And Scrum isn’t SCRUM.
Scrum is bigger than Sprints
I used to think the major emblem of Scrum, and of Agile more generally was the whiteboard of post-its. I was wrong. For many, the entire Agile movement boils down to Sprints.
Like many of us, I’ve worked in a company that sold fixed time/scope/cost projects (yes all three) for their developers to deliver in an ‘Agile’ fashion by splitting the work into ‘Sprints’. Of course it wasn’t Agile and it wasn’t Scrum.
I really want to repeat that. Not. Agile.
Splitting fixed-specification work into short delivery periods is pure waterfall incremental delivery. They’re not even Sprints. Sprint is a Scrum-specific term for an iteration, so they’re only meaningfully Sprints if:
- They start with collaborative Planning
- They end with Review and Retrospective
- The backlog is open to review and is expected to change
- You build change into your expectations, without onerous Change Control or contractual penalties
Unfortunately companies doing this think they’re already Agile. It limits their own ability to embrace genuine Agile change, and brings the entire paradigm into disrepute.
The marketing genius behind Scrum is both a benefit and a hazard. Scrum practices are and remain an invaluable contribution to the Agile space, and it is many practitioners’ first bite at Agile. At the same time, Scrum terminology has become debased by buzzword abuse that threatens broader Agile uptake.
If I had my way I’d abandon all those cool Scrum words. Make a clean break - save the great practices and leave the language to the buzzword cowboys. Iteration and timebox would be perfectly good plain-English alternatives for Sprint. (There are other good reasons for a language change - perhaps for another post.) Of course a wholesale language change isn’t exactly my decision to make ;)That aside, I can only make a few recommendations:
- Challenge assumptions that Agile = Scrum. If it’s something you yourself believe, learn about Kanban or DSDM or one of the other Agile methods. Expand your practice and your toolset.
- Use Scrum and Sprint only when you’re genuinely employing Scrum practices.
- When you find a Waterfall house that believes it’s Agile, gently work with them to to introduce genuine Agile change. And let me know how you did it and how it went!