Setting initial WIP limits

When starting a team up with Kanban, one of the earliest questions is how to you set initial WIP limits. The simple rules we use are covered in this video.

Improve the work, not the metrics

One of the key practices supporting continuous improvement is making your work, and how you do the work, visible. This starts by tracking the progress of that work in a highly visual way, often by using a kanban board. Once that work is being tracked we can begin to gather that data and start to gain insights into where our biggest opportunities for improvement are, often by using the metrics defined in The Three Flow Metrics (Plus One).

The three flow metrics (plus one)

Some of the best indicators of team performance are the flow of both new information into the team and of value out of the team. If we can improve visibility into these indicators, and therefore the opportunities for the team to improve the way they work, it becomes possible for the team to support their organization in ways they couldn’t before. There are three standard metrics that are core to understanding the effectiveness of any flow-based system. The relationship between the three metrics is defined by Little’s Law. When applied to the systems used to enable knowledge work the law is usually restated in terms of Throughput, Work In Progress (WIP), and Cycle Time.

Lowering the Water Level - the metaphor explained.

Toyota has this metaphor of “lowering the water level” that they use when looking for opportunities for improvement. This video explains the metaphor and how it applies to your Kanban system.

Introducing the Kanban Guide

The Kanban Guide is a document from ProKanban.org, explaining the bare essence of Kanban for knowledge work. What are those things that are universally true in any Kanban system? What must be present if we’re to legitimately say that we’re using Kanban?

LEGO Exercise: Collaboration

Most teams are a bunch of individual silos that have become good at passing work between each other. This exercise is designed to show how real collaboration is different from the way we normally work.

LEGO Exercise: Technical Debt

Demonstrates the kind of debt we accumulate if we don’t refactor as we go. This exercise will let the attendees experience the pain of dealing with technical debt, rather than just understanding it intellectually.