Friday, 13 March 2015

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

Retrospectives

Project Manager as Servant Leader

Burndown

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:

Project Manager with Agile/SCRUM

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.

As in

“We work in Sprints.”

Or

“We blend Waterfall and Agile (because we work in 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 upshot

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!

Who am I?

Agile practitioner for twelve years. Scrum Master and Agile Project Manager (yes they do exist!) and now Delivery Manager for a decade.

Why am I committed to Agile methods? Because they treat grown-ups with respect. Clients who can legitimately develop their ideas and change their their mind. Teams who bring more to the party than ‘mere’ technical skill. Agile approaches both assume and foster fruitful collaboration.

I’ve been lucky to work with some really varied companies. I've seen different approaches to Agile delivery - some done well, some done terribly - and been able to gain broad experience. This blog represents some of that accumulated experience. Expect my opinions to change as I continue to grow and learn!

The by-line photo is nicked from a friend at the Cheap Emotional Response Network. You know who you are - thanks mate!