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:
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:
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.
Beware snake-oil salesmen.
