How to study the flow of work with kanban cards
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:
An example kanban index card with a column tally chart
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.
Kanban cards with tally charts arranged into a histogram as part of the team’s retrospective
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.
Related articles
How Kanban visualisations and conversations enable process improvement
After deciding to adopt a new process a key challenge is to actually start doing it. This is the story of how a team I’m working with decided to carry out code reviews as part of our process, and how our kanban board helped us.
The kanban board helped us visualise this new step in our process and allowed us to see that despite our belief and enthusiasm in introducing code reviews, we weren’t actually doing them. Reviewing the board at the daily stand up meeting provided visual feedback that lead to productive conversations about what might be stopping us and how we could improve. After we implemented new behaviours the board highlighted whether we improved and allowed us to continue to monitor our behaviour.
- The team’s kanban board after we’d got rid of the queues, with no cards at all in the Code Review column.
Introducing the Code Review process: a focus on ‘just enough process’
At the team meeting where we discussed a code review step we wanted to introduce ‘just enough’ process to make sure we would actually do it. We agreed to do the smallest thing that could work and to avoid being too ambitious or strict in how we defined code review. We came up with the following rules:
- If the person worked alone they needed to ask someone else on the team to come to their machine and discuss the code.
- The developer who needed the code review was responsible for pulling another person in to do it.
- If two people paired on the task it didn’t need a code review.
- If the task didn’t need a code review then the developer responsible would say so at the daily stand up and if the team agreed, it could skip that step.
What the board showed next: Good intentions were not enough
During the daily stand up meetings in the first week of working with the new process, the team reported many tasks as “finished development” when they hadn’t been code reviewed. We started moving those cards to the right of the “In Dev” column. Within a couple of days it was clear that we had a queue of index cards to the right of the “In Dev” column.
We had a brief discussion on the queue of cards to the right of “In Dev” and we agreed that it was a sign that we weren’t doing code reviews in an effective way. We said we’d focus on doing code reviews and ‘unblock the queue’ that day.
At the next day’s standup the queue was still there. This illustrates an important point; changing the way we work is hard and sometimes good intentions are not enough. At that day’s stand up meeting we had a deeper discussion about what was preventing us from doing it and identified two major issues.
The first issue was a concern about interrupting other developers. We agreed that one solution was to do the reviews directly after stand-up, since the team had all been interrupted.
A second issues was making it more obvious which cards were actively being worked on “In Dev” and which cards needed a code review. To be more explicit we created a column on the board between ‘In Dev’ and ‘Waiting for Test’ called ‘Code Review’.
By the next day’s stand up the queue of cards in Code Review was gone and we haven’t seen a queue of work build up in code review since.
Visualisation and productive conversations are key to process improvement
The kanban board showed us that our behaviour wasn’t producing the goals we wanted. Seeing this and discussing it as a team helped us understand more about what was stopping us and allowed us to experiment and test new solutions, as well as providing ongoing feedback about whether the new process step was working effectively.
What’s your experience implementing new process steps such as code review? Have you found visualising has been effective in reflecting how well your doing? Have you redesigned the way you visualise things in order to help you act more effectively? Let me know your views and experiences in the comments.
This post originally appeared on Platformability: Insight from Caplin’s tech team
Related articles
- Conversations for double-loop mindset changes with Kanban (benjaminm.net)
Hi, I’m 
Benjamin Mitchell's Blog 