I love Scrum / I hate Scrum

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!

Guy

Dual-Track Scrum and the Waterfall Monsters

I was recently introduced to Dual-Track Scrum / Dual-Track Agile at a presentation by the Head of Product at a major high-street brand. It scared the willies out of me that he could describe his process as Agile. More on that later. First...

The challenge

A perennial difficulty for Agile teams: how to combine design with delivery.

• You often need a degree of design before implementing in code
• UX specialists often want to work to a very different cadence from developers, being less inclined to break their work into separable chunks

Some teams have difficulty resolving this within a Sprint. Some solve it by UX working 'a Sprint ahead'. It's not a difficulty that I've particularly experienced with Agile teams.

Another challenge: backlog items that are insufficiently understood or not 'validated', leading to protracted planning sessions where the team tries to understand the story, or expensive validation in code instead of cheap paper testing.

This too is a difficulty that I've not encountered.

Cue Dual-Track Scrum.

Discover / Deliver

Dual-Track Scrum addresses both of these by splitting the multi-disciplinary team into two: Discovery and Delivery.

The Discovery track clusters around the Product Owner. It may include BA, UX, technical representation (perhaps a designated lead engineer) and potentially QA. This track develops the Product Owner's ideas into feasible user stories and designs. At the end of their sprint they hand the designs to the Delivery track for implementation in the next sprint.

The Delivery track implements the Discovery track's specifications. They might then hand them back for QA a sprint later.

Why this makes me shudder

Let's look back at the first point of Agile manifesto:

Individuals and interactions over processes and tools

Dual-Track privileges inter-disciplinary interaction between members of the Discovery track, and subordinates the Delivery track. While it subtracts interaction, it adds process. It limits the ability of the experts on the Delivery track - the people with the bread-and-butter experience of actually building the thing - to feed their insight into the designs they're being asked told to implement.

To emphasise the point, Dual-Track also runs against the third point of the Agile manifesto:

Customer collaboration over contract negotiation

Each design that is passed over the wall from Discovery to Delivery is a mini-contract. We've 'validated' this. The lead engineer has signed it off for implementation. Now build it. Dual-Track is starting to look like a step back towards process and waterfall - even more so if Delivery hand the code back to Discovery a sprint later for QA.

Of course we try to be pragmatic rather than purist. If we lack effective tools to overcome those two challenges, perhaps Dual-Track is worth it.

We already have the tools

Back when I started Scrum, our whiteboard had two ticket states: Not Done and Done. Then the Kanban guys encouraged us to visualise our workflow, the INVEST mnemonic prompted us to make our tickets smaller, and our boards started to look rather different: Backlog / Design / Dev / Test / ...

Sure some up-front design is still required. By the same token there will almost always be some up-front dev: databases, environments, architecture, or spiking to discover the domain. This is not wasted time - it's the business of creating a high-functioning team.

Last time I facilitated a team on this basis, the devs came back with a familiar difficulty in the very first retrospective: designs that were unnecessarily difficult to implement. There and then the team agreed to have a quick multi-disciplinary conversation around the emerging designs straight after each stand-up. It served us for the next three months, to the end of the project.

Thats the second great tool. Inclusive, ongoing conversation. Or in terms of the Agile manifesto again: Individuals and interactions over processes and tools.

I'm not saying that Dual-Track is never a useful or appropriate tool. But if you have the problems that it's designed to solve, perhaps try some core Agile techniques first:

• Visualise your workflow
• Small, Independent, individually Valuable user stories
• Conversation, Conversation and more Conversation

Lord knows this is lower impact than slitting your team in two.

Dual-track goes pathological

If my concern is that Dual-Track is process-heavy, it was rammed home in that presentation I was talking about. Head of Product. High-street brand. 150-head Agile Centre of Excellence!!!

Their Dual-Track process sports:

• Multi-sprint Discovery, with multiple stages for each feature
• Yes he really called them stages - straight outta PRINCE2
• Finished designs handed to the Delivery team for implementation
• Multi-sprint stages in Delivery
• In fact so many stages that he couldn't fit them all on one slide
• Designs that never make it to Live, simply because the pipeline is so long that they're no longer relevant when they get to the end
• Tweaks to features on Live that have to go back to Visualisation, the very first stage of the Discovery track

He described the process as "Agile" and "Lean", with the tagline "Speed leads to perfection". Yet it's a perfect picture of Big Design Up Front and Winston Royce's original description of Waterfall, complete with features that never make it into production!

From Winston Royce's 1970 paper Managing the Development of Large Software Systems. It starts with a fantastic description of the problem that really is a must-read. His solution - lots more documentation - not so much...

Dual-Track may be a valuable tool in the hands of practitioners with a genuine commitment to Agile values. Clearly it holds appeal for some who understand Agile and Lean as buzzwords, but have an instinctive bent towards Waterfall and heavy process.

Beware snake-oil salesmen.