The ghosts of project management’s Iron Triangle still haunt agile teams

The Iron Triangle, a 60-year old project management metric structure, continues to frustrate agile project teams. Developed in 1969 by Dr. Martin Barnes, the Iron Triangle’s three dimensions are scope, schedule, and cost. This triangle should enable project managers to adjust as conditions change. However, too often in practice, managers view the three dimension as fixed and meeting all three planned estimates is judged “success.” Plans are considered “fixed and correct” and non-compliance with the plans reflect a fault in execution, not planning. For example, the Standish Group, researched software successes and failures for many years, defined project success as: “the project is completed on time and on budget, offering all features and functions as initially specified.” The use of the Iron Triangle expanded during the 1970s and 1980s, a period dominated by command-control managers who embraced the “solid and prescriptive” Iron Triangle.

In the early 2000s I began to hear Agile teams complain, “Management wants us to be agile and adaptive, but we also must conform to the project’s planned scope, schedule, and cost.” Management wanted agility but required traditional performance measures. If adaptation and flexibility are the trademarks of agile projects and conforming to plan is the trademark of traditional projects, then why did we continue to base success of agile projects using traditional measures?

As agile grew in popularity, so did interpretations of what it meant. The Agile Manifesto provided?a fundamental mindset, but practical implementations varied, even among the manifesto authors. I encountered an example of this during a presentation in Munich, Germany in the 2005 time period. After presenting my version of Agile Project Management to a dozen and a half software development managers from divisions of this multinational firm, one of the managers asked, “Our Scrum coach tells us that we can’t ask how long a project will take, how much it will cost, or what the final feature set will be. What do you think of that?” My response, “That is nuts!! Management has every right, and yes, responsibility, to ask such questions. How has your senior management reacted to this idea?” I asked. They grinned.

In part, the drive to get away from fixed commitments arose from prior “death march” projects that demanded strict adherence to the Iron Triangle plans. Some agilists, in their desire to retreat from unrealistic fixed commitments of the prior era, went too far towards no commitments.

We needed a measurement system that addresses both needs—adaptability and predictability—a tall order. The system needed to encourage adaptability on one hand and provide predictability on the other. But what it really required was a mindset change and then metrics that matched. Everyone—from developers to product and project managers to mid-level and senior managers and executives—needed to recognize the speed and uncertainties of today’s world required they accept adaptability as key to success.

Nothing highlights the historical mindset issue like the following quote from colleague Helen Pukszta at the Cutter Consortium. The quote always stunned me, but unfortunately was not abnormal. While this quote comes from the past (mid-1990s), it illustrates the ghosts that still plague us.

“I recently asked a colleague CIO whether he would prefer to deliver a project somewhat late and over-budget but rich with business benefits or one that is on-time and under-budget but of scant value to the business. He thought it was a tough call, and then went for the on-time scenario. Delivering on-time and within budget is part of his IT department’s performance metrics. Chasing after the elusive business value, over which he thought he had little control anyway, is not.”

Initial attempts to solve this paradox (I plan to write another article on the difference between a paradox and a problem) were velocity and the inverted triangle. Velocity, useful within a team to understand capacity, went from being a sometimes useful team tool to another way to bludgeon teams with a useless productivity metric.

Using the Iron Triangle in a slightly separate way—inverting the triangle with the “scope” pointing down was another attempt at measurement change. This inversion indicated that to meet time and cost plans, modifying scope would be acceptable. Some inferred that this version stressed quality, however the word quality doesn’t appear in it. This Inverted Iron Triangle was an improvement because it suggested more flexibility, but it failed to demand the radical change in mindset required.

As an attempt to resolve the paradoxical goals of adaptability and predictability, the second edition of my Agile Project Management (2009) book introduced the Agile Triangle (shown in the graphic). Its dimensions are:

• Value goal: Build a customer-valued, releasable product
• Quality goal: Build a reliable, adaptable product
• Constraints goal: Achieve value and quality within acceptable constraints (scope, schedule, cost).

The Agile Triangle challenges teams to constantly ask themselves: “Do we still think a valuable, quality product can be delivered within our constraints?”?

Who says Agile methodologies can’t deliver to a fixed date—I’ve done it (and others have also). In mid-2002, Alias Systems in Toronto, Canada, started developing Sketchbook Pro, a software package to be announced concurrently with the launch of Microsoft’s Tablet PC—a very fixed deadline. For Alias this was a new venture, adding a retail product to their successful commercial base, exploring a recent technology platform, and included the fixed deadline and a team size constraint. The team had a vision—an easy-to-use consumer-focused sketching product worthy of a professional graphics artist. They delivered a high-quality, feature rich product on-time and the product remains in the market 20+ years later.

Measuring success, especially when it includes value, can be tricky. Motorola’s 1990s ill-fated, multi billion-dollar, satellite-based Iridium project was a spectacular failure in the market. Meanwhile, the movie Titanic, which was severely over budget and schedule—and viewed by early pundits as a $200 million flop—was the first movie to generate over $1 billion in worldwide revenue. By Iron Triangle measures Titanic was a failure. Within some circles, Iridium was considered a success because it fulfilled the original specifications within cost and schedule budgets. Using the Agile Triangle, the Titanic project would be considered a success—it delivered value even though it exceeded its constraints. Iridium would have been considered a failure because it failed to deliver value, even though using traditional project measurements, it succeeded.

I want to go back to the last sentence of Helen Pukszta‘s CIO quote, “Chasing after the elusive business value, over which he thought he had little control anyway, is not.” This exemplifies one of the challenges of adopting an agile mindset; it’s harder than maintaining the status quo because measures of success, whether for projects, products, or enterprises are fuzzier, even while they are better.

A traditional manager concentrates on following the plan with minimal changes, whereas an agile manager focuses on “adapting successfully to inevitable changes.” While measuring value and quality can be challenging, they are worthwhile arbiters of success. But measuring via the Iron Triangle dimensions, while easier to measure, is less effective. By employing a 60-year-old metric in an agile delivery effort, we let the ghosts of the past haunt our path to the future.

?2023 by Jim Highsmith

#agilesoftwaredevelopment #scrummaster #agilemindset #agileprojectmanagement #agile #agileculture #scrum #agileculture #businessagility