Thinking About Cadence vs. Iterations

Many people use an iteration approach to agile. They decide on an iteration duration, commit to work for that iteration and by definition, they are done at the end of the timebox.

I like timeboxing many things. I like timeboxing work I don't know how to start. I find short timeboxes help me focus on the first thing of value. Back when I used staged-delivery as a way to organize projects, we had a monthly milestone (timebox) to show progress and finish features. The teams and I found that a cadence of one month was good for us. The timebox focused us and allowed us to say no to other work.

A cadence is a pulse, a rhythm for a project. In my example above, you can see I used a timebox as a cadence and as a way to focus on work. You don't have to use timeboxes to provide a cadence.

A new reader for the Pragmatic Manager asked me about scaling their agile transformation. They are starting and a number of people are impatient to be agile already. I suggested that instead of scaling agile, they think about what each team needs for creating their own successful agile approach.

One thing many teams (but not all) is a cadence for delivery, retrospectives and more planning. Not every team needs the focus of a timebox to do that. One team I know delivers several times during the week. They plan weekly, but not the same day each week. When they've finished three features, they plan for the next three. It takes them about 20-30 minutes to plan. It's not a big deal. This team retrospects every Friday morning. (I would select a different day, but they didn't ask me.)

Notice that they have two separate cadences for planning: once a week, but not the same day; and once a week for retrospectives on the same day each week.

Contrast that with another team new to agile. They have a backlog refinement session that often takes two hours (don't get me started) and a two-hour pre-iteration planning session. Yes, they have trouble finishing the work they commit to. (I recommended they timebox their planning to one hour each and stop planning so much. Timeboxing that work to a shorter time would force them to plan less work. They might deliver more.)

A timebox can help a team create a project cadence, a rhythm. And, the timebox can help the team see their data, as long as they measure it.

A project cadence provides a team a rhythm. Depending on what the team needs, the team might decide to use timeboxes or not.

For me, one of the big problems in scaling is that each team often needs their own unique approach. Sometimes, that doesn't fit with what managers new to agile think. I find that when I discuss cadence and iterations and explain the (subtle) difference to people, that can help.

6 Replies to “Thinking About Cadence vs. Iterations”

  1. Great post Johanna, once again. We have a saying in spanish “lo bueno si es breve, es doblemente bueno” probably lost in translation will roughly be “something that is good, is twice as good if brief”
    Long meetings are the materialization of WASTE in development process.
    Regards. Ale

    1. Ale, thank you. I love the idea of something being twice as good when it takes less time. Yes, many people do not realize they have waste in their projects. I’m writing a book about how to do agile and recognize your waste now.

  2. Agree with most of your thoughts! The observation i would make is that scaling agile (maybe we should say agile at volume instead!) seems to work best when teams are allowed to identify HOW they are going to work . To own their process because then they feel more ownership and accountability to reflect and improve it. What I would counter with is that without some common elements it’s difficult to understand a large complex undertaking especially where we are targeting some specific outcome . I would actually suggest the “cadence” should be one of those comments elements. Especially teams new to agile to give them some initial structure to organise, and be transparent around. I would also expect as teams mature they constantly evolve to what works for them and provides what others might need from them. What’s the General consensus on this?

    1. Phil, especially if you want to “share” agile across the organization or organize several teams into a program, the teams do have to define their agile approach.

      I don’t know if there is a “general” consensus. I wrote about how to do this for programs in my book Agile and Lean Program Management. It’s what I teach in my product owner workshop, too.

      Cadences work, even if iterations don’t.

  3. Pingback: Time You Spend in Agile Meetings | Java Code Geeks | Aquaiver IT Solutions

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.