Agile Zone is brought to you in partnership with:

Mike is a certified PMP project manager and a certified ScrumMaster. Mike was involved with the creation of the DSDM Agile Project Leader certification, holds this certification at the Foundation, Practitioner, and Examiner levels. Mike was named an honorary member of the DSDM consortium and served on the board of APLN and the Lean Software and Systems Consortium. He currently co-leads the PMI Agile Community of Practice. Mike is a DZone MVB and is not an employee of DZone and has posted 148 posts at DZone. You can read more from them at their website. View Full User Profile

Replacing the Iron Triangle of Project Management?

  • submit to reddit

Last year sometime, I heard Jim Highsmith do a talk on replacing the traditional project management iron triangle with a new 'agile triangle' that is based not on time, cost, and scope... but instead, based on value, quality, and constraints (time, cost, and scope). This is a concept Jim introduced in the latest release of his book Agile Project Management: Creating Innovative Products. Something in the idea has been bugging me a little, so when I read Isreal Gat's post this morning, discussing ways to use Jim's agile triangle, it got me thinking.

The general idea behind the agile triangle is that we need to take the focus off of delivering to a set schedule, a fixed budget, and some predetermined set of deliverables; and focus more on the value the product is delivering. In principle I agree, but does it make sense to modify to triangle to deliver that message?

I've always looked at the iron triangle as a way to explain the relationship between time, cost, and scope. If you change one of the three variables, the physics of project management says that one of the others has to change too. If I want to add scope, time or cost has to go up as well. If I want to deliver in less time, I either need more budget or I need to reduce scope. If I want a less expensive product, I either need to reduce scope or reduce the time it takes to build it.

I'm curious if the agile triangle follows this same pattern. If I increase value, does quality have to go up or down? Do the constraints have to change? What about if I change quality? Does value go up? Do I have to change the constraints? What about the constraints? If I tweak the constraints, does that always impact value or quality? There are some guesses that we can make, but the agile triangle doesn't give us any guidance. The relationships between the variables are less precise, and therefore I think using the triangle metaphor is less powerful.

We all know of projects that have come in on-time and on-budget, with everything the customer wanted, and have been total failures in terms of market performance. I agree that we need to focus on value and quality as first class citizens in the project management discussion. To me though, quality and value are attributes of scope, and it just comes down to the definition of done. Do we have features in our backlog that are 'done' when they have poor quality? Are they 'done' if the customer does not accept their value? Value and quality are part of the acceptance criteria of scope.

I would probably flip what Jim did a bit and leave time, cost, and scope as the vertices of the triangle, but just like Jim broke the constraints into three attributes, I would break scope into three attributes... requirements, quality, and value. So, the question is... are value and quality project constraints or attributes of scope. I think you know where I stand ;-)
Published at DZone with permission of Mike Cottmeyer, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)


Mark Bick replied on Wed, 2010/02/24 - 1:08am


At this stage of agile maturity, I would agree with keeping the three vertices of 'time, cost and scope'. Primarily because most organisations still use them for project management purposes and agile is at a stage where it is integrating the agile understanding of 'deliverable, quality and value' into current thought. Using the model you have suggested can help with the integration. This isn't to say that current project management frameworks do not require deliverables, quality and value. Agile simply thinks and does it differently.

Merging them into 'scope' works for me. For now.

Thanks for the point of view.


Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.