Kanban et amélioration continue

To get your team engaged in the habit of continuous improvement, it can be helpful to spend a few weeks measuring simple metrics and running experiments from your retrospectives.

Begin by tracking four items: Total work in process, blockers, throughput, and lead time.

Total work in progress (WIP)

Whether you’re using physical boards or Kanban software, your total work in process is all of the tasks currently on your team’s Kanban board. It’s anything that anyone on the team has started but not completely finished. As you start limiting your work in process, you’ll start seeing this topline number decrease. As a gut check, divide your total WIP by the number of members on the team to get an average WIP per person. Does it show that each person is “doing,” for example, an average of 15 things? Does that seem like too many?

Blocages

A blocked item can’t move to the next stage in your process because of an issue. While similar to a bottleneck (both create delays), a blocker typically signals an unfinished dependency, a defect or an unavailable skillset. For example, a blocker may arise when you’ve sought information from an external source and can’t complete further work until you receive a response.

Focus on three things when measuring blockers:

• How often are items blocked?
• How long do they stay blocked?
• Where in the process do blockers happen?

In each daily standup, add “1” to the “blocked days” for that card and note where the block occurred.

Rendement

Throughput is the number of items completed per time period. An easy way to start tracking your throughput is to record how many items were completed (i.e., moved to “Done” and never moved backwards) at the end of each week. Track this number from week to week to see how changes made in your Kanban system affect how much total work actually gets done.

Délai d'exécution

The definition of lead time varies based on industry, type of work, and how much of your process is included in your lead time measurement. For the purpose of this exercise, lead time is defined as how long it takes a card to travel across the entire board.

The clock starts when a card is pulled onto the board and stops when it reaches the “Done” lane. If you’re using a physical Kanban board, record the start date on the back of each card; in Kanban software, there should be a “start date” or other field in the virtual card to track dates. Then, when the card reaches “Done,” record the date and calculate how many days (or working days) passed since its start date.

Many calculations are possible with lead time and throughput metrics. Keep it simple in the beginning and only record the average lead time of every card that was finished that week (i.e., the cards you counted to measure throughput).

On an ongoing basis, compare these four metrics to see what effect they have on each other. As you reduce the size of queues in your system, it should start to reduce your average lead time.

As you experiment with ways to manage blockers more effectively, you should also see lead time reduced. As you continue to limit your WIP, and work together as a team to complete work collaboratively, you should see throughput improve.

Take time during every weekly retrospective to record data for blockers, start date, completed date, throughput and lead time. As you get better at analyzing these metrics, you’ll want to segment them by card type, priority or another dimension that’s important to your team.

For example, you could say that your lead time for standard priority items is an average of 8.5 days but that your lead time for production break-fix items is 1.8 days.

At each weekly retrospective, calculate and record:

• Throughput: the number of cards completed this week
• Lead time for each card (completed date and start date)
• Average lead time for this week
• Cards completed with > 0 blocked days
• Total blocked days
• A list of places where cards were blocked

Tally the above for three to four weeks before you begin to use retrospectives to run experiments.

An experiment, in this instance, isn’t much different from a basic scientific experiment. Evaluate the current state, form a hypothesis, test the hypothesis with an experiment, measure the result, and then draw a conclusion.

As a team, review your throughput, average lead time, blocker data and total WIP metrics. Have the team pick one of those four metrics for your first experiment.

For example, if your average lead time for the past three to four weeks is 11 days (varying between two and 19), you might decide to shoot for less than 10 days.

If your blocker data suggests that you might be leaving items blocked longer than necessary, your experiment might be to modify the way your team responds to blockers. Perhaps your team will decide to adopt a “stop the line” mentality; if a card is marked as blocked, it’s “all hands on deck” to remove the blocker as quickly as possible.

Or, if your throughput is three items per week, you might decide to try to increase it. If your total WIP still says that you have, on average, seven items in process per person, your team might try to reduce total WIP to see if it affects throughput. You could then look for queues in the process where you could reduce the WIP limit and watch to see what it does for throughput.

One final example, coming at it from another direction. If your blocker data suggests that you could improve by managing blockers differently, your team could adopt a change in policy for how blockers are managed and monitor lead time, WIP, and throughput to see what effect the policy change has on those metrics.

As you continue to pursue improvements to your process, follow these ideas to keep the energy up among your team:

• Focus your experiments and metrics on improving one or more of your team’s capabilities, whether it’s quicker delivery, predictable delivery or the capability to deliver higher quality, measured in lower defect rates and instances of rework.
• Continue to encourage team ownership of the process and focus improvement efforts on the Kanban system, rather than individuals.

From this point forward, think of your retrospectives as a place to formulate and evaluate experiments. You may have more than one experiment running at once, but always run at least one.

Kanban is an evolution, not a revolution. The longer you work with and observe your process, the more you’ll see ways for improvement.

Running experiments from your retrospectives can help you understand the why and how of your process so your team can make small, incremental changes. It’s the best way to:

• Achieve a sustainable Kanban system
• Increase business value
• Keep your team engaged in continuous improvement