Flow vs Iterations in Agile: Is There a Right Workflow Approach?

Gone are the days of maximum capacity utilization as a way to get more efficient and improve your team's performance. With Agile transformations on the rise, not just in tech but in engineering, banking, pharma, and other fields, one of the dilemmas that leaders face is whether to turn their focus on flow or iterations to adopt Agile. 

Let's get into the discussion head-on! We'll discuss the differences between flow- and iteration-based Agile workflows, which approach is best, and how can both be mixed, or should they?

What Is Flow-Based Agile?

Flow in Agile is a term used to describe the optimal state of a work process. The concept is rooted in the Lean philosophy. One of the founding Lean principles emphasizes the importance of continuous value delivery by establishing a smooth workflow.

A flow-based Agile process simply focuses on releasing value to the customer as soon as possible in a continuous flow (i.e., whenever a functionality is complete). The idea here is to keep the batch size of work as small as possible to make its "flow" through the process and ultimate market delivery more efficient. Limiting work in progress (WIP) is central to a flow-based approach, which creates a pull system in the process.

Lean flow process diagram

Iterations in Agile - What Does Working Iteratively Mean?

Iteration-based Agile refers to a work process where delivery happens within time-boxed periods called iterations. A work increment is completed at every iteration on a regular basis. The team is focused on maintaining a backlog by progressively prioritizing new work functionalities. The highest-level work at a given moment is planned for delivery at the end of each iteration.

It's not recommended for new work to enter the process until an iteration is complete because that can dilute the focus on the work at hand and compromise the planned goal (in terms of functionalities) for the iteration. 

Flow-Based vs. Iteration-Based Agile Process: Differences Explained

While adaptability to changes is the true goal of the Agile movement, there are different types of Agile methodologies. Both the flow-based and Agile iterative processes can help you with that mission. As we've given more context into the two approaches, let's take a closer look at the key distinctions between them.  

Flow-based vs. iteration-based Agile process

Constraints in Agile Iterations vs Flow-Based Processes

Agile teams using iteration-based work processes deliver value at every iteration. They limit the scope of work and time for its execution to enhance early value delivery. In Scrum, for instance, iterations are called sprints. Each sprint should result in a tested and functioning piece of work.

Alternatively, in a flow-based Agile process delivering value can take a different amount of time depending on the deliverable. Instead of limiting the time for work completion, the flow-based approach focuses on limiting the amount of work that can be in progress (WIP limits). This triggers one of the guiding principles of the approach to start new work only when team members have the capacity to do so.

Keeping a limited work-in-progress size allows teams to identify issues early in the process and reduce the need for rework. While that's the case in flow processes, and there's a natural drive to unblock the interruptions to continue to deliver value, iterations oftentimes focus on the individual contribution (or the lack of it) rather than the workflow itself.  

Alleviating work bottlenecks on a Kanban board

Feedback Loops in Iteration vs. Flow-Based Agile

When working with iterations in Agile, teams create a feedback loop at the end of each cycle. This is usually done by reviewing what has been done throughout the iteration and releasing it to the market in a batch. The idea is to get the customer's feedback and then re-plan if necessary. This re-planning usually means changing the priorities in the backlog or adding new items.

Alternatively, there isn't a strictly defined feedback loop in flow-based Agile. The team replenishes their work queue, reduces the batch size as much as possible, and continuously delivers functionalities to the customer. In this case, feedback can come at any point in time. Whenever there is a change, teams replenish their queue with new requests and mark what's a higher priority just in time.

Keep in mind that in a flow process, teams can still negotiate a delivery schedule by having "Replenishment" and "Delivery" cadences/loops. The main difference is that, unlike focusing on iterations in Agile, they can happen in an ad-hoc manner.   

Planning and Prioritization

Flow-based processes allow for planning to happen "just in time," or as needed. Iteration-based approaches, however, plan work items according to backlog priority, starting with the most important and continuing through the iteration. 

Furthermore, teams using iterations start working on the next piece of work once the planned deliverable is completed. Whereas, in flow-based workflows, planning deliverables is flexible and can change depending on their priority. 

One advantage of flow-based processes is that, due to their nature, they're more suitable for tracking flow metrics. Monitoring those on a regular basis can help you create a more predictive work process that can enable you to eventually embrace forecasting rather than estimations when doing your planning.

Measuring workflow efficiency using the Flow Efficiency chart

Creating an Agile work process is not easy, and it's not an initiative you can put an endpoint to. Like in Lean, the key is developing a mindset, a culture around customer focus, feedback exchange, and continuous improvement. The fact that almost half of Agile users do not just adopt Agile practices to improve delivery efficiency but also to support their digital transformations shows that Agile is more of a behavior than a long-term commitment (16th State of Agile Report).

When Should You Apply Agile Iterations and Flow Processes?

Iterations-based and flow-based Agile approaches are often suitable for complex projects/ initiatives that require timely feedback from team members and stakeholders. They can be beneficial to efficiently manage projects that require research and development and come with high rates of change.  

Iterations can hold more evident benefits for projects that need to abide by a specific deadline, especially when you don't have historical data to rely on. An example could be when you have to deliver a product's prototype for an event that is happening on a predefined date. They're also preferable for projects where delivery primarily depends on a single team. In general, iteration-based approaches work very well in a software development context.

Conversely, a flow-based process is more flexible if there are high chances of cross-team dependencies. They provide more agility to create "waiting queues" in the process and measure them to properly manage your dependencies. Flow-based Agile also works better when you have to respond to workflow interruptions, or you need to manage work with different classes of service.

So, Flow-Based or Iteration-Based Agile? It Depends.

Honestly, there is no right or wrong approach. It all depends on the context that you're in. Iterations can be great for product development projects when you've laid down a product vision. However, when the types of work often change, you rely on multiple other teams, and unexpected requests emerge, iterations can be hard to sustain. That's where flow-based Agile comes in.

The important thing here is not blindly following one specific framework or method. Instead, focus on creating a process that meets the context you're in. Then, you may even find that a hybrid project management method (such as Scrumban) suits you best.

The fact alone that close to 80% of people use Kanban boards, while at the same the most popular Agile approach is Scrum, speaks plenty about the synergy that can be achieved between iteration- and flow-based Agile.

It's more important to start with what you do now and evolve by experimenting with the myriad of techniques and practices available in Agile.