A mentor of mine from twenty years ago recently asked: "Can Agile commit to long term commitments needed by executives to run their business?" I answered with conviction that it certainly can, but when I went on to explain, I realized the answer is fairly complex. To simplify, if you prefer managing with data, you will love agile.
Executives' fiduciary responsibility is to make prudent investment decisions with information "reasonably available” to them. Traditionally, they have employed project planners to assemble highly detailed investment plans with precise cash flows tracking multiple years of projected project investment and performance. After the plan is approved, there are hundreds more hours spent managing the project budgets, variances against the plan etc. FAS86 rules have further motivated project planners to collect detail plan information to qualify for project capitalization.
"If you prefer managing with data, you will love Agile."
Such detail estimating across long planning horizons is recognized by many software managers and directors as unrealistic planning, which consumes many months of critical resources that could be better spent on value-added product delivery. According to the Standish Group research, only 9% of large company projects were "successful."1 The remainder came in over budget, over schedule, or under delivered, and often with sacrificed quality (including unfixed defects). While large capital project spend can be controlled, the real problem is that execution is inherently non-deterministic. Many CIOs, BU Presidents, and Engineering VPs have lost their jobs from over-commitment and under-delivery.
"Execution is inherently non-deterministic"
The root cause of unpredictable program execution is not the lack of information that is "reasonably available," but rather the lengthy planning horizon and inherently non-deterministic delivery system coupled with the lack of objective milestones used to monitor and adjust progress. Proper "Agile" planning and delivery "turns the waterfall system on its side," to the effect that these problems are directly addressed. Agile transformations, when implemented properly, provide "delivery capability" that builds credibility and removes the need for detailed project accounting. Instead, companies are transitioning to strategic funding, rolling planning, and decentralization of project decision authority. The latter requires substantially less management overhead and delays as self-organizing teams deliver the work. Furthermore, cycle times from plan to delivery are substantially shorter, which provides the strategic capability to respond to changes in business conditions.
Progressive Planning and Agile Funding
The sprint (usually 2 weeks) and the quarterly plan are estimated, committed, and executed upon by the delivery teams. The 9-12 month road map, updated quarterly, is realistic based on rough estimates, demonstrated capacity, and steering adjustments from rolling planning and new market information. Strategic funding and longer-term planning is based on known capacity, SWOT analyses, and scanning of the environment. Rolling planning based on a changing environment manifests as adjustments to programs in increments, one team at a time, on a quarterly basis based on planning / execution time box boundaries. In Agile, work items are broken into such small chunks (stories), that they can be prioritized and delivered in a way in which highest customer value is continuously realized. There is a "minimum viable product" as an initial test of the market, followed by incremental improvements in user enablement.
Predictability
Through Agile, we break the large project into many small deliverables of working software... small enough to be delivered a just a few days. By measuring many small projects to an objective definition of “done,” Agile teams understand their capacity based on data. This same data is used for accurate projections and for instilling confidence among executive stakeholders.
Delivering Agility through DevOps
Agile without continuous integration and deployment doesn't deliver the benefits needed to lift the requirement for project accounting. As long as there is calendar time associated with integration and release processes, there is uncertainty related to making the product fully customer-quality ready; it needs to be fully integration tested, defects need to be fixed, and it ultimately needs to be deployed to customer environments. Customers need training and support needs training. All of these activities must occur before customers are realizing benefit.
3 Not-so-Easy Steps
After an organization implements 1. Progressive Agile planning, 2. Agile execution, and 3. Modern DevOps, then and only then will it have all of the capabilities necessary to build confidence and credibility among its executive level stakeholders in order for the traditional project accounting and annual budgeting processes to be transitioned to rolling planning and strategic Agile funding.
1. "The Standish Group Report: CHAOS." Project Smart, 2014, www.projectsmart.co.uk/white-papers/chaos-report.pdf.
