Making a cake is a process.

Making a cake is a process.

Getting started using Kanban is deceptively easy – there are just three steps. The first is visualizing the flow of work, the second step is setting work in progress (WIP) limits and the third is documenting process policies. Visualizing means developing an understanding of the steps that are taken to complete a unit of work, such as a project. A WIP limit represents the team’s normal capacity to handle work in each of the visualized steps. The third is to document or create the policies that will govern the process, such as classes of services and how interruptions and expedited items will be handled. The process is simple and concise, however, the devil is in details.

Visualizing the flow of work begins as a mapping process. Initially, use a technique like value chain mapping , activity network diagrams or just plain process flow charts to document your process. Diagraming the process flow on paper or in a tool before translating it to the Kanban board allows the team to discuss and make sure the flow accurately reflects how work is done. The flow below represents the process I use to create the interview segments for the Software Process and Measurement Cast.

Software Process and Measurement Cast process flow.

Software Process and Measurement Cast process flow.

When you are convinced that you have the process laid-out correctly construct the Kanban board. If using time-honored methods of a white board or brown butcher paper, I typically define the start and end points for the flow and then fill in the middle parts (adding a column for the backlog at the beginning and a column for done at the end).

Generally there is a lot of pressure to “redesign” the process as soon as you have put down on paper, on a physical Kanban board or into one the great Kanban tools. Resist the urge to change the process until you have begun to use the board and see where the bottlenecks appear. Waiting to see how work flows allows process improvements to be made based on data rather than opinion. Also using the work flow visualization as a feedback mechanism will allow the team to reverse changes if they don’t work.

The next step is to set the initial WIP limits. This can be a bit of an art. One method is to set the limit for each step at one for each person assigned to the step. For example, my podcast flow would have a WIP limit of one for each step (my podcast empire is . . . me). Another method is to use a recently completed project as an example and walk through the process with the tasks to estimate the limits. When using this method, the team should continually ask whether each team member was trying to work on more than one item at a time. This an important question because multitasking is an indicator of violating WIP limits. Another method is to simply begin a project. This is a variant of the one WIP per person method. In this method, each team member begins by pulling a piece of work they can do. This number is used to set the initial WIP limit for the categories of work that are initially possible. As work progresses more and more of the process will be used and WIP limits identified. This method can mean that initially some team members will be engaged in work that is not their specialty. This is where having team of specializing generalists (a person that can do more than one thing, but does have a specialty) comes in handy, as team members can pitch in and help in more than one step. Regardless of the method used each person should focus on a single task at a time. Adjust and experiment with WIP limits to minimize the time it takes for work units to move through the process.

The final step is to document the policies that will be used to govern the process. All policies should be explicit and transparent. It is very hard to govern a process with hidden policies. Also when you have to guess what the process is, it very hard to test the policy to see whether it can be improved. Polices that need to be defined include the WIP limits, classes of service, how to handle interruptions and how temporarily breaking WIP limits will be handled. I generally have team members and their managers define the initial set of policies as part of a project or support chartering process. The chartering process gives the team a chance to get all of the rules on the table, discuss them and then cleanly begin.

Beginning to use Kanban is a fairly straightforward three-step process. One, map your current process and convert it into a Kanban board. The board is in essence an overlay on top of the process you use today, which makes beginning to use Kanban less contentious. Make changes to the process only after you begin using it and you have visual evidence of a bottleneck. Two, set initial WIP limits. This part of the process might require some experimentation, however always err on the side of overly constrained as it will always be easier add to the limit than decrease the limit (this is just human nature). Finally, define the policies that will govern the process. The whole team and their managers should commit to be governed by the agreed on policies. Three steps . . . no more, no less. Each one will require careful consideration and discussion, which is why the devil is always in the details.