When Should You Move from Iterations to Flow?

I'm writing part of the program management book, talking about how you need to keep everything small to maintain momentum. Sometimes, to keep your work small, teams move from iterations to flow.

Here are times when you might consider moving from iteration to flow:

  • The Product Owner wants to change the order of features in the iteration for business reasons, and you are already working in one- or two-week iterations. Yes, you have that much change.
  • You feel as if you have a death march agile project. You lurch from one iteration to the next, always cramming too much into an iteration. You could use more teams working on your backlog.
  • You are working on too many projects in one iteration. No one is managing the project portfolio.

This came home to me when I was coaching a program manager working on a geographically distributed program in 2009. One of the feature teams was responsible for the database that “fed” all the other feature teams. They had their own features, but the access and what the database could do was centralized in one database team. That team tried to work in iterations. They had small, one- or two-day stories. They did a great job meeting their iteration commitments. And, they always felt as if they were behind.

Why? Because they had requests backed up. The rank of the requests into that team changed faster than the iteration duration.

When they changed to flow, they were able to respond to requests for the different reports, access, whatever the database needed to do much faster. They were no longer a bottleneck on the program. Of course, they used continuous integration for each feature. Every day, or every other day, they updated the access into the database, or what the database was capable of doing.

The entire program regained momentum.

kanban.iterationThis is a simplified board. I'm sure your board will look different.

When you work in flow, you have a board with a fixed set of Ready items (the team's backlog), and the team always works on the top-ranked item first. Depending on the work in progress limits, the team might take more than one item off the Ready column at a time.

The Product Owner has the capability to change any of the items in the Ready column at any time. If the item is large, the team will spend more time working on that item. It is in the Product Owner's and the team's interest to learn how to make small stories. That way, work moves across the board fast.

If you use a board something like this, combined with an agile roadmap, the team still has the big picture of what the product looks like. Many of us like to know what the big picture is. And, we see from the board, what we are working on in the small. However, we don't need to do iteration planning. We take the next item off the top of the Ready list.

There is no One Right Answer as to whether you should move from iteration to flow. It depends on your circumstances. Your Product Owner needs to write stories that are small enough that the team can complete them and move on to another story. Agile is about the ability to change, right? If the team is stuck on a too-large story, it's just as bad as being stuck in an iteration, waiting for the iteration to end.

However, if you discover, especially if you are a feature team working in a program, that you need to change what you do, or the order of what you do more often than your iterations allow, consider moving to flow. You may decide that iterations are too confining for what you need.

9 thoughts on “When Should You Move from Iterations to Flow?”

  1. Flow seems like a good option for some projects I work on Johanna so that was a timely article. Is it the same as Agile Kanban? Or does it share a common base with Kanban but perhaps isn’t as prescriptive?

    1. Hi Alistair, flow is kanban. (I’m not sure what you mean by “Agile Kanban.” Maybe you can explain it to me?)

      To me, kanban isn’t prescriptive. You describe your flow on your board. You limit your work in progress. The team’s job is to move work across the board. If you apply lean principles to your kanban approach (and why wouldn’t you?), you perform some kind of continuous improvement, known as kaizen, on some periodic basis. Kanban reflects your current state or culture. Many forms of agile require that you change your culture. I find this quite interesting. (evil cackle.)

      I’m delighted you found this timely.

      1. yes I keep prefixing things with ‘Agile’, must do something about that. What you describe in the flow article is just what I need for a short 3 month project that’s coming up. Low risk, exploratory, ideal for trying out Flow. Thanks again Johanna.

  2. Pingback: When Should You Move from Iterations to Flow? - The Agile Product Report

  3. Hi Johanna,

    In the case of Kanban, at what point do you release? We’ve been working constantly in sprints, however we are a mature product and think perhaps Kanban may be more useful for us a the moment.

    1. Hi Stephanie, you can release whenever you have “enough” for a release. If you want continuous delivery, and you have a product that supports it, go for it. That really depends on your definition of done. Do you have everyone in the room/on the board for done-to-production? If you only have the people in the room/on the board for done-to-staging (or something like that), then you need to either:

      – add another column to your board so you can get all the way to production
      – hand the feature over to a different group so they can get the feature to production
      – bundle the features so you can have a “project” or “release” or a named-something, so you can get it out the door.

      It depends. If you release at the end of each sprint now, go for it at the end of each feature. I would tell the rest of the organization you are experimenting, and measuring your results, so they know. I would also set acceptance/release criteria for each feature, in the same way you do for a release.

  4. Hi Johana,

    One of the key differences which I see between an Iteration based vs. a Flow based approach is that the former is largely based on ‘push’ mechanism, whereas the latter is on ‘pull’ mechanism. In your view, are you indifferent towards this or do you believe that teams need to be be mature and ‘well oiled’ to work effectively in ‘pull’ based flow?

    1. Hi Sunil, it is true that when a team commits to work in an iteration, they operate based on push. And, if you don’t watch the size of your work in flow, because it’s pull, you might pull just one feature or something in a few weeks. That would be Bad!

      I often say agile is the most disciplined of all project management approaches. In that sense, the team needs to be well-oiled if you want the ability to change. However, if you want to discover your workflow, you might want to try kanban. If you want to combine kanban with timeboxes, why not?

      There is no rule about not using timeboxes in kanban. You can spike in kanban. You can say, “As a team, we want to limit our WIP to no more than 2 open stories at a time. We may have to pair or swarm to complete those stories.”

      You can do this in iterations, also, of course.

      What you have to do is make sure you integrate the stories into the code base as you proceed, always showing progress. I don’t care if a team uses push or pull. I care about too much WIP and not showing progress. And, in the post, I wondered about the ability to change.

      Agile is about the ability to change. How a given team discovers their sweet spot to change? I don’t care.

      BTW, I use personal kanban inside one-week timeboxes for my own work. I have quarterly, monthly and weekly backlogs. (The quarter and month view is more of a roadmap.) I execute the work in flow. Why? Because I need to be able to change to respond to client requests.

Leave a Comment

Your email address will not be published.

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

%d bloggers like this: