Why to Focus on Flow of Value and Not Iterations

Agile is usually described as a method of delivering value incrementally to customers. This comes from Scrum’s sprint. From the Scrum Guide – “The heart of Scrum is a Sprint, a time-box of one month or less during which a “Done”, useable, and potentially releasable product Increment is created.” Sprints avoid getting locked into the constraint of trying to achieve a fixed scope in a designated amount of time at a specified cost. Most of Agile is based on this since Scrum is the foundation for LeSS, Scrum@Scale, Nexus, SAFe amongst others. While some of these are incorporating Kanban practices into the base Scrum practices of the sprint, Agile is still mostly viewed as creating value in iterations.

There is a subtle problem with this perspective when it comes to convincing management how to interact with Agile teams. Prior to Agile, executives have been under the impression that merely making greater demands on development teams would get the job done when additional requirements demanded it. While this approach is not effective, it often gets deliveries done on or near on time. The problem is that scope and quality are both dropped out. This is often not immediately noticed by the executives since the problems caused by this show up later and the executives just tend to blame the developers when they arise.

Many people expected the adoption of Agile would correct this because they believed that executives would understand that the amount of work that can be accomplished needed to be decided by the team. But I’ve always felt this was wishful thinking because Agile, 20 years in, is still mostly identified around the team, not the business. While most Agile at scale methods throw in references to business Agility, most are still based around the team or team level.

Agile teams based on Scrum plan around two week increments or, in SAFe’s case, about 3 months of work. The focus is on what can be done within a particular amount of time. This still leaves open the viewpoint of “we’d get more done if the development teams would be more efficient.” Hence, old habits of pressuring teams to get more done should still apply (even if they never really did). What’s needed is to change the focus from the development teams building in iterations to a focus on the value being delivered.

Two concepts are needed to facilitate this change:

• The concept of the Minimum Business Increment
• The science of Flow

Flow tells us that we will be more efficient if we reduce delays in our workflow. MBIs provide a focus on what’s the most important thing to deliver.

The concept of the MBI enables us to ask the question: “What’s the most important thing to deliver next?” The science of Flow would provide the rationale as to why you don’t want to overload people working on the next most important MBI. In the context of understanding Flow, adding the next most important thing to a team to do while they are working on the most important thing will clearly just slow things down. The focus is no longer on “how can we get developers to do more” but rather “how can we get developers to build the most important MBI faster?” This is an important shift.