*Until you understand the challenges preventing you from collapsing the process into To Do | Doing | Done
I’m a big advocate of collapsing columns on your Scrum / Kanban / Story board from the classic In Analysis / Analysis Done, In Dev / Dev done & In Test/ Test Done (yes, this is a waterfall process on a wall) to To Do | Doing | Done.
There are many reasons why To Do | Doing | Done is more suited to iterative & incremental development - Jit Gosai does a great job of calling out some of the benefits in his “In Test Column” post.
This post is focused on the When & How of collapsing the number of columns on your board.
What happens when you start with the end?
I worked in an enterprise organisation that was adopting Agile methodology and had leapt in at the deep end.
Those driving the transition towards iterative development all had rich & diverse experiences in Agile so laid down their ideas in the Agile workbook.
They also translated these ideas into Jira workflows.
One of the ideas (aside from rolling out Jira) was to prescribe the To | Doing | Done columns.
Well, this just blew the mind of most of those knew to Agile. Some of them remembered transitioning to Waterfall!
- Where are the quality gates?
- How do I track progress?
- How does the RACI apply to this process?
They had been working with staged delivery for decades & those introducing Agile did not have sufficient grey hair to convince them iterative delivery is better (even though staged delivery wasn’t working for them) .
There are 2 primary reasons I’m focusing on in this post as to why you want to keep the waterfall process on the board; for a little while at least:
- Desert island drop off
- Waste management
Desert island drop off
“Lost” pilot episode
I compared the leap from a waterfall process to To | Doing | Done with being blindfolded, picked up out of your seat & dropped in the jungle of a Indonesian island.
You’d be like Jack waking up in Lost - what just happened?!
You’d have no idea how you got here, what you needed to do & most likely insufficient skills to help you achieve the necessary goal of survival.
You’d need to revert to the skills that helped you survive in the office & adapt them to help you survive in the jungle.
This is exactly what happened at the enterprise organisation.
A wide range of behaviours arose from people not given enough support to help with their transition to Agile including:
- Not really changing their ways of working, but using Agile & Scrum terminology to re-badge their processes
- This lead to more confusion as different people applied the terminology to different parts of the process leading to increased misunderstanding, confusion & frustration
- Using Jira labels as Waterfall process steps. We had to apply a label to reflect what step the work was currently in
- e.g. To Do -> In Analysis / Analysis Done labels
- e.g. Doing -> In Dev / Dev Done & In Test / Test Done labels
- Again, people (even within the same team) used different labels leading to more confusion
- Identifying where their current process already matches the prescribed process so no need to change…
Waste management
Having the Waterfall process with all it’s “Done” or “Waiting For” columns visualises those handoffs / gaps in the process where the work is not being worked on.
In value stream mapping, this is called “Non Value Add” time & invariably over the SDLC it is greater / longer than “Value Add” time when stuff is being worked on.
The image above is a stacked bar chart of the the total time that stories remained in a particular Jira state for a project. The green blocks are “Value Add” time, the red blocks are “Non Value Add” time.
We typically optimise the “Value Add” time because we can see it & track it - there’s visible progress & outputs that can be seen at each stage.
We don’t see or track the “Non Value Add” time as there’s nothing tangible to come from it.
Think about time you spend waiting for an answer to a question you’ve sent in an email, or time spent waiting for a PO to demo your work to. These are both examples of “Non Value Add” time.
When you have “Done” or “Waiting For” columns you can actually see & track work that piles up in them.
You can have discussions about what might be causing work to reside in those Non Value Add columns.
I’d put money on if you spent more time reducing how long work resides in the Non Value Add columns, you will reduce batch size, reduce lead time & increase throughput.
Options for removing columns
I’ve said I’m an advocate for only having To Do | Doing | Done columns, yet I’ve spent the majority of this post explaining why the visualised Waterfall process is so useful.
So how do you get from a visualised Waterfall process to To Do | Doing | Done?
Here’s 2 patterns I’ve experienced on my travels:
- Emergent
- Experiment
Emergent
In organisations I’ve worked in where teams have collapsed the columns, it’s been organic & controlled by the team themselves through close collaboration & discussion.
Emergent Example 1
In one example, the “Dev” & “Test” columns were collapsed into just “Dev / Dev Done” as a result of the stories only residing in Dev Done for a matter of minutes as the team got better at Tester / Programmer pairing & smoothing testing through the SDLC with smaller batch sizes.
The team called out the pointlessness of the separate columns, so we updated the explicit lane policies to show that testing was actually part of development & that we couldn’t be dev done if we hadn’t finished testing.
Emergent Example 2
In another organisation, we reached the Nirvana of analysis, build & test all being part of “Doing” (what I refer to as the Dev Triangle)
To Do was the prioritised backlog (we took from the top) & Done was the code in the production (we still hand to handover to operations for deployment to Prod).
Experiment
Some organisations I’ve worked with knew where they wanted to get to so actively took the decision to collapse the columns, even though stories were taking their sweet time to move through the Non Value Add columns.
Experiment Example 1
One organisation chose to collapse Dev & Test columns in to just “In Dev / Dev Done” as they saw it as a way to drive the team behaviours towards the desired end state.
Taking the training wheels off did result in some level of confusion & lack of visibility of work, but through close collaboration, the feedback loops did shorten, the lead times shortened & guess what… throughput increased.
Experiment Example 2
In the enterprise organisation attempting to adopt Agile we did have some success, albeit for a short-lived project (16 weeks).
We embraced the enforced Jira To Do | Doing | Done workflow, laid out our questions & concerns at the beginning which gave us conditions we wanted to either dampen (if not working for us) or amplify (if working for us).
Having this transparency in a team all new to Agile really helped the team get behind the new workflow.
We gave frequent demos of small pieces of functionality to the business stakeholders (who were very proficient in their domain) which enabled us to make corrections quickly & deliver software they could actually start using as soon as we’d delivered it.
(It was in this project that I developed a Test Strategy & Test Report in Confluence using the Jira Issues & Excerpt macros to reduce duplication across the GxP project, but that’s another story)
Summary
To Do | Doing | Done should be the desired end state for any team looking to do iterative & incremental software development, just don’t give your team that board setup without adequate supervision!
Use the “Done” / “Waiting For” columns to identify what is slowing your development process down & remove those impediments.
Eventually, work in those columns will zip through to the next Value Add column & you can remove the Non Value Add columns.
If you do decide to jump straight in to To Do | Doing | Done, ensure you have boundaries & some form of metrics that inform you if you are going in the desired direction.
In either model, ensure the team has time to investigate the different situations they find themselves in so that they have the opportunity to improve. Themselves.
What other strategies have you tried for collapsing your columns?