We all want to design our Kanban boards to enable consistent, smooth flow of work all the way from start to finish. Unfortunately, that capability doesn’t come naturally and the way we often visualize our work processes can unknowingly cause dysfunction. In this post, we share some important things to consider (at least from our experience) when you want to design your board to enable great flow.
Focus on the work, not the workers
Do the column names of your board sound like the titles of the people in your team? Do you, or others in your team, often work in just one column of your board? If so, your board design might be built for resource efficiency instead of flow efficiency.
Resource efficiency is making sure that every individual person (in this case) is always busy – often at the cost of completing work. Flow efficiency is a focus on making sure that the path is easy and clear for work moving through a workflow.
A team that focuses on flow efficiency encourages collective ownership of work from start to finish. A team that focuses on resource efficiency tosses work over proverbial walls to the next column and moves onto something else without looking back (or forwards, in this case). A desire for flow efficiency doesn’t mean that everyone has to be assigned to everything all the time. Even when there is a primary assignee, a team is collectively responsible for getting work completed and team members may need to work on items in multiple columns at one time. These practices will put a priority on team performance over individual performance.
Purposefully handling cyclical activities
If your board is built with too much granularity, team members can be confused about what to do when they experience the cyclical portions of your process. Let’s tackle the most talked about scenario – testing!
Let’s imagine the team has a column on their board called Executing followed by a Validating column. The team’s policy is that an item moves from Executing to Validating when it is ready for external review. The team recognizes that bugs will be found during validation from time to time.
If the team doesn’t talk about how to handle the discovery of bugs when work is in the Validating column, they may think that the best course of action is to move it back to the Executing column (and repeat this process as many times as it takes.) Unfortunately, moving cards backwards causes us to lose visibility and data. (Read about the impact of backwards flow on data.)
Instead, the team can take steps to better accommodate this expected cycle. One option is to keep all cards in Validating until all found bugs are fixed. If they want to separate the initial validation from subsequent fixes, they can create a new column to the right of Validating called Fixing. Now when bugs are found, cards move there until are all fixed. The good thing about both of these choices is that data is preserved. We can still measure the original time spent in Executing AND tell how long it takes to complete since it first entered Validating.
Separate activity from wait
In order to really focus on improving the flow of work through your system, you will want to visualize when work is actively being worked on versus when work is ready and waiting for attention. This allows you to see important things like:
bottlenecks in different stages of the workflow as seen by large queues directly to the left
unreasonable amounts of work sitting in active column, masking additional wait time
whether or not you should focus on reducing wait or speeding up certain activities.
As you might have realized from this post so far, column names matter! A good practice is to use verbs for columns representing active work. This way they are not confused as waiting columns. Even better, break down your active columns into Doing and Done sub-columns! Visually separating active work from waiting periods allows you to use the Flow Efficiency chart more effectively.
Banish Blocked and On Hold columns
Our final tip for this post is to say goodbye to Blocked or On Hold columns – or any other column with the same purpose. While these columns do help us see wait, they do not represent a stage of a lifecycle that happens in a predictable place. Rather, they are fleeting attributes of work residing in a particular stage of its lifecycle. We use columns to display the lifecycle stages of work. So, we need to use other visual queues to denote fleeting attributes like this.
If you try to treat these attributes like a workflow stage by using columns, you are artificially picking a place in the workflow for it to reside. That wreaks all kinds of havoc! First, when you move an item into this kind of column, you can no longer see where in the workflow you experienced the wait. Did it get blocked in this stage or that one? Additionally, teams often use these pseudo-stages as a place to stash work so they can get around their WIP limits. This results in cycle times becoming longer and longer. Finally, when you are ready to put the item back into the real workflow, you have all of the data issues caused by backwards movement.
A better practice is to visualize this kind of wait in the place where it is incurred. Yes, that may make it more painful but… that’s kind of the point. It can be the forcing function that causes you to face the problems instead of hiding them in forgotten columns.
Add columns representing handoffs
Handoffs are expected parts of the workflow and, when they come back from the handoff, they can move directly to next column on the board. In this way they are different than blocked or on hold columns and it is a very good practice to represent them using columns.
The Key Takeaway
In the end, there are no board police to decide what is right and wrong. There is no external governing body to keep you from making certain decisions for your board. Instead, it is up to you to understand the consequences of the decisions that you make and how they impact your ability to meet your goals. Take a moment to consider your board and the points in this blog post and determine if you can better enable flow!