Quality, Time, Scope – in the right order

Have you made a clear decision about how to order Quality, Time, and Scope in your organization? If not, you may not be getting the results you want.

Product development is a process of discovery. It is not possible to know in advance with certainty what capabilities are essential to adoption or market success. There are many sources of uncertainty: the market is developing; things don’t work as we expect them to; technology has unforeseen limits; people leave and are replaced, taking precious know-how with them. As a result, assuming you can make the perfect plan and execute it when developing product leads to disappointment.

Three ways of ordering Quality, Time, and Scope of a product

There are two working definitions of Quality: 

freedom from defects 

or 

fitness for use 

The first definition is about conforming to specifications, and is appropriate when customer requirements are presumed to be well known, as when manufacturing many copies of a design. The second definition is about marketability and usability and is much more appropriate in innovative development where requirements must be discovered. 

Scope is the breadth of capabilities or features of the offering. This is usually captured in a requirements specification, a set of agile epics or stories, or a conception of Minimum Viable Product (MVP).

Time can be expressed as an estimated release date, an imposed deadline or time-box, or an investment stream with a cadence of releases with fixed cycle time.

Without clear guidance on the relative priority of Quality, Time, and Scope, organizations tend to put Scope first, offering a wish list of capabilities as MVP. Once a scope-first program is underway and starts missing estimates (see column B), management tends to impose deadlines based on financial constraints. To make the deadline while checking off as much scope as possible, teams tend to push defects out into the field. You are left with software that pleases nobody. Unreliable, late, and incomplete. Poor quality causes reputational damage, poor credibility, and is much more expensive to fix than to prevent.

Why not (as in column C) put quality second and let the delivery date float? Time uncertainty is very hard for management and customers to understand. Leaders expect their teams to show progress often enough so they can identify troubled projects. Stakeholders expect to see progress points and may be making sales commitments on product delivery. Customers need to plan their own work and may have financial deadlines imposed on their ability to buy. The real world is not very accepting of time uncertainty. 

Making scope the dependent variable (column A) is cringe-inducing for most product managers, but it has some real advantages. First, without field evidence in the form of customer conversations and sales, nobody really knows what capabilities are important. So MVP and other scope driven ways of specifying products are often opinions of well-informed but fallible people. If you deliver high quality software on a regular cadence (meaning on a constant cycle time like every quarter) but miss some scope you have an immediate opportunity both to check whether the scope you missed matters, and another chance to get it right.

If you are late with a delivery or have poor quality, you will annoy essentially all your stakeholders. If you miss some scope, you will annoy a few, but have a chance to atone in the next release. Consistently delivering high quality software on a cadence makes it simpler to develop a continuous improvement culture and builds credibility with customers and internal stakeholders, especially if you communicate to them that they can count on the date and the quality even if the scope sometimes falls short. Your product managers will adjust to the idea that they have to choose the most important capabilities that will fit into the release, knowing that releases occur frequently enough that course can be corrected and shortfalls can be compensated. Senior management has transparency about progress because they can market test working software every release, and releases again happen reasonably frequently. 

So choose Column A and communicate this choice clearly to your team and stakeholders. Make scope the dependent variable and hold to high standards on quality and cadence. With those constraints the team can get creative about working in such a way that scope can be ejected from a release when it needs to be. Our understanding of requirements is imperfect, so our estimation is also imperfect. All we can really expect to do is improve with experience. A repeatable cycle of Quality, Cadence, Scope is a very effective way to drive this learning loop.