Copyright \u00a9 2016 Technology for Alpha LLC. \nPART I - A modern day interpretation of\u00a0the AGILE MONEYfesto\n\n\u00a0\n\u00a0\nIn a recent report, Gartner estimates that about a half of today\u2019s 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.\nIn theory, the overall investment accountability for an enterprise-scale agile program sits on the shoulders of four key roles:\n\nBusiness leaders\u00a0own 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)\nCapability owners\u00a0are 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)\nProduct managers\u00a0own 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\u2019 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)\nProgram leads\u00a0own end-to-end accountability for the execution of agile programs covering product road maps funded by capabilities.\n\n Copyright \u00a9 Technology for Alpha LLC\nFigure 1 - The agile investment quartet and focus areas\nIdeally, 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.\nYou 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:\n\nEpic 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.\nEnterprise-scale agile programs are accountable for the capability outcomes; the business outcomes are not an appropriate direct measure for their success\nAs an agent of the capability outcomes, each epic and feature represents a commitment between a single capability owner and a single product manager.\nProjects represent the way to fund and coordinate work at the capability level among multiple functions and products. Their jurisdiction of control doesn\u2019t extend onto the activities of the agile teams.\nSizing is not estimating. Agile teams size their build effort; the program and portfolio management team estimates the overall program effort and cost.\nFor all teams, past performance is the best indicator of ability to meet future commitments.\nEstimation 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.\n\nThese 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\n\nRisk Averse\u00a0- 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.\u00a0\nControl Focused\u00a0- 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.\u00a0\nEarly Adopter\u00a0- 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.\u00a0I've seen cases where\u00a0an individual feature cost became 5x, program cost 2x and program schedule 3x of the original estimate\u00a0on the very capable program leaders\u2019 and sponsors\u2019 watch.\u00a0The problem was that most of these leaders were misinformed about the performance of their program\u00a0because of the inappropriate use of retrofit program controls and metrics.\n\nStill, we don\u2019t 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?\nInterestingly, 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\u2019t miss budget targets because team capacity is fixed, and they don\u2019t 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.