Beyond Scope, Schedule, and Cost: The Agile Triangle
Original seminal article from Jim Highsmith
I mentioned the Agile Triangle in a prior post on technical debt, but it requires more than a passing mention. Many agile teams are faced with the paradox of being asked by management or customers to be “adaptive, flexible, or agile,” while at the same time being asked to “conform to plan,” where the “plan” is a traditional Iron Triangle plan based on scope, schedule, and cost. We ask teams to be expansive, to work closely with customers and respond to them, to seek value—but then we penalize them for being 10% over budget.
The Agile Triangle, shown in the figure and introduced in Agile Project Management2nd Edition), addresses the real goals of projects—producing value that delights customers, building in quality that speeds the development process and creates a viable platform for future enhancements, and delivering within constraints (which are scope, schedule, and cost). The Agile Triangle alters how we view success.
First, let’s look at value. A number of studies have shown that 50% or more of functionality delivered is rarely or never used. Even if some of that functionality is necessary, for example the functionality for year-end accounting close, there is still a huge percentage of unused functionality in most software systems. This leads the conclusion that scope is a very poor project control mechanism—we should be using value. Furthermore, rather than asking, “Did we implement all the requirements?” the question should be “Can we release this product now?” I’ve known projects that were deemed releasable with 20-30% of the originally anticipated functionality—and the customers were delighted. They got their fundamental needs met—very fast!
The Agile Triangle elevates the critical role of quality, a dimension we have given lip service to for far too long. If we are serious about quality then it deserves a primary place in any measurement program. Quality comes in two flavors—today and tomorrow. “Today” quality addresses the current iteration or release of a product. It measures the reliability of the product—“Does it operate correctly?” If a product operates reliably, it delivers value to the customer in the form of implemented features. Products that are un-reliable, ones that give incorrect answers or periodically fail completely will fail to deliver current value.
The second dimension is future quality—“Can the product continue to deliver value in the future?” The ability to deliver in the future tests an application’s ability to respond to business changes, both anticipated and unanticipated. While we can often use flexible designs for anticipated changes, allowing for tax table changes for example, the strategy to deal with unanticipated changes is different. Responding to the unanticipated future requires adaptability, and the key to adaptability is keeping technical debt low.
The final piece of the Agile Triangle is constraints—scope, schedule, and cost. It’s not that these elements are unimportant, but they are not the goals of a project. Constraints are critical to the delivery process; they establish clear boundaries within which the team must operate. However, only one of the three can be paramount, and on agile projects this is normally schedule.
The Agile Triangle gives us a different way of looking at success, a way that resolves the paradox of adaptability versus conformance to plan.