Kanban in 5 Easy Steps

The primary goal of a Kanban system is to maximize the delivery of value to the customer by steadily increasing the speed and quality of output, simultaneously, until the system reaches an optimal level. Only when you have stable, smooth flow of work is predictability of delivery times even possible.

This post was originally published by Neo Innovation on their official blog. I am republishing it here so that Startup Patterns readers can have easy access to tools and tactics for small teams, Kanban being one of those tools.

Kanban — A Crash Course from Sam McAfee

The Basics

There are five main steps to implementing a Kanban system:

1. Visualize your current workflow.
2. Apply Work-in-Process (WIP) limits.
3. Make policies explicit.
4. Manage and measure flow.
5. Optimize iteratively with data.

Let’s look at each step in turn.

1. Visualize your workflow.

• You map the process you currently use to deliver work product to the customer on a visual control board, either physical or digital.
• Each column represents a step for adding value to a unit work. Make sure you map every step from conception to delivery to the end consumer.
• You may optionally have columns in between steps representing necessary “wait states” or buffers.

Pro Tip: A Kanban board is not intended to be in a permanent configuration, at least not for a while. The idea is to iterate the board configuration periodically, as a team, to find the optimal configuration. Retrospectives can be used to surface opportunities to improve the board configuration.

2. Apply WIP constraints.

• You implement WIP constraints in Kanban by only allowing a limited number of work units to be in any given column at a time.
• The exact limit on a column depends on your context, but I have found the best number to be the number of individuals (or pairs) who do work in that step.
• Work does not move into the next step until a space opens up for it.
• The effect is a system where the end consumer gradually pulls work items through like a vacuum.

Pro Tip: This is both the simplest and most powerful practice, and yet it is the one that is most counterintuitive and faces the most resistance. Despite overwhelming scientific evidence to the contrary, people cling to the idea that if they work on more things at the same time they will get more done, more quickly. It is simply untrue.

3. Make Policies Explicit.

• Assign different classes of service to different work items. Common classes are “Standard” (FIFO), “Expedite”, and “Fixed Date” classes.
• Some classes are allowed to skip to the front of the queue. The idea is that if everything is FIFO, a high cost-of-delay item can get stuck waiting behind a low one just because it arrived later in line. Or an unanticipated item causes other planned work to stop, while you address it.
• If you split demand into classes, while some items may end up with slightly longer lead time, overall the flow is more smooth and regular.
• We want to increase throughput, no doubt, but in business predictability is often worth a slightly longer average lead time. High throughput is less valuable if it is bursty and unpredictable.

Pro Tip: Reserve some capacity for unexpected work or work that had a fixed delivery date, perhaps using an 80/20 distribution. What this does is smooth the flow of work for standard items, and still allows for interrupt-driven, fixed date, and emergency work to use the “fast track lane”.

4. Measure and Manage Flow.

• We are optimizing for speed and quality simultaneously. The metric we use is cycle time, or its mathematical equivalent, throughput.
• Cycle time is calculated by the average time it takes a unit of work to move through the system.
• Throughput is the number of units that move during a given time period.

Pro Tip: A Cumulative Flow Diagram (CFD) is the best visualization for this, but it takes some getting used to. Most people are used to a Control Chart. A real, robust tool would have both and calculate them for you, but they aren’t hard to build by hand.

5. Optimize Using The Scientific Method.

Just as you would state a hypothesis as part of running a feature experiment , it is a good practice to think carefully before you modify the board willy nilly.

• Declare a hypothesis about how a change to the board will result in a specific, measurable outcome.
• Make the change, and allow the team to use the board in that configuration for a period of time.
• Measure whether it actually improves performance, and change it back if it doesn’t work.

Final Thoughts

Stories should be sized as the smallest shippable units of value. You don’t need separate cards for pieces of implementation (don’t have “chores”). The story is not done until it’s shippable. Don’t start another story if you are at your WIP limit. If you’re having trouble tracking what everyone is doing, your stories are still too large.

You should be aiming for continuous delivery, even if it’s just to staging, with a manual last step for deployment. You can keep things pull-based by using WIP constraints at point of delivery, where the client or customer accepts your work. The client pulls releases when they are ready. That sets the pace for the rest of the system up-stream. If this leaves some of the engineers idle some times, T-Shaped team members (more senior, cross-trained) can swarm to emerging bottlenecks. Never load senior folks to 80% or higher capacity. Let them float to put out fires, and smooth flow.

Kanban is an incredibly powerful method for managing your workflow process and gradually improving your performance. It encourages all of the core best practices of agile, like cross-functional teams, fast feedback, co-location and pairing, and continuous integration and deployment. For a modern software development team, Kanban is your new best friend.

From: Kanban — A Crash Course from Sam McAfee on slideshare.com

How are your teams doing?

Having trouble? Let’s talk about it. Set up a time for a free consultation here: https://calendly.com/sammcafee

Originally published at www.startuppatternsbook.com on September 9, 2015.