Mark Stringer gave me some good feedback recently, that I clearly hadn’t described what I meant be Cadence at the recent miniSPA conference. In order to try and correct that, I thought I’d try and clarify with a blog post that it not simply variable length iterations.
The purpose of a cadence is to establish a reliable and dependable capability which demonstrates a predictable capacity. Cadence gives some confidence in the upcoming work when we are triggering rather than scheduling work.
Time-boxing is one specialised form of cadence. It’s like a metronome, giving a single tick. All the main process events are based around this single tick, as shown below where the dotted vertical lines represent the Sprint boundaries. In this example, the unit of work is a User Story, and User Stories should be small enough to be scheduled into a Sprint, and subsequently completed in the same Sprint. Stories in Progress are limited to two, as a good Scrum team might, but Stories don’t always fit exactly into a Sprint. Note also, that while releases can happen each Sprint, User Stories are only potentially shippable product increments.
Kanban on the other hand has a cadence which is more like a drummer. The rhythm is more complex than the single tick of a metronome, and can be more varied, as shown below. In this example, the unit of work is a Minimal Marketable Feature, which while needing to be as small as possible, is not constrained be being required to fit into a schedule. Instead, an MMF is able to flow over a number of process events while it delivers some releasable value. Planning, reviewing, retrospection and releasing all still happen regularly, but they are de-coupled. They can happen independently, at differing rates, which may provide more freedom in creating a natural process which enables the team.
A cadence is usually ‘harmonic’, in that there is a neat overlap between the different rhythms, as in this example. However, it does not have to be. A look at some definitions of cadence can show why. These are some favourites I picked off dictionary.com
- 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. 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.
On my team cadence is defined by the fact that “we release working code to production every second Wednesday”.
This is like a heart beat the goes through the whole team, makes it easy to co-ordinate various tasks (e.g. manual regression testing, wasteful processes like production change requests, and booking of resources to start the scripted deployment) and allows our sponsors and customers to set their expectations about when new functionality will be released.
There have been times where we haven’t finished enough customer-visible work ready to be released where we have skipped a release (using the notion that there was nothing for the customer to pull and we shouldn’t push it onto them), but this has sometimes been at the expense of more co-ordination and planning costs when we’ve done anything other than wait to the next regular ‘heart beat’ two weeks later.
[…] What is Cadence? (Karl Scotland) […]
[…] What is Cadence? Great post explaining cadence using nice pictures. “The purpose of a cadence is to establish a reliable and dependable capability which demonstrates a predictable capacity. Cadence gives some confidence in the upcoming work when we are triggering rather than scheduling work.” […]
I like the concept of decoupling stories and sprints, and not trying to timebox things that obviously can’t be timeboxed. But doesn’t this add overhead to the development process? Do developers that are working on big tasks (that won’t be finished before release) work in a separate branch? How can QA function properly? I know my questions are a bit lower-level, but I just can’t get my head around the extra overhead that this process could produce.
I like the metaphor of a drummer and tapping out a rhythm, as well as the harmonic’s of planning, reviewing, restrospection, and releasing. I have used this with teams to simply express a need to establish a natural “rhythm” that the team can sustain when delivering MMF as production ready working code. If the cadence is too finely tuned to reflect a particular composition of a team then this will change when the team changes in a significant way. There is such a thing as organizational cadence – one which is at a longer wavelength then allowed for any one team. It aggregates all the individual rhythms represented by the team cadence i.e harmonics
In fact if you have ever been to a Drum Circle, you find that participants (team) who have never drummed together or for that matter some have never drummed can figure out the rhythm and in relatively short time (minutes) the drum circle as a team has a beat. What is interesting to experience is that this happens without anyone giving any instructions. The rhythm changes (speeds up or down) and the leadership (person setting the rhythm) changes establishing a new flow. All this without anyone instructing to do anything other than work as a team by listening.
In essence I like it.
Great stuff Karl. You’ve succictly explained a term which is new to most people when they start to hear the language associated with kanban. This is a really nice metaphor.
Can we say that the basic metronome beat might be a starting point for eventual progression to a more sophisticated kanban rhythm?
It is perhaps useful to recall that the idea of cadence lies in the lean systems thinking concept of takt time, which is named after the German word for ‘beat’… as in drum beat or heart beat.
Takt time is calculated by determining the customer demand for value (i.e. working product delivered) and dividing that by the available work-time. The result tells you how much product you need to deliver per period. And then you can determine how many resources you need to deliver at that pace. Both too fast and too slow development is wasteful.
Applied to the development of software intensive-systems, I suggest the customer demand is established by the pace at which the user’s Acceptance Test group can accommodate new releases. The cadence of the entire development process should then be geared to that.
Best regards,
Grant (PG) Rule
Another excellent post Karl.
I would suggest that we separate the notion of a Scrum Sprint timebox from the wider concept of timeboxing. Scrum connects many activities to a particular timebox but this is not the only way that time boxing is used.
A time box can be useful for managing activities at a wide variety of levels. For example, a meeting or a project can be timeboxed. By timeboxing we communicate that our priority is schedule, most obviously over scope.
So a timeboxed meeting will provide an hour to discuss a topic, the discussion is over hen the time runs out. This can be a useful discipline independent of methodology.
Similarly a timeboxed project is a commitment to effect a change bounded by a particular date, this will guide our decisions about how the change will be approached.
[…] on this subject. His work along with the writings of Karl Scotland (Kanban, Flow and Cadence. What Is Cadence. Does A Kanban System Eschew Iteration. etc), David Anderson and the rest of the KanbanDev mailing […]
Karl, help me understand something. I like the idea of a complex drum rhythm over a metronome beat, but aren’t the drummers still drumming within a time signature, e.g. 4/4 — or are you implying that the signature itself is rapidly changing, in the style of Stravinsky for example?
If the former, then I don’t see it as any different to the way a Scrum team works, but if you are changing time signatures, and perhaps duration of each beat (?) then that is wildly fascinating and I want to learn more about that. I am not sure it is the best way to reveal dysfunction though, but I think it must have some other interesting outcomes.
It starts to seem likely that Scrum done with respect and intelligence and Kanban performed the same way will converge on a common solution. As we all discuss this I see so many more similarities than differences.
As an example, I have worked with teams who do mid-sprint planning, simply because it is exactly the right thing to do. Generally they continue with the committed work, but new information that comes to light can be incorporated if everyone agrees and corresponding articles are removed from the current commitment. Just as common are mid-sprint retrospectives (although I’ll still tend to recommend teams set certain days/times for these to continue the sense of regular rhythm — heartbeat. There is a feeling of safety in that, a steady commitment, a trust.
One of the very big advantages of regular rhythm for product reviews of course is that we can calendar in the execs, customers, users etc. months ahead of time. Running reviews ad hoc we stand a big chance of not having the right people there. I also like the ceremony around the “Regular Wednesday Lunchtime Review” (or whatever it is). Ceremony is important for tribes, and a good Agile team is exactly that: a tribe. A review is a feast, with many guests invited. It takes planning and consideration to entertain well.
Karl, Tobias,
[Ok – I made it halfway through typing this, and then realized that I was wrong… I’ll leave it, though, and then say where I ended up]
In my mind, the biggest difference is in how you arrive at the timing, not in the nature of the timing.
Scrum generally specifies the overall time signature and the different meetings (Inspect and adapt cycles in general, but I’ll call them meetings for ease) occur at harmonic cadences within that overall signature. I can easily picture a daily standup as sixteenth notes within a weekly tempo of quarter notes within the sprint cycle of measures… Same thing with kanban except replace sprint with MMF’s…. they do tend to hit a steady pattern as Karl describes.
[Ok – post-wrong, aka different type of wrong, starts here]
I was going to say that Scrum specifies these tempos and kanban allows them to emerge. I was wrong. Scrum specifies two of the cadences: Sprint length & Daily stand-up. Kanban doesn’t specify any of them, but the daily one is almost universal in my experience.
However, Tobias, from listening to how you run Scrum, it sounds like you do allow all of the other tempos to emerge naturally, including release cycle and some aspects of the planing cycle.
As I listen to you talk about to Scrum I continually come to the understanding that successful teams led/facilitated/taught by the masters are going to end up with behaviors that look and feel remarkably similar, regardless of the set of tools and approches used to get there.
[…] estimates completely off. This is why I hate estimates (Waterfall or Scrum based) and love Lean’s Cadence. From Mary Poppendieck: A regular cadence, or “heartbeat," establishes the capability of a team […]
[…] Scrum werden in Kanban unterschiedliche Takte für unterschiedliche Ereignisse genutzt (siehe den Artikel von Karl Scotland). Aber auch bei Kanban gehört ein regelmäßiges Inspizieren und Anpassen dazu. […]