Who is watching after your agile money? Part II

eggs basket
Credit: Pexels

The enterprise-scale agile programs are complex operational systems. Proper executive controls are needed to avoid unnecessary operational and financial risks.

PART II: Understanding of the investment side of agile

After half a century in the making, the traditional program and project management theory looks better than ever — well understood, ubiquitously trusted, battle-tested and continuously fine-tuned to perfection. As long as your desired outcome (scope) is well understood, and your constraints (quality, time and cost) are agreed-upon upfront, it will get you to your destination safe and sound. The definition of success is clear and simple — deliver the desired outcome with minimal variance to the constraints

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:

  • Agile, Core represents the effort and expenses for activities that are directly controlled by agile teams. They typically include analyze, design, build, test and release tasks.
  • Agile, Noncore refers to the effort and expenses for activities that are not directly controlled by agile teams, but performed by their members. Examples include assistance with environment set up and management, test data collection, cross-team coordination, support for ad-hoc requests to perform activities not directly related to the scope of their current sprint workload.
  • Enabling refers to the effort and expenses incurred outside of agile teams.  Examples include program and project management and reporting, architecture, infrastructure support, change management and deployment.

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:

  • The first pattern favors control over agility. It requires a traditional bottom-up project proposal estimate from each program team (agile and enabling), for the elaborated agile scope. These organizations often end up operating a waterfall-style enterprise program under the disguise of the "agile" brand name.
  • The second pattern fully embraces the agile principles. Followers of this pattern size the agile team effort by using story points first. Then they calculate the required capacity for enabling teams using a predefined formula, often a simple multiplier.

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.

graph 1 Technology for Alpha

Figure 2 – Agile Program Cost, Plan vs. Actual Comparison

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.


This article is published as part of the IDG Contributor Network. Want to Join?

Drexel and CIO.com announce Analytics 50 award winners
View Comments
Join the discussion
Be the first to comment on this article. Our Commenting Policies