≡ Menu
Pawel Brodzinski on Software Project Management

Cadences and Iterations

Cadences and Iterations post image

Often, when I’m working with teams that are familiar with Scrum, they find the concept of cadence new. It is surprising as they are using cadences, except they do it in a specific, fixed way.

Let’s start from what most Scrum teams do, or should do. They build their products in sprints or iterations. At the beginning of each sprint they have planning session: they groom backlog, choose stories that will be built in the iteration, estimate them etc. In short, they replenish their to do queue.

When the sprint ends the team deploys and demos their product to the client or a stakeholder who is acting client. Whoever is a target for team’s product knows that they can expect a new version after each timebox. This way there is a regular frequency of releases.

Finally, at the very end of the iteration the team runs retrospective to discuss issues and improve. They summarize what happened during the sprint and set goals to another. Again, there is a rhythm of retrospectives.

Then, the next sprint starts with a planning session and the whole cycle starts again.

It looks like this.

All practices – planning, release and retros – have exactly the same rhythm set by the length of timebox. A cadence is exactly this rhythm.

However, you can think of each of practices separately. Some of us got used to the fact that frequency of planning, releases and retrospectives is exactly the same, but when you think about this it is just an artificial thing introduced by Scrum.

Would it be possible to plan every second iteration? Well, yes, why not? If someone can tell in advance what they want to get, it shouldn’t be a problem.

Would it be a problem if we had planning more often then? For many Scrum teams it would. However, what would happen if we planned too few stories for the iteration and we would be done halfway through the sprint? We’d probably pull more stories from backlog. Isn’t that planning? Or in other words, as long as we respect boundaries set by the team, wouldn’t it possible to plan more frequently?

The same questions you can ask in terms of other practices. One thing I hear repeatedly is that more mature teams change frequency of retrospectives. They just don’t need them at the end of every single sprint. Another strategy is ad-hoc retro which usually makes them more frequent than timeboxes. Same with continuous delivery which makes you deploying virtually all the time.

And this is where the concept of cadence comes handy. Instead of talking about a timebox, which fixes time for planning, releases and retrospectives, you start talking about a cadence of planning, a cadence of releasing and a cadence of retrospectives separately.

At the beginning you will likely start with what you have at the moment, meaning that frequencies are identical and synchronized. Bearing in mind that these are different things you can perfectly tweak them in a way that makes sense in your context.

If you have comfort of having product owner or product manager on-site, why should you replenish your to do queue only once per sprint? Wouldn’t it be better if the team worked on smaller batches of work, delivering value faster and shortening their feedback loops?

On the other hand, if the team seems mature frequency of retros can be loosened a bit, especially if you see little value coming out of such frequent retros.

At the same releases can be decided ad-hoc basing of value of stories the team has built or client’s readiness to verify what has been built or on weather in California yesterday.

Depending on policies you choose to set cadences for your practices it may look like this.

Or completely different. Because it’s going to be adjusted to the specific way of working of your team.

Anyway, it is likely, that the ideal cycle of planning, releases and retrospectives isn’t exactly the same, so keeping cadences of all of these identical (and calling them iteration or timebox) is probably suboptimal.

What more, thinking about a cadence you don’t necessarily need them to be fixed. As long as they are somewhat predictable they totally can be ad-hoc. Actually, in some cases, it is way better to have specific practice triggered on event basis and not on time basis. For example, a good moment to replenish to do queue is when it gets empty, a good moment to release is when we have a product ready, which may even be a few times a day, etc.

Note: don’t treat it as a rant against iterations. There are good reasons to use them, especially when a team lacks discipline in terms of specific practices, be it running retros or regular deployments. If sprints work for you, that’s great. Although even then running a little experiment wouldn’t hurt, would it?

in: project management, software development

5 comments… add one

  • Jason Yip July 13, 2012, 1:15 pm

    Given the context that you’re describing, I’d suggest replacing “iteration” with “timebox”

  • Pawel Brodzinski July 13, 2012, 1:25 pm

    @Jason – Ah, naming issue again.

    Thanks for the advice, although I likely misused it – replaced only part of iterations with timeboxes. What I refer to in the post is common usage of concepts, and this is exactly what meaning teams attach to iterations, thus the naming.

    So, at least for the sake of this post, I’m going to use these terms interchangeably. Hope you won’t treat it as poking you in the eye with a pencil :)

  • Ron July 13, 2012, 2:12 pm

    I totally agree with you on that. My team uses all parts of Scrum but learned to adjust the frequency of planning, sprint length, releases, retrospectives etc. to their and our customers needs. As we do not develop “projects” but products that are used by different groups of customers and have to be maintained over years we have to adjust to many external influences.
    Usually we plan and estimate 1 hour every monday, do a 5 day sprint, repeat 3 times, review, release, do a retro… but sometimes we have only 2 sprints before we release because that new feature just has to be finished and deployed asap. Then we do 5 sprints to implement someting complex before a release, the other day we do another planning and estimating after 3 days and so on. This works quite well so far and keeps us flexible.

  • Vasco Duarte July 14, 2012, 1:06 am

    The strongest argument in the post seems to be the contrast between Natural and Unnatural rhythm for certain activities. Although this may be an important argument you do not explain what it means to you. Also unnatural may be better for certain activities. Also it us unclear that cadence is even a need in some activities (yes, this also means iterations may not be the best seek organization pattern) :)
    so, what does Natural mean, and why is it important to you?

  • Pawel Brodzinski July 14, 2012, 10:27 am

    @Vasco – I wouldn’t call it natural vs unnatural. If you ask about such distinction I would rather go with more vs less suitable although it might be false in some cases too. Think, for example, about a team that is pursuing continuous delivery but is not yet there. Is more frequent delivery natural for them? No. Is it more convenient? Again, no. Yet they see value in it and they decide to try.

    The basic goal of the article was written explanation of something I keep explaining on different occasions. It wasn’t my goal to rant against iterations. I see the point of coupling together all the cadences and calling them a timebox or an iteration and I even wrote that in the disclaimer at the end of the post.

    At the same time I often see inconvenience of such situation. Reasons may be different but, in general, it will be somehow connected with how the team wants to change. Often, with the team being more aware of meaning of specific practices they perform and willing to experiment with them. Sometimes, as you point, it may be about dealing with something that is simply a pain in the neck when done in strict timeboxes.

    I’m not sure if that answers your question.

    Ah, one more thing. Of course I don’t treat a regular rhythm as a must either and I also gave examples of such situations. I treat the concept of cadence pretty loosely. As long as it is somewhat predictable I’m fine with that – it doesn’t have to happen “every 3 days” or something. I believe it addresses your point of not needing a cadence in specific situations.

Leave a Comment