Thus cadence is what gives a team a feeling of demarcation, progression, resolution, or flow. It is a pattern that allows the team to know what they are doing and when it will be done. For very small or mature teams, this cadence could by complex, arrhythmic, or syncopated. However, it is enough to allow a team to make reliable commitments because recognizing their cadence allows them to understand their capability or capacity.
The appropriate cadence for a team will be influenced by their transaction and coordination costs. Transaction costs are those associated with performing an activity. For example, the cost of making a release is a transaction cost. Coordination costs are those associated with the logistics of an activity. For example, the cost of getting people together to manage a release is a coordination cost.
Thinking in terms of transaction and coordination costs can provide the basis for establishing an appropriate cadence for the various events such as prioritization, planning, reviewing, retrospection, and releasing. Focusing on reducing these costs can subsequently allow the cadence to change as delivery capability improves.
The end goal of reducing costs and improve cadence is to be able to quickly, reliably, and frequently release valuable software. In doing so, we can help to further reduce costs. David Anderson uses the example of over-ground and under-ground trains. Over-ground trains, which run less frequently, tend to require more planning by looking at a timetable and travelling to the station at the right time to avoid unnecessary waiting. Under-ground trains, which run more frequently, tend to require less planning because it is safe to turn up and catch a train quickly. Thus by releasing quickly, reliably, and frequently, we can reduce the need for much of the planning overhead.
Once a cadence has been established and a delivery capability understood through measuring cycle-time and throughput, then reliability can be achieved. Rather than making promises or setting targets, information can be given about the likelihood of certain timescales. When a team pulls in a piece of work, it is able to forecast that it should be delivered within a known time period, with known percentage likelihood, based on historical performance. For example, a team can measure its capability to deliver features within fiftenn days, 80 percent of the time.
By releasing frequently, to a known cadence, with a well-understood capability, a team can build trust that it is delivering to its full capacity.
Learning is how a team constantly develops a kanban system’s capability to meet its purpose. A kanban system should continuously improve to create an economy of flow, rather than an economy of scale, with the ultimate goal being to eliminate the kanban system.
In their book Learning to See , Mike Rother and John Shook use the phrase “Flow where you can, pull when you must.” A kanban system allows the work to be pulled, but in order to really achieve flow, the team members should be always looking for ways to keep the work moving, rather than keeping themselves busy.
One approach to continuous improvement is to reduce WIP limits. When a kanban system appears to be working smoothly, lowering a WIP limit is analogous to lowering the waterline. It will expose the rocks, and new bottlenecks and constraints will be discovered. As a result, teams can work to remove the new bottlenecks and constraints until work is flowing through the system smoothly again.