Dual-track Agile in Kanban
Earlier this year we had a problem. We were running in a mostly Kanban fashion with work on a JIRA board. We had some newly minted WIP limits to start shifting our focus from picking up tickets to improving throughput and getting tasks to done. But the board wasn’t representing all of the work we were actually doing. There was hidden work.
This hidden work was all the extra bits of research and discovery needed to figure out exactly how we were going to solve complex technical problems. Or how were we going to even Design things. Questions like “What is the best user experience we can create for this function?” were happening on the sidelines and not being recorded anywhere. This meant the important questions were not getting the focus they needed.
What this lead to was Developers picking up development tasks moving them ‘In Progress’ where they would sit taking up valuable WIP, extended our cycle times, while the same developer would try and eke out any extra discovery work required for their project, offline, hidden from view. Not fun for anyone!
We needed a way of capturing this and surfacing it so we could visualise all of the work in our value chain.
Enter Dual Track
Previously when working in teams I’ve used Dual Track Agile (in a Scrum-ish way of working).
In fact there is a really good article here about it: https://medium.com/@daviddenham07/dual-track-agile-the-secret-sauce-to-outcome-based-development-601f6003ea73
Basically it comes down to identifying the two streams of work, or later what became our ‘Modes of work’.
Here’s how we went about it in a Kanban setting.
Tasks could either be a ‘Discovery’ task or a ‘Development’ task (you might want to use the term ‘Delivery’ instead of ‘Development’ as it’s discipline agnostic, this is the term we went with).
If you needed to find out the best way about doing something you’d write up a Discovery task and bring it into the board. If you knew how to do it, and just needed to perform the task you’d create a user story like normal.
Getting to Simplicity
Part of what drove this was knowing what state our ‘Projects’ or ‘Initatives’ were in.
Are we building them? Are still doing research? Is it just a ‘brief’ (shudder) from the business?
To do this I had considered implementing vast monuments to process and tools. Creating complex and unnecessary frameworks, with check points (read: bottlenecks) to enable us to do this creating potentially massive burdens for our team to follow.
Ultimately, with a little help from my team mates, we ended up stripping how we describe the state our initatives into either ‘Discovery’ or ‘Development’.
We either know what we’re buidling, or we’re still figuring it out. Ultimately you don’t need anything more in your process. The rest can be covered in our interactions with stakeholders, and simple confluence documentation capturing all the standard project artifacts (RAID logs etc.)
How it Works
In action how we see it working is each ‘Team’ (which is very loose, fuzzy thing, probably the subject of another topic) works on Discovery tasks to scope up the work they need and then creates their Development tasks to ship the desired solution.
The goal is to try and break down the big unknown boulders, into pebbles we can delivery incrementally. We’d play a bigger discovery task (like say Researching and Designing a new user flow) and then once it’s done, this would create multiple smaller stories which the team could then implement as part of their ‘Development’
Putting it into Kanban
In terms of how it looks on a Kanban board, we again opted for simplicity just labelling a task as ‘Discovery’
We also label ‘Bugs’ as a seperate ticket type… bugs are a bit weird actually. They are part Discovery and part Development. Sometimes if a bug is really weird and complicated we play a spike (Discovery) first to figure it out before estimating the bug. If we feel confident dropping an estimate on a bug we know we can just play it without any discovery ahead of time. Example below.
Limiting the Unknowable
If you don’t know how hard something is going to be how do you limit it? Enter timeboxes - every discovery ticket must have a timebox.
Once the timebox expires you either write the tickets to implement your solution, or if you didn’t find an answer write another Discovery task outlining where to go from here. This effectively puts a stop in Discovery work stream and forces us to have a conversation at a fixed point in time (if you thought it’d take you 2 days to solve a problem, and you’re no closer after 2 days it warrants a wider conversation with the team).
We decided as a team to convert timeboxes to T-Shirt sizes so we can use it for our WIP limit. You might not want to do this, have a chat with your team and figure out what works best for you. The important thing is having a timebox to control your discovery work.
Shameless Linear Plug
Now I’ve become a bit of a Linear fan boy, but for good reason. One of the things it’s enabled us to do is make simple templates for each stream of work. We’ve implemented our own Definition of Ready and Done for Discovery and Development work. This arguably wasn’t possible — in a useful easy way- in JIRA)
In particular we’ve managed to come up with a simple way of setting up our Discovery tasks which ensures consistency and stops us getting stuck in rabbit holes.
We give our Discovery work estimates as well (as it’s part of the value stream, and takes effort). This then contributes to the team’s “Velocity WIP Limit”.
What it meant for us
For our team knowing we have the space and time to work out how to solve problems has been a huge boon. Doing the work about the work feels cheap and light. Anytime we feel like we don’t know enough we know we can play a simple Discovery task first to give us the best chance of getting the solution right when we build it. It’s also helped us reduce cycle times, meaning we can meet more frequently to talk about what we should work on next in our Replenishment ceremony.
It’s also helped our Product Managers as the amount of Discovery work in their initatives helps them understand just how much unknown there is we are dealing with, and therefore how long and how much risk a project might carry.
Have you tried something similar? Keen to hear your thoughts!
