look at some definitions of cadence from dictionary.com can show why.
- In music, the ending of a phrase, perceived as a rhythmic or melodic articulation or a harmonic change or all of these; in a larger sense, a cadence may be a demarcation of a half-phrase, of a section of music, or of an entire movement
- Music. A progression of chords moving to a harmonic close, point of rest, or sense of resolution.
- The flow or rhythm of events, esp. the pattern in which something is experienced: the frenetic cadence of modern life.
Thus cadence is what gives a team a feeling of demarcation, progression, resolution or flow. It is a pattern which 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 recognising 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 prioritisation, planning, reviewing, retrospection and releasing. Focussing 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 15 days, 80% 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” [x], 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.