If you take the Iron Triangle to heart – quality, scope, time, choose two – then there’s no way to deliver high quality software features on any accurate estimated-beforehand timeline.
That’s what the Iron Triangle means.
So something has to slip – either time, or quality, or scope.
What usually happens is that two things slip initially – scope and quality. When the organization realizes that quality is sucking and that scope is not good enough, then time slips. Unfortunately, because of the previous rush to get something incomplete and not very good out, you’re way behind the 8-ball by this time.
You end up releasing something that’s not very good, doesn’t meet the desired scope, and is late anyway.
I have heard many people tell me that they could get software products out on time with good quality, but I think those people did something slightly different (see the possibilities below). The nature of software is that it’s unpredictable. The nature of estimates is that they are always too low. If you combine those two things then there’s no way to get the scope you expect out at the time you predict. Unless you do one of three things:
- “Sandbag” your schedule. This means putting enough slack in the schedule that the unexpected difficulties that arise when you work on new and innovative things don’t cause the schedule to overrun. This is very difficult to do, because management pressure against it is intense, but can be done. By the way, this is also what professional project managers do, even for predictable things like building houses and bridges. There’s always a buffer (and those projects are still often late). It’s not usually what these people mean, though, when they say they always release their software on time.
- Take the Iron Triangle to heart, and let scope slip. What this means in practice is usually what’s called a “release train.” You schedule releases every so often, like every three months, or every month, and whatever is done with high quality in time for the upcoming release gets to go on the train, and anything that’s not done simply waits for another train. At its most refined, this becomes a continuous deployment model, augmented by Kanban, perhaps. Each feature is worked on until it’s finished, and when it’s finished, it’s released.
- Deliver features incrementally. This is a variation on the release train model, where instead of waiting to release a feature until it’s finished, you decompose the feature into smaller parts and release them onto the trains as they are finished, based on timeboxes of development effort. There’s still a decision on whether the increment that’s been finished can be released, based on two criteria: 1) does it do anything at all useful? 2) Is it high enough quality? There are often situations where a partial feature can still provide value, even if it’s not everything you want from a feature. Often these incremental features are called “beta” or “early release” to distinguish them for the customer.
The reality is that even though you can’t, by definition, give an accurate estimate for anything interesting, it is possible to finish interesting things, and release them. The main problem is that you can’t really say when they will be finished. And so as a product person, because you are expected to be able to provide a roadmap, you need alternative ways to talk about it versus simply saying “We’re releasing feature A at this time, and feature B at this later time.”
I encourage people who think they can release a software product with a set scope and a set level of quality by a set time to try a) to convince me that they did it, and b) to teach me how to do it, because I’d like to know. I’ve never seen it happen in my experience, either with my own products or with the products of other teams and companies. I’ve only heard about it, from friends of friends. It sounds like an urban legend to me.