Thursday, 26 February 2015

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

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!

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.

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!