Who is watching after your agile money?

PART I – A modern day interpretation of  the AGILE MONEYfesto

In a recent report, Gartner estimates that about a half of today’s enterprise software is developed using agile or iterative methodologies. IDC predicts that 90% of enterprise software development projects will be rooted in the agile concepts by 2018. Thanks to the digital revolution and two decades of experimentation with the agile methodology, many companies are finally serious about enterprise-scale agile programs, and they are now investing in them by the masses.

In theory, the overall investment accountability for an enterprise-scale agile program sits on the shoulders of four key roles:

• Business leaders own the results that materially impact the bottom line of the enterprise. They are the P&L holders; they sponsor business and enterprise capabilities that they need to deliver on their commitments. (E.g., consumer credit card business line)
• Capability owners are functional leaders. They own investment budgets, and they fund projects to create or enhance functionality of their capability. (E.g., credit risk management, marketing and distribution, fraud management, reference data, enterprise architecture)
• Product managers own specific technology products that deliver a quantifiable outcome to enable capabilities or other products. Technology products are the emerging currency of the interactions between business and IT — IT Projects traditionally used to fulfill this role. Product Managers’ primary responsibility is to maximize the value of products throughout their life cycle defined by the road map. (E.g., fraud management product, credit authorization product, application-hosting product)
• Program leads own end-to-end accountability for the execution of agile programs covering product road maps funded by capabilities.

Copyright © Technology for Alpha LLC

Figure 1 – The agile investment quartet and focus areas

Ideally, business leaders and capability owners agree on key initiatives, i.e., epics, during a planning cycle, typically run annually and refreshed semi-annually or quarterly. Capability owners and product managers decompose epics into smaller units of change, i.e., features, and they sequence them on the appropriate product road maps. The road maps are then mapped onto release schedules of the program, for which the program lead is ultimately accountable.

You may notice a strong sense of separation of duties in my description above. Your observation is right, and it is by design. The above process requires strong collaboration, friction-less interactions and fulfilled commitments among these four roles for agile programs to measure up to the stakeholder expectations. If you happened to search through the agile literature, you probably have found abundant discussions on collaboration and culture, but not so much on interactions and commitments, because running an enterprise-scale agile program wasn’t the primary focus of the original agile manifesto and most of the subsequent methodology efforts. Below, I will propose a few principles to address this gap:

1. Epic and feature definitions, e.g., scope, cost and timing, product road maps and release plans, represent formal commitments among the members of the agile investment quartet, in Figure 1.
2. Enterprise-scale agile programs are accountable for the capability outcomes; the business outcomes are not an appropriate direct measure for their success
3. As an agent of the capability outcomes, each epic and feature represents a commitment between a single capability owner and a single product manager.
4. Projects represent the way to fund and coordinate work at the capability level among multiple functions and products. Their jurisdiction of control doesn’t extend onto the activities of the agile teams.
5. Sizing is not estimating. Agile teams size their build effort; the program and portfolio management team estimates the overall program effort and cost.
6. For all teams, past performance is the best indicator of ability to meet future commitments.
7. Estimation is not a one-time activity during the planning cycle, but an iterative process fed by a continuous feedback from stakeholders, program teams, and customers to the agile investment team. Estimation rigor grows proportionally to the confidence in inputs.

These principles are not widely used yet. Instead, most organizations fall into one of the following three categories when it comes to scaling up agile capabilities

• Risk Averse – Leaders are aware of the gaps in their program governance and controls to confidently scale up agile initiatives. Hence, they deliberately slow-down the program ramp-up, engage in extended proof of concepts, and encourage their “self-organizing” teams to figure out how to run agile. 
• Control Focused – These organizations implement a modified version of agile to counter the perceived weaknesses of the original methodology. They require extensive planning and analysis of features and stories before any design and development can start. The end result is a modified waterfall program that is disguised under the banner of agile without its benefits such as speed, flexibility and innovation. 
• Early Adopter – These organizations believe that one can’t learn how to swim on land. They invest significant financial and management capital to get these programs off the ground as soon as possible. Results are mixed. Some organizations have reported success in getting their scaled agile programs running, while others suffered. I’ve seen cases where an individual feature cost became 5x, program cost 2x and program schedule 3x of the original estimate on the very capable program leaders’ and sponsors’ watch. The problem was that most of these leaders were misinformed about the performance of their program because of the inappropriate use of retrofit program controls and metrics.

Still, we don’t hear often about troubled agile programs in the news, industry and professional magazines or alike; and, Gartner just reported that 89% of the surveyed organizations saw themselves as highly or moderately successful with agile. What is going on?

Interestingly, agile programs never blow up in the same way their waterfall cousins do when delivery milestones or budget forecast are missed. Instead, when agile programs are sick, they bleed insidiously. They don’t miss budget targets because team capacity is fixed, and they don’t miss deadlines, because scope is variable. But, they suffer when commitments to specific outcomes are due, and business leaders and capability owners start complaining about missing functionality.