Small Steps, Giant Leaps

It is said that the flutter of a butterfly's wing can ultimately cause a typhoon halfway around the world. In other words, a small change in a complex system can have dramatic effects. This is true of software delivery teams looking to improve flow, as I was reminded last year working with a new team and introducing just a few of the ideas popularised by Kanban and David Anderson.

The team’s natural state was to pull in too much work, context switching and queues started to develop. We visualised this on a board and could see the queues and avatars spread across the work. The ability to see this presented the opportunity to talk about how to improve.

We agreed to experiment with work in progress limits, starting by limiting the number of tickets to the number of developers that we had. We also talked about breaking down work further. The team were using relative sizing, so we agreed a maximum story point size, if a ticket was too big, we had to slice it up into smaller chunks. Lastly, we talked about context switching, and limited the number of avatars people were allowed to use. We captured all of these agreements next to our board, and validated the effects by looking at data before and after the change.

The following chart was built by exporting data from our work tracking system into excel. We recorded where work was in progress and where it was queuing, and visualised it. The coloured areas represent the average time where work was taking place at the different stages in our workflow, the white space is the average time the work was queuing before each stage.  This is then laid out in the order that those stages occur. This allows us to both calculate and visualise flow efficiency and show it in relation to cycle time, which is shown in days.

This is what it looked like the first time we measured it. Our flow efficiency was 29%, meaning 71% of the time a ticket was on the board, it was sat waiting in a queue. We could also see where work was spending the most time queuing. On Average, it was taking us about 13 days to get a ticket from initial analysis to live and delivering value.
After the change, we saw some dramatic changes in the data. Cycle time to live had reduced from 13 days to just over 6 days. Our tickets were smaller, so you would expect cycle time to reduce, but the key is the increase in flow efficiency from 29% to 43%. The reason for this is reduction in queuing, which is clearly visualised in the chart.

When we looked at this on a cumulative flow diagram, the effect of that increase was clear. The black area on the CFD is the count of tickets that we had got done and the coloured areas are the amount of work we had in progress at any time, the different colours representing a different stage in our workflow.

The changes we made did take a little while to take effect, as the tickets we already had in progress from before the change gradually made their way across the board to done, but eventually the effect becomes clear. When we measured throughput at the end of August, we could see that it had improved by roughly 150%, far more than a linear change that would have resulted from the reduction in the size of the tickets.

We started publishing these results around our office, pretty soon other teams were asking us what we did, and slowly the same principles began to cross pollinate around other teams.

As we learned more, we tweaked the policies about WIP and ticket sizes, reducing them further. We introduced more ideas from Kanban, such as classes of service and understanding lead time distribution.
​
All of this started from a short discussion about the way we work and agreement to try some changes. No one needed to work harder, no one needed to work over time, just some simple thoughts about how to improve our system put into practice.