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)
Conversations for double-loop mindset changes with Kanban
You can watch the video of my talkfrom the Lean Software Systems Consortium (LSSC12) conference in Boston earlier this month.
Using the Ladder of Inference to produce Double Loop Learning conversations
Visualising work is a key part of the Kanban Method. In many situations it can lead to people realising there are problems or opportunities for improvement, which can be successfully accomplished by simply changing behaviour (single loop learning). However, in some situations, particularly where there could embarrassment or threat, these change may need challenging existing mindsets (called double loop learning). Using practical examples drawn from directly helping teams, this talk will present a model for understanding how we can proactively engage in conversations that increase the chances of capitalising on the value that visualising the work provides.
Here’s a review from Jack Vinson
Benjamin Mitchell used the topic of “what comes after visualization” to start a conversation of what to do once you’ve got some visualization. He particularly talked about Chris Argyris‘ Ladder of Inference (and expanded by Peter Senge), which he used as a way of thinking about how we see things and how we interact with our colleagues and coaching / consulting clients. He particularly warned about staying away from making assumptions and working at the levels of Select and Describe (rather than Explain, Evaluate, Propose Actions). Since Argyris is one of the promoters of double-loop learning, it is not surprising that Benjamin discussed the Mindset -> Actions -> Results learning loop. I liked the discussion of taking different actions to get results vs changing one’s mindset because the Actions aren’t getting anywhere like where they need to go.
Here were some reactions from Twitter:
Let me know your reaction in the comments.
Effective decision making: avoid confusing discussions with decisions
A key to effective decision-making is to avoid confusing discussions with decisions. Discussions are important for ensuring that the widest range of information is available to make a decision, but treating a discussion as a decision is likely to lead to confusion, frustration and ineffective actions.
Open discussions are important, but they’re not the same as making a decision
Open discussions are important because they allow everyone to understand the problem, the possible approaches and the concrete proposals for moving forward.
A pattern I’ve seen with teams that struggle to make effective decision is assuming that just because a difficult topic has been discussed there is a shared understanding of what has been decided and a commitment to act consistently with the decision.
Often these assumptions are not stated explicitly, leading to statements like “we decided a lot of things in that meeting” when in fact there weren’t any decisions. This can be followed up later by frustration over “how come we are discussing this again? I thought we decided on this in a previous meeting!”
It is important to be explicit about any decisions made during a meeting. One approach is to highlight them visually, which I’ve used when using a simple kanban approach to meetings.
Some basic characteristics of effective decision making include:
- Being clear about the process used to make the decision
- Allowing people to raise any concerns or interests
- Explicitly stating what the decision is
Have you been in situations where you or someone else has confused discussions from decision making? Tell me about your experiences in the comments.
Hi, I’m Benjamin. I hope that you enjoyed the post. I’m a consultant and coach who helps IT teams and their managers consistently deliver the right software solutions. You can find out more about me and my services. Contact me for a conversation about your situation.
Image Credit: CiscoANZ on Flickr
Removing the bubbles: solving bottlenecks in software product development
A challenge with software product development is visualising the work so that you can spot where there are delays in the process of converting ideas from “concept to cash”. This post shows how a cumulative flow diagram helped identify a pattern of queues over time. Removing these queues had many benefits such as fewer errors, increased team communication and improved team capacity.
Make the work visible
The first task is making the work visible. In knowledge work, such as software development, it is difficult to see the work being done, which is why a visualisation approach such as kanban can be so useful. Here’s a view of a kanban board from an earlier client team:
The kanban board is useful for a “moment in time” view, but it’s not possible to easily see patterns that might develop over time. Looking at the kanban board on a particular day doesn’t make it easy to answer questions like these:
- How long have these work items been waiting in this column (stage)?
- How long does it usually take for work items in this stage of the process to complete?”
- How often do we see queues in this step? How long do they last for?
- Are these queues a special event or do they happen regularly (touching on the difference between common and special cause I’ve mention in an earlier blog)
To find these answers and look more clearly for patterns over time we built a cumulative flow diagram (CFD, also called a ‘finger chart’) by counting the number of post-it notes in each stage (column) in the team’s process after each daily stand-up. Unlike my earlier post on using three forks and a hand-drawn chart to help a team improve in this case we used an Excel spread sheet.
Visualise the work over time to better understand queues (‘bubbles’)
The cumulative flow diagram for this team helped make visible that there were consistent queues of work in the functional testing and acceptance testing processes over time. These queues are visible as “bubbles” that develop in the cumulative flow diagram. See the highlighted in orange and red stages below (click the image for a larger version).
Do the detective work necessary to understand what causes the queues (‘bubbles’)
Around two-thirds of the way through the above chart (which covered about 36 weeks) we decided to focus on studying what was causing the queues to develop in functional and acceptance testing.
The functional testing involved someone other than the person who developed the functionality (user story) validating that it worked functionally (there were no obvious errors). Once functional testing was complete then the acceptance testing stage was performed by a business analyst or the product manager.
The team were releasing to production every second Wednesday. On the middle Wednesday the person who did the functional testing switched to doing the integration testing (ensuring the features which were created as a package to go to production worked individually and combined, as well as running a set of manual regression test scripts to make sure that the new functionality hadn’t had any impact on the rest of the website). During the week spent on Integration testing, no functional testing was done, which we believed was the cause of the queues or orange bubbles on the chart.
Creating a new policy to reduce the queues (‘bubbles’)
We sat down with the person who performed the Functional and Integration Testing and mapped out the schedule of their work across the fortnight between releases (see the hand-drawn diagram we came up with below).
We also mapped out a new “policy” that described what the person doing testing did for for the week spent integration testing:
While performing the Integration Testing in the week before the release, if there are any work items in the Functional Testing column, spend up to an hour each day doing them.
We experimented with the new policy for the last third of the cumulative flow chart. The cumulative flow diagram showed that the queue (bubble) in the Functional Testing (orange) step virtually disappeared, as did the queue in the Acceptance Testing (red) stage. The CFD not only highlighted the initial problem, but it also validated the experimental change we made in policy resulted in an improvement (it allowed us to answer the critical question – “did the change we made to our process result in an improvement?”)
It’s the system!
This example demonstrates how changing the way the work is structured can produce improvements without having to change the work that team members were doing. This example shows that the queues caused by the way the work was structured (e.g. the system we had designed) and not the work of the team members. It speaks to Deming’s ‘provocation’ that “95% of the variation [in how long the work takes] is due to the system and not the individuals”.
Benefits
There were many benefits to the changes that we made above:
- Removing the queue in functional testing meant that if a problem was found then the developer got faster feedback. Getting feedback faster reduced the time it took a developer to “get their head back into the issue” and fix the problems. It also improved the communication between members of the team – the developers were more likely to speak to the person who did test at stand-up about the work that was coming because they knew it would be tested quickly, rather than potentially sitting in a queue waiting for a week.
- By reducing the bottleneck in Functional Testing also reduced the same bottleneck in Acceptance Testing.
- The reduced “thrashing” from having issues discovered close to the release date meant the team’s capacity to do work increased.
- As there were fewer queues it reduced the pressure on team members, helping them feel less rushed which improved the quality of life for the team, reduced “rushing” leading to better quality and team morale.
Hi, I’m Benjamin. I hope that you enjoyed the post. I’m a consultant and coach who helps IT teams and their managers create more effective business results. You can find out more about me and my services. Contact me for a conversation about your situation and how I could help.
Improvements on using a simple kanban for effective meetings
Since I posted last week about using a simple kanban to structure workshops, I’ve used the technique with several other clients and have made some subtle but useful improvements.
Here are the key improvements:
- Making time constraints explicit. Ask everyone at the start of the meeting “are there any time constraints you have?”. Write a post-it for anyone that is coming late or will be leaving at a different time than the others. Use a “time constraints” column between the “to do” column and the “doing” column, where the post-it notes are queued in time order. Placing the column here allows people to see what time constraints need to be considered when choosing the next most important topic. If there are known breaks such as morning tea or lunch time then put these in the queue as well. As the time constraint is reached, then pull it into the “done” column (this means the done column can be read from top to bottom as a hi story of the meeting).
- Defining key questions on the “to do” column. I’ve been writing the key questions to ask when focussing on the “to do” column. The benefit of making them explicit is that it has been easy to ask someone else to “run the board” and facilitate the meeting. This has been useful in giving clients the ability to practice running for themselves, which is more powerful than me demonstrating it to them. The key questions are:
- Is there anything else to add?
- Is there value in re-ordering the backlog (to do queue)?
- What’s the next most important item to start
- Adding an “any actions?” exit criteria to the “to do” column. Once the agreed time limit is reached, or earlier if anyone feels the current topic has finished being discussed, ask “are we done? would anyone like longer on this current topic?” if there’s no agreement about adding more time, then ask a second question “Are there any actions we need to record?”. If any actions are needed then these are added to the “actions” column.
- Add an “actions” column to the right of “done”. I’ve added an “actions” column to the right of “done” where any actions agreed in the discussion can be put.
Having run four or five workshops like this in the last week, it is critical is to be strict on not allowing discussion to continue once the timer has gone off (I use the marimba noise from my iPhone’s timer and deliberately let it ring several times if people are talking past the time). I stress that it’s OK to propose to take more time and to see if there’s consensus (by asking ‘Does anyone have a concern if we continue for X more minutes?’), but allowing people to keep talking makes it too easy to continue talking too long.
Some other observations and things I’m experimenting with:
- Estimating times. In a few situations I’ve tried asking people to estimate how long they think a topic will take. This can be revised before the task is started. Once it is started the time can be updated by adding “+5” for example, when five extra minutes are added. I’m just experimenting with this at the moment. It has been useful at highlighting that a group has been underestimating each topic, which made people add more realistic times to future topics.
- Inviting people to write the post-it notes, re-arrange or track actions themselves. Several times I’ve found myself doing the work for the clients, by writing the post-it notes, re-arranging them or tracking actions. I believe that the effectiveness of this approach can be enhanced if the participants have the experience of doing the work for themselves. Also, it reduces the possibility of error by writing the wrong thing.
- Add a section for “policy changes” under the “actions” column. I’ve also been experimenting with “policy” changes for agreements around how the team might be working. I use the format “It’s OK to …” An example from a client this morning was “It’s OK for tasks to move tasks back into ‘to do’” or another one “It’s OK to split a larger task into smaller ones at any time”
- Keeping a cumulative flow chart. This morning I was working with a client who wanted to try using a cumulative flow chart to record what occurred on their team kanban board. In order to illustrate, I got them to hand-draw the chart (see last week’s post on using three forks on a hand-drawn cumulative flow chart as an example) by counting the number of post-it notes in the columns (we ignored actions as these were by-products of discussing topics, rather than topics themselves). The client reaction was great, with the manager saying “I completely get what the chart is about now” and the result was we only need to spend two minutes actually talking about it (to help others in the team check their understanding). Here’s the chart they produced:
Client Response
The response from clients has been really positive to this approach. The client this morning said they were amazed how much they achieved in a short workshop. They also said they felt more energized from that meeting than they had when we’d done a longer meeting without using this kanban format! I’ve also used it with little or no introduction in meetings and it’s been very successful.
I’d welcome hearing further about your experiences, or your views on what I’ve mentioned, in the comments.
Using a simple kanban to run effective meetings and workshops
I’ve found using a kanban a productive approach to structuring and running meetings, workshop and presentations. Many meetings or workshops are often run from a fixed schedule that isn’t easy to update or change and also isn’t visible to the participants. I wanted to find a better way of structuring the day which balanced some competing goals:
- Allow participants to take as much responsibility as they were comfortable with adding, removing or re-ordering the topics covered.
- Acknowledge that as a content expert on many of the topics it’s appropriate for me to offer suggestions about which topics are likely to be most relevant, and the order and approach to presenting them.
- Find an approach that addressed the previous two goals without spending longer than necessary talking about the process during the meeting.
The solution I came up with was to use a simple kanban system of post-it notes. UPDATE: I’ve blogged a few improvements on using a simple kanban to structure meetings
Here’s how it worked:
- At the start of the day I presented a list of topics/activities we could cover in a suggested order with suggested timings (e.g. 30 mins) in a “to do” column. At this stage there was an opportunity for the group to add or remove topics or re-arrange the order.
- I introduced a “doing” column with a (work in process – WIP) limit of one topic at a time. When we decided to start a new topic there would be a quick discussion about how long we wanted to spend on the topic, which we wrote on the post-it note.
- There was an exit criteria on the “doing” column, so that when we reached the time agreed we stopped and asked “is everyone happy to move on?” before it could move to “done”. This encouraged a focus on the coming to a close on topics before starting new topics (“stop starting, start finishing”)
- If anyone wanted to continue then they had the option of creating a new post-it note that could be added to the ‘”to do” column that could be chosen to continue.
- We then went to the “to do” column and checked if anyone wanted to add a new topic, re-arrange the list of topics and most importantly, decide which task to start next.
There were many benefits from using this approach:
- It allowed the participants to take as much of responsibility for what we talked about as they wanted and left open the possibility for them to take more responsibility at each “which topic next” decision point during the day.
- The list of ordered “to do” topics was visible throughout the day, so people could make more informed decisions about which topic to start next. Nearing the end of the day it helped the participants focus on spending their ‘time budget’ on topics they thought most valuable.
- The overhead of this approach was minimal.
- Discussing how long the group wanted to spend on a topic helped me gauge how valuable the topic was. In one situation participants asked for a 10 minute overview of a topic which really focussed how I presented it. We also adopted the practice of asking someone to say what was most important about the topic, or what the key outcome they wanted from a topic was as the topic started (similar to defining the success criteria on a software development task)
- It gave people an experience of working with kanban that increased their understanding of the approach.
- Whenever discussions went off-track we stopped and asked “do we need to add this as a new ‘to do’ topic?”
- Rather than having to structure the list of topics at the start of the day, when we have least information about what will be useful or interesting to the group, we were able to defer this decision by making lots of smaller “what’s the next most important task to begin?” decisions as we went.
I’ve used this technique several times in workshops and meetings and continue to find it helps increase the productivity of the meeting by ensuring the group are engaged in discussing exactly what they want to talk about for the time they want to talk about it. Have you used a similar approach? What’s your experience been?
Thanks to @HakanForrs and @YuvalYeret for discussions about Jim Benson’s Lean Coffee format which inspired my approach.
How three forks on a hand-drawn chart helped a team improve
After visualising the workflow of a recent client’s software development process, and showing where the work was, the team realised there was a queue of tasks that had been developed and were waiting to be validated (‘tested’). The team decided to move from a “I just do my task” approach to a “whole team” approach where they focussed on making a single task flow across all of the development process with minimum delay. They decided that rather than continuing to do more development and hoping that the validation work would eventually complete, the people who did development would go and help those who were validating the work.
The problem was that the Development Manager (who believed his role was to maximise the number of development tasks completed) was concerned that if the development work stopped to reduce the queue in validation, then eventually the validation step might run out of work to do.
In order to address the Development Manager’s concern we went to the hand-drawn cumulative flow diagram (sometimes called a finger chart). The cumulative flow diagram was drawn each day, by the team member who ran the daily stand up, by simply counting the number of tasks in each stage of the workflow. The x-axis shows time in days, and the y-axis shows the number of tasks in each step of the workflow.
As we had a couple of weeks data it was possible to extrapolate the rate at which the validation work was being completed. We were also able to extrapolate the rate at which development work was finishing. In order to do this extrapolation we grabbed the nearest straight-edge items we could find, which turned out to be forks!
As the photo shows, the forks indicated that it would take about two weeks for the validation step to run out of work to do if most of the people doing development spent their time helping do the validation. This data allowed the Development Manager to feel more comfortable about allowing the strategy a shot for a week, after which it could be reviewed.
This example demonstrated the benefits of using quick, low-fidelity data collection methods. The discipline of hand-drawing the chart each day meant that it was better understood by the team members than if it had been automatically produced in an electronic tool. The team were also able to see how the data could be valuable, as it allowed them to discuss the Development Manager’s concerns with data rather than just opinion.
In the end, the strategy to work as a whole team and focus on the validation step turned out very well. The team were able to reduce the time it took to validate tasks, providing quicker feedback to development (which reduced defects), increase the amount of work they got done at the same time as improving the team’s morale.
Do you have stories of using quick, low-fidelity data collection techniques to improve team performance?
Benjamin Mitchell's Blog 