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.
Constraints are misleading
The iron triangle discusses the relationship between scope, cost and time.
The assumption is that these three interrelate in an adverse way with each other – that is, increasing one will increase the others. Quality suffers when all are fixed. But this ignores the fact that few value streams are effective. In fact, by focusing on principles of flow and lean we can deliver value in a shorter period of time, thereby reducing cost.
The essence of lean is to decrease waste by eliminating delays in the workflow. This requires preventing the need for:
Removing these delays not only shortens the time required to deliver value directly, but eliminates the work they create (see Why Looking at Delays In the Value Stream is so important). We can increase value without requiring additional work by focusing on those items that will deliver the greatest amount of value in the shortest amount of time. This is the definition of the Minimum Business Increment.
This combination of eliminating delays while focusing on the most important work provides a way to use the constraints of the iron triangle as a guide – not a limitation. We can get more value delivered in a shorter time and with less cost by attending to them.