Product funding and the burden of agility

Enterprises create value by investing in opportunities that promise a high return (outcome over cost) and a low risk (variance of outcome, time and cost).  From an investor or sponsor perspective, this rule applies equally to the traditional and agile initiatives.

The traditional project funding and project management methods have meticulously evolved to satisfy this rule over multiple decades: an annual planning cycle to select the better opportunities based on a business case and a plan with a fixed scope, schedule and cost, a dedicated project team to execute the plan, and an oversight function like PMO to monitor variance from the plan. These methods are often deemed bureaucratic and complex, but they have been proven to be fit-for-purpose for the traditional initiatives.

The project-based methods don’t work for agile initiatives, since agile work is organized along opportunity areas, products and work-streams. Instead, agile organizations adopt a different method, called product-funding or capacity-based-funding. This method distributes available funding across persistent and self-organizing teams. The portfolio-level personnel no longer plan the work for others, nor do they track the cost of the work at the project level. Expenses are fixed, and work that takes longer than expected, does not change the budget. Self-organizing teams move people to the most critical work without escalation to management.

It is true that the product-funding approach significantly reduces bureaucracy and simplifies planning and accounting, but does it also improve decision-making, lead to a better management of investments, or worse cause waste or financial hazard? These are fair questions for agile leaders to ask, because the burden of the bureaucracy and complexity of the project-based methods is deliberate and serves for a purpose. Shouldn’t be there a corresponding burden embedded in the product-based methods? To answer these questions, we need to look deeper into how agile organizations function.

The burden of agility

In contrast to traditional initiatives, agile initiatives don’t have a set scope or schedule. Moreover, instead of a dedicated team they have an allocated capacity. The fixed run-rate of this capacity helps minimize the cost variance, but agile organizations still need to ensure a flow of high returns while managing scope and schedule expectations of sponsors, and ultimately investors. Agile operating environments offer three management levers to influence the outcome, scope and schedule of initiatives:

1. Work priority. Relative priority of initiative components, e.g., epics, features and stories, on team backlogs
2. Team-size. Resource capacity and competency assigned to each team
3. Portfolio workload. A ratio of workload to capacity in aggregate

By setting these levers accurately and frequently, agile organizations can accelerate or decelerate work, add or delete scope, and relocate investments at any level of granularity within their value streams. When these levers are incorrectly set or fall out of sync, resources become routinely wasted on getting the wrong things done that are unnecessary, redundant, low value, delayed, obsolete, cancelled, or defective. Consequently, agile organizations may incur unnecessary expenses, mismanage assets, neglect commitments, or forfeit opportunities.

Ultimately, the financial performance of agile organizations depends on how well they manage work priorities, team-sizes, and the portfolio workload across their entire operating environment. Therefore, the burden of continuously maintaining these levers at an optimum is called the burden of agility, and the aggregate economic loss caused by the improper settings of these levers is call the cost of agility.

The cost of agility

The cost of agility increases with scale. A typical scaled agile organization consists of tens of, and sometimes hundreds of, self-organizing teams working on thousands of work-items, like epics, feature and stories with myriad cross dependencies in a continuous flow operating model. For example, a 1000-FTE organization may require 1,500 interdependent prioritization decisions every sprint, and each miscalculation adds to the cost of agility.

There are other factors that can disturb the balance among the above-mentioned levers. The capacity requirements of agile work-items consistently expand from inception to completion due to scope additions, discovered complexities, and optimistic estimates. In a digital world, business outcomes are more sensitive to delays. The bottlenecks and excesses of demand and capacity continuously shift across backlogs. Risk of a cost overrun is often concealed from the executive eyes due to the fixed run-rate of agile programs. Work-items in trouble remain undetected longer due to the management of budgets using allocated costs. Unless these factors are deliberately managed, the cost of agility keeps accumulating. 

What should you do?

To mitigate the cost of agility, agile organizations need to maintain a streamlined and predictable operating environment. Popular agile frameworks and enterprise tools are the first line of defense, but the maturity of their capabilities related to demand-supply balancing, work prioritization and resource allocation greatly vary. In most cases, agile organizations need to implement custom method or system enhancements to address the organizational behaviors and operational patterns that lead to sub-optimal work prioritization, resource allocation or work intake decisions.

The cost of agility effects every agile organization differently. It grows with scale and the pace of change, and it is less affordable at traditional enterprises compared to digital natives. Therefore, agile organizations first need to quantify their cost of agility to determine when they need to act, and a flow analysis of their operating environment can help.

A typical flow analysis consists of a comparison of the progress of work in an agile work stream between two time-lapsed snapshots of the portfolio work-items. Fortunately, many agile lifecycle management systems already gather a wealth of information that can be utilized for this purpose, and historic data can be leveraged for immediate insights. In the first snapshot, work-items that are baselined – i.e., elaborated, sized, but not being implemented yet – are identified and marked. A second snapshot is taken several program-increments later to allow the marked work-items to complete their journey within the value stream. Work-items, which are not activated in a production environment within their committed timeframe, are examined for possible bottlenecks and leaks in that value stream. For example, a flow analysis conducted at a financial services company revealed that a unit of output was costing 3 times more than the estimate and highlighted several operational patterns responsible for this trend.

In conclusion, the product-funding method is a necessary upgrade for all agile organizations with a considerable scale. However, its benefits are not for free, and the use of this method may incur a significant, yet manageable cost. By analyzing the flow of work within their operating environment, agile organizations can determine how to best mitigate their cost of agility.