Sub-title: Breaking the Iron Triangle

Sub-title #2: Jeff Sutherland’s book could have been called: “Scrum: Twice the decision-making in half the time leading to half the work and twice the output.”
But every smart publisher would throw out that title.

A discussion is raging at LinkedIn about the Iron Triangle because Jeff Sutherland, co-author of Scrum, often says that “Scrum breaks the Iron Triangle”. This, you can imagine, causes ripples through the Project Management community. Mr. Sutherland also speaks of “Velocity” and sometimes as a way to explain the breaking of the Iron Triangle, he’s known to say that a Scrum team can increase their velocity by employing various patterns of behaviour which reduce hand-offs, increase quality, et cetera — and this “breaks” the Iron Triangle.

I have captured some thoughts on the subject below.

In Product Development, the end state cannot be known in advance of starting — that is, the scope cannot be known in advance of starting. And even after starting, the product scope changes rapidly as market conditions and users’ needs change and/or are better understood.

Therefore, the iron triangle is a weak model to apply. The Iron Triangle is a useful model only if the conditions which define scope, time, and cost have low variability. If building a house, for example, the end state can be known before starting its construction; apart from the paint colours and some finishing touches, every part of a house can be modelled and codified before starting its construction. Thus, the Iron Triangle can be useful to inform discussion and decision making: would we like to speed up construction of the house? Maybe…so let’s spend more to hire more contractors.  Will cost change if we add another bedroom and detached garage?  Probably, unless we buy cheaper materials.  See, the variables have predictable outcomes.

If developing product, such as creating software wherein the future states of the source code are unknowable, the iron triangle causes weird discussion and isn’t likely to improve decision-making. Perhaps other theories of constraints can be more useful.

Theories of constraints share a common supposition: “a chain is no stronger than its weakest link”. In complex, adaptive problems, the weakest link is neither scope, nor quality, nor time, not cost, nor knowledge, nor technique — it is common understanding or coherence.  Note, those factors are missing from the Iron Triangle. The Iron Triangle quickly becomes an irrelevant model in the realm of Product Development or complex/adaptive problem-solving. The only way to force the Iron Triangle model in this realm is to consider ‘time’ to be, not just a variable, but a changeable dimension. That is, as a Scrum team increases cohesion and alignment, they make decisions faster — this has the effect of making ‘time’ slow down, they can make more decisions per unit of time as though the team is travelling faster through time.  Weird, right?  So it’s just easier to throw away the Iron Triangle.

About Velocity

Yes, Jeff Sutherland discusses velocity in depth. But I’d like to remind everyone his definition of velocity…

Velocity is a measure of distance travelled over time. In other words, the *distance travelled through the Product Backlog* over *Sprint Length*. To say that velocity, in Scrum, is the speed of the Scrum team is quite inappropriate. More appropriately, an increase in velocity means the team is travelling further through the Product Backlog per Sprint.  It helps to stop thinking of the Product Backlog as a bunch of items and a bunch of story points. It’s more helpful to think of the Product Backlog simply as ‘the work that needs doing’ — a Scrum team can increase their rate of travelling through ‘the work that needs doing’ by…well…by learning.

An increase in a team’s velocity does not mean (necessarily) they are going faster. It OFTEN means they are going smarter. A Sprint is a learning cycle. The team learns as they work together. (Where’s “learning” in the iron triangle!??) When Mr. Sutherland  says Scrum “breaks” the triangle, I believe he is thinking of this very notion of learning. As transparency increases, the team can make better decisions, meaning they can eliminate waste (doing LESS work!!) and cohere more rapidly and achieve high-quality decision-making, thus going increasing their output.

“One of the ways a team increases their velocity is BY DOING LESS WORK.”

As a Scrum team travels through the backlog, a learning team will discover ways to reduce work per Product Backlog Item: they’ll figure out ways to automate a bunch of repetitive stuff; they’ll produce modular designs which create opportunities for reuse and adaptation; they’ll learn from their mistakes, reduce risk, and increase quality. (These are the results of learning as a team and one of the key reasons for Scrum’s rules that a Scrum team is small and has stable membership for long periods — communication saturation enables cohesion and therefore enhances learning…as a team.)

In other words, the team finds ways to travel further through the backlog each Sprint while not working harder/more.

Hence, the iron triangle as weak model for understanding the constraints in complex problems.

Tip: Angela Montgomery has written extensively about Theory of Constraints in complex settings — her writings are waaaaay more helpful to us in the realm of Product Development than the limited Iron Triangle.

Affiliated Promotions: