Agile Tetrahedron move above the PM Triangle for Value

Agile Tetrahedron - ver 1

Who can explain the classic Project Management Triangle?  I've found that everyone has heard of it and uses it fairly well in a sentence. But when it comes to actually explaining the analogy to the triangle the struggles begin.  Some call it the iron triangle - as if nothing can stretch or shrink it's features once set.  I created a plastic triangle that was adjustable to illustrate the nature of negotiation of each of the sides.


I want to move beyond the classic three variable problem of the project (scope, schedule & cost) and envision a model that describe the value that a project represents while maintaining the constraint relationship that these classic triangular relationships represent.  Enter the Tetrahedron - a platonic solid.  The tetrahedron has four faces, each face is a triangle, it is the simplest form of a pyramid with the base in the form of a triangle.

Highsmith's Agile Triangle

Jim Highsmith introduce the concept of treating the PM triangle of cost, schedule, and scope as constraints in his Agile Triangle by adding a fractal triangle at the vertex of his triangle of value, quality and constraints.  While other's had explained the iron triangle as having an aspect of quality on the inside that one obviously would never vary.  Well then if one is not varying quality while do we talk so much about technical debt?  Jim does a great job explaining that the traditional aspects are constraints and that the desire of a business is to derive out of these constraints something of significantly larger value than constraint space represents.

"Quality is a value to some person."  -- Jerry Winberg

Discussing this with my colleague Rick Stephenson we envisioned a more physical and tactile model.  A model that retained the constraints concept from Highsmith, but added the multiple aspects of value -- business, technical and customer value.  We desired to represent these three types of value as separate and independent aspects that must be attended to by the project team while staying within the constraints.  Yet it is the desire of the project's sponsors to raise the values as high as possible while minimizing the surface area of the constraint space.  When these desires are modeled in the tetrahedron with physical objects one can start to get a gut feeling for the tradeoffs that directors and managers must make in the project.  Build upon a small constraint base and the pyramid may become unstable.  Imagine the table upon which you are building your model to be the platform for your application - when the platform is shaky and unstable the application needs much more base surface area to attain a sufficient height (values).

In the model of the Agile Tetrahedron I made above I cut the business value face a bit and the technical value face even lower.  The idea was to show that those faces may not be completely required to deliver customer value within a given release (constraint).  Yet, one can see that extending that idea to an extreme may prove dangerous with a shaky platform.

Agile Tetrahedron model: print, cut, fold, play...

PDF of Agile Tetrahedron model ver 2.3 - print, cut, fold, play...

See Also:
Check out the Kickstarter Troxes - a new kind of tetrahedron-origami

How to make the classic PM Iron triangle  out of plastic drinking straws.
Beyond Scope, Schedule, and Cost: The Agile Triangle by Jim Highsmith
Patterns in Nature - Is there a fractal nature to the universe?