Iteration- and Flow-Based Agile

Teams use agile approaches in one of two primary ways: iterations or flow. Yes, you can combine them, too.

An iteration-based agile approach means a team works in timeboxes of the same size for every iteration (as shown in the following diagram). The team fixes the duration of the iteration. Teams often work in one- or two-week iterations (the timebox). Every two weeks, by definition, the team is done because the timebox is over. The team doesn’t change the duration because the team can’t estimate what it can complete in a timebox if it keeps changing the duration.

In iteration-based agile, the product owner and the team manage the work in progress by estimating the number of stories (and other work) the team can commit to in a timebox. When the team estimates, the product owner receives feedback on the estimated size of the work. The product owner then has choices to make more stories or ask the team to swarm or mob on the work.

Note that I have included all of the work in a timebox: requirements, analysis, design, build, test, release, and deploy. Teams perform all of those activities to deliver finished value. (Sometimes teams release internally but do not release to customers or deploy each iteration.)

You might think a team does these activities sequentially. Not necessarily. The team often performs these activities as a team, on one or two features at a time. I’ll explain more in Chapter 6, ​Teams Deliver Features​. The team performs all these activities, but not necessarily in sequential order for a given feature. Here’s a quick example: During a planning meeting, the team—as a team—discusses a couple of possible designs for a given feature, because the time needed might change depending on the design. A tester might sketch some possible tests. Even before the team “starts” work on that feature, the team estimates, designs, and tests—just a little bit. That’s what I mean by a nonsequential approach to the work.

An iteration-based agile approach provides a cadence—a project rhythm—for teams to deliver and learn, retrospect, and plan.

In a flow-based agile approach, shown in the next diagram, the team maps the flow of value through the team. The team sets a WIP limit for each column on the board and tracks the team’s cycle time—how long features take on average. The team and the product owner manage the work based on those limits. After finishing some work, the team delivers and learns, retrospects, and reviews what it wants to improve.

Flow focuses on the continual pulling of work; iteration more often focuses on pulling a limited set of work into a defined timebox.

Neither the flow nor the iterations approach is right. Neither is wrong. It’s all about what your team needs to see the work, release valuable product often, and get feedback.

I happen to like a flow-based approach inside of some cadence. I like seeing working product at least every two weeks, which is what I do for my collaborative projects. I deliver value more often for my personal projects—at least once a day. I want to see where the work starts, where it waits, how long it waits, if there are any cycles, and so on. Flow and kanban boards can show you that. Iterations—by themselves—don’t show you details of where work is stuck.

Distinguish Between Cadence and Iteration

I said that iterations are timeboxes of a week or two, maybe longer if you don’t need more frequent feedback. I also said that a cadence provides a rhythm for a project. Let me explain the difference.

Many teams appreciate 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. It plans weekly, but not the same day each week. When the team has finished three features, it plans for the next three. It takes 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 the team didn’t ask me. See ​Organize the Team’s Meetings​, to see why I prefer midweek cadences.)

Notice that this team has two separate cadences: at least once a week for planning work, but not the same day each week; and once a week for retrospectives, on the same day each week. The team isn’t working in iterations; it’s working in flow. The team uses the idea of a cadence to provide a pulse, a rhythm for its project.

If the team used iterations, it would always plan on the same day, at the beginning of the iteration. The team would always have a retrospective on the same day at the end of the iteration. This team doesn’t do that, and that’s great. Teams don’t have to follow prescribed ceremonies, especially if the team’s context is different from other teams’.

A cadence is different from an iteration. Decide what fits for your team.