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 outcome.”
A discussion is raging at LinkedIn about the Iron Triangle because the co-authors of Scrum say that “Scrum breaks the Iron Triangle”. This, you can imagine, causes ripples through the Project Management community.
Dr. Sutherland and Ken Schwaber speak of “Velocity” and, to explain how Scrum breaks the Iron Triangle, they're known to say that a Scrum team increases their Velocity by reducing hand-offs, increasing quality, et cetera.
I don’t often weigh in on discussion of Velocity — I find the metric too easily gamed and it brings out the worst in managers — but it’s an important discussion and warrants clarification.
In Product Development, the end state cannot be known in advance of starting. To put in Project Manager’s terms: the scope cannot be known in advance of starting. Even after starting, product scope changes rapidly as market conditions and users’ needs change or become better understood. Therefore, the Iron Triangle is a weak model to apply in Product Development.
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 (scope) 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. Furthermore, our civilization has built millions of houses worldwide and the factors of time and cost are well-known and predictable. Thus, the Iron Triangle can be useful to inform discussion and decision-making:
- Would we like to speed up construction of the house? Yes, so let’s spend more to hire more contractors. Will quality suffer if we add more contractors? No, engineering specs and quality standards are well-regulated.
- Will cost increase if we add another bedroom and detached garage? Yes, unless we buy cheaper materials throughout.
See, our choices regarding scope, time, or budget have predictable outcomes because the variables have predictable relationships. The Iron Triangle model can help us understand those relationships.
The same is not true in complex problem domains such as Product Development, Scrum’s sweet spot. Not only are the variables unknown, many are unknowable. The relationships between constraints of the Iron Triangle are often counter-intuitive:
- Would we like to speed up development of the product? Yes, so let’s not spend more to increase the size of the team.
In complex settings, such as software development, the Iron Triangle 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”. So, what is the weakest link in the work of a Scrum team?
In complex, adaptive problems, the weakest link is not scope, nor quality, nor time, nor cost, nor knowledge, nor technique — it is team cohesion. Note, those factors aren’t present in Iron Triangle. The only way to force the Iron Triangle model in this realm is to change the definition of ‘time’. I mean, we might consider time to be, not just variable, but a changeable dimension. Hmm… how to explain…?
Let’s consider a Scrum Development Team: As a Development Team increases cohesion, 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?
Yes, weird. So, the Iron Triangle is a square peg versus a round hole.
Let’s get back to ‘Velocity’
Yes, the authors of Scrum have discussed Velocity in depth. I’d like to remind everyone of the definition of Velocity...
Velocity is a measure of distance travelled over time. In other words, in Scrum, Velocity is the *distance travelled through the Product Backlog* over *Sprint Length*. To say Velocity is the speed of the Scrum team is inappropriate. More accurately, 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 they are going faster. It often means they are going smarter. A Sprint is a learning cycle in which the team learns about their problem domain and they learn (hopefully) to work together more effectively. (Where’s ‘learning’ in the Iron Triangle!??) When we say Scrum “breaks” the triangle, we're talking about this very notion of learning. As the team learns to work together, they cohere, they learn to make better decisions, and they make better decisions faster. This has at least two important outcomes:
- the team can eliminate wasteful decision-churn;
- and their high-quality/high-cohesion decisions enable effective shortcuts through their problem domain.
Thus: One of the ways a team increases their velocity is BY DOING LESS WORK.
As a Scrum team travels through their 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 with 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 their backlog each Sprint while not working harder/more. The Iron Triangle does not help us to model these emergent constraints: team cohesion and learning — the model therefore breaks down in complex environments.
***
This article is also published at scrum.works.
Closing
What’s your take on this? Is your experience similar to mine?
If you’re interested in learning more from me, visit my site and contact me to explore the opportunities for your organization.
Join me for a Scrum.org course: scrum.works/classes
And consider adding my recent book to your library: davidsabine.ca/phoenix