9 November 2023

One of the most difficult parts of making software products is helping stakeholders who are not software specialists understand why software delivery can’t “just go faster”. I’ve been thinking about what I believe is a misunderstanding of the “levers” that are available to software product people when planning releases. I think that misunderstanding has its roots in classical project management (building bridges and stormwater systems: not building software). I also believe that experienced product delivery practitioners with only the best intentions inadvertently disappoint their customers.

The classic iron triangle

Many people who have worked in project management are familiar with the concept of the iron triangle. Like most really famous models it’s origins are unclear, but the commonly understood version in traditional project management has been around for at least fifty years and looks like this:

It’s another way of saying that when you run a project you can’t have your cake and eat it too, i.e.:

• Increase the scope => late delivery
• Compress the schedule => reduced scope or more resources (money)
• Reduce resources => reduced scope or late delivery

Importantly - quality is not considered a variable: ideally we never compromise on quality.

This is sometimes summarised with: “good, fast, cheap: choose two”.

The iron triangle of product delivery

Here’s an updated version of the iron triangle (from Rally Software) that makes more sense for software product development, adapted for long-lived “products” rather than “projects”:

• Scope Value: how much customer value are we planning to deliver?
• Resources Capacity: how much team time is available (outside what is already committed to operations, support and maintenance)?
• Schedule Time to market: how quickly can value be realised?

Time to market is sometimes called “time to value”. It can be applied to a whole product being launched or the smallest feature. It’s the amount of time that passes before users get value from it.

This version of the triangle is a better fit for products, but it still has shortcomings when it’s used to explain managing software delivery, particularly when explaining to stakeholders who don’t have a software delivery background.

If we give you more money, can’t you go faster?

Let’s imagine we want to release earlier than originally planned. One approach would be to reduce the value we deliver to shorten the time-to-market. For example, perhaps we are planning to release after six two-week sprints, but instead we decide to release after the third sprint.

But, what if we don’t want to reduce the value we are delivering - what if we just want to shorten the time-to-market? Then, our only option is to increase capacity. However, that comes with a problem.

Increasing capacity in a software team is not easy, and it’s not fast. Finding people and convincing them to join is difficult and time-consuming. It also takes time for people to understand how to work together and to understand the product they are working on (to “ramp up”). That time is elapsed time: it can’t be shortened by throwing more money at it.

Based on my own experience, my rule of thumb for “standing up a team” is that it takes up to three months to hire, another three months to onboard to a point of productivity, and up to another six months to become highly performing. That means that if we want to increase capacity with the same capability we are used to, we’re probably already 12 months away from that capacity being available.

Value and quality

The nice, symmetrical, equilateral triangle used to demonstrate the triangle is misleading in another way too.

“Lean thinking” optimises for the flow of work through a system and is really useful in software development. Those of us engaged in technology delivery today usually know the dangers of a long time to market with a “big bang” release. We like to avoid risking spending a lot of time (aka “capacity” in the new iron triangle) creating something that misses the mark completely. Missing the mark might lead to miserable customers and a commercial failure.

Contemporary product practice encourages technology businesses to start with a minimum viable product (MVP), get it in the hands of users, learn from their feedback, and then iterate (The Lean Startup is a useful intro to the principles). From an iron triangle view, that means that the MVP approach:

• Optimises for time-to-market
• Constrains the amount of value we can deliver in each release (subject to capacity)

This can work really well with an early-stage product where there is a community of committed early adopters, an effective feedback mechanism, and it’s worth making mistakes while seeking an MVP. However, as a business becomes more established, the customer base grows, and customers become comfortable with existing products the potential negative impact of that approach increases.

If our definition of “minimum” or “viable” doesn’t match the expectations of our users, they might feel we have not delivered a product of sufficient quality and reject it. When we shorten time-to-market, we reduce value, and this can reduce perceived quality. I saw this in action at Xero, where we engaged our accounting practice users to evaluate an MVP and the strongest feedback was “please don’t send it to us until it’s finished” 😬.

The lesson is that despite the iron triangle suggesting we can hold quality constant, quality is partly dependent on value.

Putting it together

Next time you are explaining how the iron triangle works, don’t forget to explain why capacity is not as quickly changed as value or time-to-market, and don’t forget to explain the impact of reducing value delivered on quality!

Here’s my new-new iron triangle - it’s much messier - because that is exactly how making technology products is:

Are you having trouble explaining the constraints of product delivery to stakeholders? Is your MVP all “M”, and not really “V”. I can help! Read more at cronin.nz or drop me a line at gareth@cronin.nz.