Project manager know: “We cannot have our cake and eat it too!” Managing projects is a lot about taking decisions within unpleasant constraints. I can eat that yummy chocolate brownie now, or later, but not now and later. Bummer.
The iron Triangle represents incompatible choices in project management. Traditionally, the iron Triangle represents three constraints and let you fix any two while keeping third constraint flexible. With just three constraints, the iron Triangle is a broad simplification of tough decisions project managers must take. There are more sophisticated models such as the Project Diamond, The Project Management Star, and many more. But more sophistication does not make life easier.
The iron Triangle for agile software development is value, scope, and effort. Pick any two, and keep the third one flexible.
3 Strategies: innovate, implement, improve
The iron Triangle value , scope, and effort for agile software development defines the following three strategies for your project:
value + effort
value + scope
scope + effort
More complex endeavours may combine multiple strategies at the same time.
Strategy 1 – Innovation: fix value and effort, flexible scope
Innovation projects create something new. They are typically timeboxed or costboxed and strive for maximal value. Innovation projects – more or less fancy – are typical greenfield-projects and are the poster child of agile projects.
Scope is often only vaguely known in the beginning and constantly refined based on user feedback. Scope comes in two flavours:
▪ Feature width: minimal functionality making the product usable.
▪ Feature depth: additional functionality making the product great.
For a given target user base, feature width is not so flexible: the number of basic functions the product must perform is given. Otherwise the product is not fit for purpose. If minimal feature width cannot be implemented within the given timebox or costbox, the project will fail. To safe the project – or our product idea –, you may retarget your product to a less demanding user base. In lean startup-parlance you do a pivot.
Basic functionality in feature width might be “payment options” in an online shop. You may offer just one option, but there must be at least one option. Just one payment option might do for some customer, but no payment option at all falls short of all expectations. The product fails.
Vertical feature depth improves your product: from barely demonstrable to full customer delight. The basic functionality – such as payment in our online shop – is enhanced and improved. The number of basic functions within the feature width remains the same.
There is usually much more wiggle room in feature depth than in feature width. Possibilities to enhance basic functionality are endless: there is always a desire to add more icing on that yummy cake. Still, a product needs a certain richness in feature depth to be fit for purpose for a given target audience. And again, if your timebox or costbox is too small for that minimal scope, the project will fail. It will fail, because either not all functionality is provided or the result is of poor quality. If the result is of poor quality, it will fail to create the value for the customer. Failure.
Strategy 2 – Implementation: fix value and scope, flexible effort
Implementation projects must deliver a given scope to achieve a required value. Replacing an old system with a new one for reducing operational costs, is a typical implementation project. Or implementing upcoming regulatory requirements to stay legal, is a typical implementation project. Typical brownfield projects: high expectations in value to create, well defined scope to deliver, little to no wiggle room. The only option is to accept the resulting effort – time and money – required to complete the project. Otherwise the project will fail.
The effort needed to complete the project is defined by the given scope – number of requirements or items on a backlog – and by the team’s velocity. A team’s velocity defines how much scope a team implements in time – typically per week or per month. The total effort for the project thus results from the size of the team and the duration needed to complete. With effort and the velocity of the team, time and cost are given as well.
Strategy 3 – Improvement: fix scope and effort, flexible value
Improvement projects change existing systems little by little: fixing some defects, make existing functionality a bit better, enhance the system a bit, add support for new or changing hardware, upgrade to recent version of the underlying technology stack. Often this work is not organised as a project, but rather part of daily operations. Still, the iron triangle applies.
Improvement projects have fixed effort: they are cost- or timeboxed. The Scope for the next release is the number of items the team can implement with given effort.
Improvement projects typically pick a rather low number of items from a rather long list of wishes. With given scope – number of items to be implemented – and effort, the resulting value is given. With a long list of wishes, there is however a lot of wiggle room: with picking the most valuable items from the list, vastly improves the result.
The iron triangle: value, scope, and effort
In software development, it is not possible to half the cost and double the time. One can half the team and double the time to deliver, but cost – all else being equal – is still the same: number of people x time. If the budget is constraint, the available time is constraint as well. If a deadline is looming, the budget which can be responsible be burned is given as well. Otherwise the resulting value – often in the form of bad quality – suffers.
Doubling the size of the team might be an option. While specific organisations might be able to scale, the effect of adding people to teams is generally unknown. Anything can happen: getting faster, slower, better, or worse. Thus, using value, scope, and effort as the three key constraints for software development projects leads to better decision making.