AvailAgility
Karl Scotland – Using Agile to Deliver Value
What is Cadence?
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.
- Dew Drop – July 22, 2009 | Alvin Ashcraft’s Morning Dew
- Friday’s Digest #15 (Kanban, Velocity, Community) | Edge of Chaos | Agile Development Blog
- Kanban In Time-Boxes: The Cadence of WIP and Sprints – new ThoughtStream("Derick Bailey"); – Los Techies : Blogs about software, programming and anything tech!
July 21, 2009 - 10:32 pm
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.
July 24, 2009 - 7:12 pm
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.
July 24, 2009 - 8:18 pm
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.
July 26, 2009 - 9:52 am
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?
July 28, 2009 - 11:59 am
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
July 30, 2009 - 8:15 am
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.
October 9, 2009 - 1:35 pm
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.
October 9, 2009 - 2:24 pm
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.
October 9, 2009 - 2:52 pm
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.
July 22, 2009 - 8:51 am
Co-ordination is the key concept there that I didn’t mention. Thanks Benjamin.
July 26, 2009 - 2:12 pm
Yes. I think good teams can start with a metronomic cadence, and move to a more complex one. I wouldn’t say that’s the only way to go though.
July 28, 2009 - 3:13 pm
I agree with the idea that the established pace should be on the basis of what user acceptance test group can accommodate. This is definitely needed in environments where the functional roles of developers, QA and System testing is explicit. Ideally in a Kanban (really for Agile) such demarcations in roles is undesirable as the team decides the WIP limits.
Unfortunately this doesn’t guide you to the length of the cadence. Its most likely that business needs (processes) as defined by sales & marketing (rule of thumb has been that 2/3 of all dollar spend by a company is by this group) is likely to have a greater influence on the cadence length, as they are closest to the customer and are missioned to set expectations.
October 9, 2009 - 1:55 pm
Generally, the cadence does have a regular signature (I like that phrasing – thanks!) so its not much different from a Scrum team. I do think it opens up other possibilities. One is to have the various meetings at different intervals. Another is having an irregular signature (although maybe not wildly changing). This tends to happen with very mature teams though who can co-ordinate and synchronise very easily and maybe don’t need to reveal dysfunction (although dysfunction can be revealed simply be limiting work in progress, regardless of cadence).
October 9, 2009 - 2:35 pm
@Tobias,
one thing to consider in the time signature, is that we are not necessarily talking about a single signature. the system in question could very easily (is most likely) a poly-rhythmic system. You could have planning running on a 3/4 signature, review on a 4/8, release on a 3/5, and …
we have to remember that not all activities need to run on the same schedule. let the customer-focused activities follow the rhythms of the customer, and let the team-focused activities follow the rhythms of the team. where there are customer-and-team combined activities, let the two synchronize naturally.
October 9, 2009 - 8:27 pm
Tobias,
> 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.
Yes. Kanban gives us a way of describing, or understanding, why these adaptations of text book Scrum are good. Or ways of arriving at these solutions via a different path.
Karl