Beyond Scope, Schedule, and Cost: The Agile Triangle

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 Management 2nd 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.


    1. Patrick Masson says:


      I like the Agile Triangle, but I wonder how well it can be implemented. That is the iron triangles attributes are easily quantified and are easily understood: dollars, features, and time. The attributes of the Agile Triangle are more subjective. What is quality might be defined differently by folks, as would value.

      How do you define quality and value among interested parties who may all have different qualities and values? I would love to shift the conversattions I have with folks away from the traditional triangle to a discussion about just this, but am unsure how to put it all in practice.

      Thanks for sharing,

      • Pat, yes they are subjective, but I say that fuzzy measures of important things are better than precise measures of un-important ones. Value can be taken from project analyzes, NPV for example, and allocated to features on either a monetary or relative basis. For organizations that don’t do project-level financial numbers, relative numbers work fine.

        There are a number of quality measures that can be used for reliability, from defect levels to code complexity, and for adaptive quality (technical debt) some companies are actually calculating TD in monetary terms.

        The other thing is to think of project performance from a balanced scorecard perspective–all the traditional measures are still there in the constraints–but we are adding new ones that are value and quality related. As we use them more, the measurements will get better.

        Thanks for you comments,


    2. Hi Jim,

      We’ve been discussing the Agile Triangle a lot in the ThoughtWorks Studios group, and we had two main thoughts about this (other than the obvious one, which is that we really like it):

      1) In presenting this, we are going to use a simulation with concrete examples of decisions you could make, and how those decisions would reflect the triangle. As your diagram suggests, “Value” and “Quality” are high-level drivers which should always underlie decisions project teams will make on the ground about schedule, scope, and cost. It’s a huge breakthrough for project management to think explicitly about how to modify schedule scope and cost, but it’s also a more complex model to try to hold in your head!

      2) We are 100% with you on the importance of quantifying value for projects and pieces of projects, and on the feasibility of this kind of quantification. Projects are always launched based on some kind of ROI case–the trick is in keeping that case in play for the duration, and keeping metrics on value delivery over the long haul.