Building software is hard. You can spend months working on a cool new feature and when released, the impact is minimal.
To deliver effectively, you need to have a structure in place that allows you to validate ideas before spending the effort to build it.
Single track agile
In traditional software delivery, you follow a linear process of planning, validating, releasing and then measuring. This works for some teams. However, in others, I’ve observed developers waiting for designs to be done, and thus discovery is rushed and a sub standard piece of software is released. If you are struggling with this, then dual-track agile might offer a solution.
Image by Scrum & Kanban: https://scrumandkanban.co.uk/dual-track-agile/
Dual-track agile
In dual-track agile, the discovery track is focused on validating ideas and testing hypotheses using user research and design thinking. The delivery track is focused on turning those ideas into software. In the image below, you can see the discovery track works ahead of the delivery track. This way there’s a steady pipeline of work.
Image by Scrum & Kanban: https://scrumandkanban.co.uk/dual-track-agile/
What does this look like more practically? My colleague, Jennifer Tennant, created this diagram, which articulates how ideas progress through the discovery track and then into the delivery track. By validating your hypotheses, you can avoid committing to an expensive build. The diagram shows stopping at certain points in the design track (another term for discovery track).
Image by Jennifer Tennant
What does this look like as a structure?
In a traditional software delivery team, you have:
- Product Manager
- Delivery Manager
- Business Analyst
- Technical Lead
- Developers
- Designer
- User Researcher
- QA
In dual-track agile, the team can look like this:
The roles listed in the discovery track or the delivery track don’t exclusively focus on their area. There’s a crossover to ensure people understand why work is being done.
In dual-track agile teams:
- The methods of standups, asynchronous messages, and show and tells are used to share progress, request support, and update on tickets. Regular updates are provided when ideas are moved to delivery or discarded. Similarly, updates occur when ideas move to release, monitoring, reporting, and iteration as part of a discovery backlog.
- If user research is arranged then the whole team takes part.
- Planning can be split into two: one for delivery and one for design. During the delivery planning session, you can focus on estimating and understanding tickets. In the design planning session, you can discuss user feedback and data to prioritise your initial focus.
Conclusion
Dual-track agile can be an effective framework to deliver great software. Importantly, it isn’t the only approach to delivery. Remember the fundamental agile principles, and work with your team to find the right approach for you.
