How do Teams Continue to Win during Turmoil?
We had a big snow this week. Twelve inches total, a forty-three year record in our part of Puget Sound country. We lost power for ten hours – no furnace, no computer, no lights. No problem – I cozied up to an emergency kerosene stove and opened Jim Collins’ new book, Great by Choice, a study of winning behavior when confronted by uncertainty – with comparisons between companies that win and companies that languish.
I was especially fascinated by the parallels I see between the behavior of Jim Collins winners, and key concepts we teach using Kanban to cope with uncertainty. Collins begins with a story of two competing teams far removed from our 21st century business world. The location was Antarctica. The year was 1911.
The competition was a race to the South Pole between a Norwegian team led by Roald Amundsen and an English team led by Robert Falcon Scott. Each team’s leader was an experienced Antarctic explorer. Each team departed its home base at about the same time. Each faced a roundtrip of 1400 miles, all of it ice and snow. What was different? The Norwegian team planted its flag at the South Pole on December 15, 1911 and returned safely to home base by January 25. The British team reached the Pole on January 17, 1912 – and never made it back, freezing to death near 79 degrees latitude.
The point of the story is that Collins attributes the difference between Amundsen’s success and Scott’s tragic failure to some fundamental concepts that apply to business management in the 21st century. I was almost startled when I realized that those same concepts apply to the Kanban method.
These concepts are:
1. Thorough advance study.
2. Limit work-in-progress.
3. Manage risk by providing buffers.
Amundsen lived and studied with Arctic Eskimos before going to the South Pole. Among the practices he observed was how the Eskimos never hurried, moving slowly and steadily, “avoiding excessive sweat that could turn to ice in Arctic temperatures.”
The Norwegian team, traveling on skis and using dogs to pull its sleds, set an attainable daily goal. And when they had reached that goal, the team stopped for the night. They set work-in-progress limits. They managed risk by providing buffers. They provided three tons of supplies for five men. The British team, using ponies to pull its sleds, carried one ton of supplies for seventeen men. The Norwegians placed 20 pennants to mark supply depots. The British placed only one. Amundsen brought four thermometers to measure altitude. Scott brought only one – and it broke.
KANBAN PARALLELS
Studying is the essential first step to designing a Kanban system. Studying the “what and why” of an existing system’s performance leads to understanding improvements and understanding what prevents goals from being achieved.
Limiting work-in-progress (WIP) is a self-imposed constraint and a core practice of Kanban, where a limit is set on the number of tasks worked on at any one time.
Collins uses the metaphor “20 Mile March” to describe an attainable and sufficient goal for a day’s work, identifying multiple benefits:
- It reduces the likelihood of catastrophe when you’re hit by turbulent disruption.
- It helps you exert self-control in an out-of-control environment.
Limiting WIP does not mean reducing WIP to near zero. The British had too little (food) inventory. The Norwegian’s had a lot more. Less inventory (traveling light), isn’t always better.
This is especially true in knowledge work. The more important factor is controlling the WIP with a limit. Maintaining a healthy level of WIP creates options that mitigate specializations in the workforce and balance against uncertainty in the market or business domain.
Buffers improve predictability. Because the initial analysis of software development is never perfect, there are always unforeseen events.
Service-level-agreements (‘) based on observed behavior buffer time expectations while WIP buffers in front of capacity constrained resources smooth flow and improve predictability.
The use of Kanban can be seen as an active part of risk management for IT organizations and product or service development groups.
Organizations that know how to manage risk will have an edge in a volatile world. The more turbulent the world, the more you need to study your situation, keep an even pace (set WIP limits) and use buffers to meet expectations and improve predictability.