Physical kanban walls, with index cards, present powerful and easy ways to collect data and encourage the team experiment with improvements to our process. I’ve come across a simple technique of writing a ‘column tally chart’ on the bottom of each index card as it crosses a kanban board to help study and manage the flow of our work.
Each day at stand up we write the first letter of the column that the card ends up in on the bottom of the index card after we’ve finished discussing it. This acts as a simple tally chart of the how many days it takes the card to cross the board, as well as providing information about where the card spent its time. Here’s an example of a card:
In this case you can see the card in the centre of the photo took three days from starting development to completion. The card was in the Development column (D) the first time the team discussed it at stand up, the second day it was in the Test column (T) and at the last stand-up it was in the Done (X) column.
Studying by asking questions
We use the column tally chart information on each card to ask questions like:
- What kinds of work take us longer? Where is the time taken?
- Are there any patterns around which columns (steps) in our workflow take time?
- Where we have to hand-over work between different people on the team (such as code review or testing), do we see delays?
- Is a step in our process, like code review, adding a burden to the time it takes us to complete work?
- Are any tasks ‘bouncing back’ from a later step? Which steps are they bouncing back from?
- Are they trends in how long work is taking or how it is flowing compared to earlier periods?
For situations where we estimated the work, the cards allow us see if there is a relationship between actual time and estimated time. When we are estimating future work we can check the actual times from earlier similar tasks as a way of improving our estimates.
Analysing the data in team retrospectives
We have been taking the cards into our team retrospectives and doing whole-team grouping and sorting exercises to see if we can spot trends in the way we are working. This achieves two goals; encouraging the use of data in retrospectives, and including the team in performing data analysis.
As an example, in a recent retrospective we organised the cards into a simple histogram based on the number of days that cards took to cross the board. We saw that we had an increasing number of cards that took longer than in earlier sprints. There were two downsides to having cards that flowed more slowly across the board; psychologically team members felt better when they were able to report progress at each stand-up, and that tasks that were smaller generally took less time to test and were less likely to ‘bounce back’ into Development.
Experimenting with new approaches
We agreed a retrospective meeting action that the team would look out for cards that had been in progress for more than four days and raise a discussion after standup about whether we could break the work down into smaller pieces. We have been doing this for the last few sprints and it has worked well.
Improving our methods
One improvement we’ve come up with is to use a dot above the letters we write on the card to show that there’s something blocking the card from being worked on. This allows us to see the impacts of blocks on the end to end (or cycle time) for a particular task.
Have you tried simple data collection approaches like this? If so, what did you find? I’d love to hear your experiences in the comments.