Scrum and the Iron Triangle
In a previous post I described how teams at Toyota use Ba to transcend difficult problems with no easy or obvious solutions. Scrum has its foundations firmly rooted in Toyota’s approach to product development. A few weeks ago, Jeff Sutherland gave me a keen insight into that relationship. Jeff explained that Scrum practices are designed to bring about the same Ba energy that helped Toyota’s product development groups “transcend paradoxes”. This happens at many levels; for example, a self-organized team iterates over solutions to a difficult technical problem until a novel solution is discovered.
On a different level the iron triangle is another software paradox. Project managers, development teams and product ownership is forever bound by the constraints of schedule, scope, and effort: two of these three variables can be locked, but the third cannot or else the project is over-constrained.
Jeff pointed out that the Scrum process itself is an innovation that transcends the paradox of the iron triangle. Scrum does not explicitly break the iron triangle; rather, Scrum brings new dimensions into play that give the product ownership, project manager and development previous unrealized options and benefits.
- Teams are more productive, producing software more frequently and with better quality.
- Product Ownership has frequent opportunity for feedback during the “lifecycle”. With opportunity to inspect and adapt the product midstream, the Product Owner ensures the right product is being built.
- The Product Ownership can now deal effectively with changing market conditions.
Alistair Cockburn has an article that touches on these concepts, but calls it “tricking the iron triangle”.
iron_triangle.png2.45 KB
At http://www.ambysoft.com/essays/brokenTriangle.html I go into detail about the implications of the iron triangle and how agile techniques can help you out.
- Scott