Kanban is a way to visualize work flowing through a system that allows a multi-dimensional view that generally is not possible with other visualizations such as status reports. Setting up a Kanban to see the current status is pretty simple. Using Kanban to its full potential to lean out a process and increase the flow of value… that’s not so easy.
Creating a Basic Visualization
- Identify the “system” which you are visualizing. The system could be an assembly line of cars, a software development life cycle, or your personal task list for the day.
- Identify the item types that will flow through this system. If this is a personal task list, you may have work items from your job, personal errands you need to run that involve traveling around town, and chores you need to accomplish. If this is a software development life cycle, the work item types will likely be projects if you work in a traditional environment. An agile team doing software development might have four types: new features, feature changes, feature removals, and defect fixes.
- Define the start and stop points. What are the boundaries before and after which the items either do not exist or are the concern of someone else? Before the start place items not started. After the finish, place items considered completed.
- Define the workflow. What steps do these items go through? The most basic series of steps is: to-do, doing, and done. Break apart “doing” into more steps when you need to visualize more detail. Be careful not to define a complex workflow of excessive detail where small changes in state do not inform decision making. You don’t want your Kanban to create complexity rather than simplify it.
You can now start placing work items in the system to reflect the current status of everything today.
Adding Restrictions to Increase Flow
Kanban isn’t just a visualization system. Kanban is also a tool that will help you add restrictions to the system and measure flow to increase the value the system produces. The restrictions you might add include exit policies on work states to prevent work items from arriving at later states as defects that require rework.
- Exit policies on each state of work set the quality controls that must be met for an item to be pulled forward to the next state. Think of exit policies as a definition of done on each state that work passes through attempting to increase the percentage of items that are complete and accurate as they arrive at each new state. You could start with a policy that defines what allows an item to start and what allows an item to be considered finished. Experiment with more policies to find more possible improvements. Exit policies help increase quality upstream, thereby reducing rework and freeing up WIP for other productive work.
- WIP Limits are numerical limits on the number of work items that can be active in a state, a set of states, and/or all of the in-process items at a time. WIP limits are a restriction which help people focus on a few things at a time to increase the speed of processing. Lowering WIP limits, not raising them, helps increase flow through the system.
- Reduce Batch Size. The smaller work items are, the less complex, and therefore the faster they flow through the system with fewer defects. However, as work items shrink, eventually they become small enough that the overhead of managing the high number of them consumes any benefit. No item should be so small that when complete a customer or someone waiting for work to be done does not have something usable/valuable. Example: if an item is to mow the grass, breaking that item into smaller items such as “Add gasoline to mower” and “Put bag on the mower” are of little value to a customer or yourself. However, splitting it into mowing the front yard vs the back yard is valuable.
Establish Pull
Kanban is designed to be a pull system. That means that items are not pushed forward to the next state when finished in the current state. Rather, the next state, by having empty room for it, pulls it forward.
Empowered people are able to limit the WIP in their systems. When there are others allowed to push items into the system without restriction or approval from those doing the work, then limiting WIP is impossible. In order to limit WIP, the people doing the work must be empowered to start work as they deem appropriate based on their availability.
WIP Limits create pull. Without WIP limits in your Kanban, it is difficult to establish pull and there will always be push energy in the system.
Pull creates transparency. If items stay where they are until someone pulls them to work on them, then we know if they are being worked on. If we push them forward, then we don’t know if they are being worked on or not. The items may have been pushed into an invisible queue. That is one way we end up with watermelon status: green on the outside, red on the inside.
Transparency enables improvement. If we can see where everything is and understand why everything is where it is and how it got there, we can improve things.
Measure Flow
There are four important measures:
- Work in Process (WIP) – the number of items currently in-process.
- Item Age – the number of days since any item has started that has not finished. You can measure item age since starting in the whole system or since the item was pulled into the current state.
- Throughput – the number of items finished per time period
- Cycle Time – a stopwatch measure of how long it takes an item to complete a journey through the entire system or through one or several states. Any stopwatch time between any start and any finish is a “cycle time.” There is no such thing as an official cycle time defined as measuring a specific thing. How long it takes you to drive to the grocery store from the moment you close the door on your car until the moment you set foot in the parking lot is a cycle time. Set up cycle times to discover bottlenecks and reveal performance.
In all four measures, use the same time period. Do not measure cycle time in days and throughput in weeks. All of your measures should use the same time period.
There are no zero time periods. The moment you pull an item into WIP, the cycle time is one time period. If you are measuring in days, the moment you start work on an item, the cycle time is immediately one day. Even if you finish the item in 30 seconds, if you measure cycle time in days, count it as a one day cycle time.
The most important measure is item aging. If you meet regularly to review the Kanban as a team to help work move along rather than just be informed of where it is and fuss at people to work faster and harder, then focus on item aging. In particular, look at the right side of the board first and work your way left looking for the items with the highest aging. Those are your problems.
Tools to Measure Flow
You do not need a tool in most cases. If the number of items being completed is more than just a few a day, then you may be creating overhead by making items too small in your work to reduce batch size. Or, your kanban may be part of a larger ecosystem of systems, and you might be wanting to receive information about how everything is flowing across hundreds of people at once.
For an individual, or a single team, automation to count throughput, WIP, item age, and cycle times is waste. You can easily do this on your fingers and manually record the numbers somewhere with ease.
Kanban Myths
Columns are required. A kanban can have columns, or it can flow vertically through rows. Any way you prefer to establish a visual model of the stream of work – even in an S-shape if that works for you – can be a kanban. The most common way is vertical columns of states and work flowing right to left. But there are no Kanban police coming for you if you do it differently. Experiment to see what works for you.
Should I use Kanban or Scrum? Scrum and Kanban are not alternatives to one another. A Scrum team can use Kanban. A team could use Kanban with so many restrictions that it is essentially Scrum using Kanban.
Scrumban. I think this is just a word that means it is a Scrum team using Kanban. There are some books presenting it as its own third thing, but really, I think it is that simple.
Kanban is Agile. Kanban could be used to help with agility, but no one at the 2001 Agile Manifesto signing knew anything about Kanban, and there was no Kanban person in attendance. Kanban was still a manufacturing idea back then and hadn’t really broken out into software. You don’t have to know anything about the Agile Manifesto or care about it to implement Kanban.
Kanban is waterfall. Waterfall is an SDLC where everyone participating in a project completes a phase of work and queues up at an approval gate. The gate is lifted, and all of the work together moves into the next phase. In Kanban, every work item moves through the system without regard to other work moving through the system. Items complete individually. Also, a kanban may represent a small part of a system, which does belong inside a predictive phase gating system, or it may represent an entire system from idea to completion.
Based upon the work of Daniel Vacanti and advice from Frank Vega. See the Kanban Guide at https://kanbanguides.org/