Who is watching after your agile money Part II
All good, but what if the desired outcome is not well understood, like in the case of agile development What do you agree to What variance do you care for How will you know if your program succeeds with stars or is about to fail spectacularly This is the dilemma most business, capability and IT leaders face when they are about to scale up their agile programs.
In Part I of this article, we introduced key roles and operational principles necessary to effectively manage enterprise-scale agile program investments. In Part II, we will discuss related common practices in the financial services industry and their potential pitfalls. Let’s start with defining the key investment components of a typical agile program:
Most executives are painfully aware of the tremendous effort that goes into the planning cycle to determine which IT projects should be funded and prioritized. One of the goals of the agile approach is to optimize the amount of effort and time spent for planning by keeping the estimation rigor proportional to the confidence in inputs, like the business need, scope (desired outcome), constraints (quality, time, cost) and dependencies. Among many variations in style, I see two distinct estimation patterns in practice:
Use of the agile principles (the second pattern) in program estimation is gaining broader adoption every day with the increasing maturity and confidence of enterprise IT organizations about their agile capabilities. This makes sense as the scope elaboration sessions with the capability owners, product managers, product owners, and agile team leaders produce best insights about what the program should do and how. Multipliers provide rapid rough estimates for enabling capabilities and visibility into the efficiency of their consumption.
As illustrated in Figure 2, the total planned investment for an agile program consists of a calculated estimate for the Agile, Core component and derived estimates for the Agile, Noncore and the Enabling components. What happens to these investment components during program execution is pretty astonishing. Let’s review them one by one:
Agile, Core - During program execution, epics are divided into new features, features into stories, stories into scenarios, etc. Agile teams continuously elaborate and size these new scope items using story points or similar methods. Once approved by product owners, scope items are prioritized and added to an appropriate product backlog. At this point, agile teams implicitly re-estimate the Agile, Core investment component for epics that were already funded by capability owners.
Due to a complex matrix relationship among capabilities, projects, products and agile teams, the re-estimates don’t necessarily make their way back to capability owners for reconsideration of their investment priorities and options, causing the capability level commitments being constantly redefined without a proper governance. The Agile, Core investment component estimate can easily double during the program execution phase, if the feedback loop from agile teams to capability owners is not functioning properly.
Separately, agile teams may not achieve their velocity targets that were assumed during the planning cycle. This may be due to challenges within teams, or factors not controlled by them. For example, environments may not be available or high-priority stories may be added to team backlogs unexpectedly mid-sprint. Clearly, these conditions should have been addressed at the program level before they hit the team; otherwise, it may not be possible to keep agile teams accountable for their velocity. Sustained velocity gaps are not factored into the original estimates, and they add up to 40% variance to the Agile, Core investment component.
Agile, NonCore -Typically, agile teams spend 10% to 15% of their time on noncore activities. However, this figure can increase to 30% to 40% if the program operating model is not adequately streamlined or automated.
When the Agile, Core effort increases due to re-estimates or velocity gaps, agile teams can’t simply hire new resources, since the team capacity is fixed. The new demand can either be addressed through a demand rationalization or by adding new sprint cycles to releases. Demand rationalization requires empowered product managers and highly effective feedback loops to the capability owners. Otherwise, new sprint cycles will be inevitable. Additional cycles cause the Agile, Noncore effort of the program grow proportionally to increases in the Agile, Core effort.
Enabling - In a typical agile program, the Enabling investment component accounts for more than one-third of the overall program investments. When the Agile, Core component is re-estimated or agile teams miss their velocity targets, most organizations have no means of resizing the Enabling effort, meaning that with every new sprint, the cost of the Enabling effort will grow proportionally to increases in the Agile, Core effort.
Evidently, agile teams’ planning poker exercises have a profound impact on investments due to the multiplier effect of Agile, Core on everything else in the program.
In summary, agile programs are complex operational systems. Effective collaboration can compensate for complexity in programs with less than 100 full-time employees. However, larger programs additionally require executive management controls specifically designed for agile to avoid cases experienced by others, such as the cost of an individual feature exceeding the original estimate by a factor of five, the program cost doubling, and the program schedule increasing to three times longer than the original estimate.