Operational Excellence – Principle 3: Draw a Line Below Which Quality Does Not Go
I. Problem Description
When you have aggressive deadlines or your project is running out of time or budget, there are only four things you can do:
- Reduce the scope
- Extend the deadline
- Commit additional resources
- Sacrifice quality
While the first two options are your best bets, and the third option is not always feasible, the fourth one (sacrificing product or delivery quality) is what most people would consider. There is a good explanation for why this can be appealing; sacrificing quality today will only surface in the future, and it will be someone else’s responsibility.
Sacrificing quality drags on your delivery capabilities. If left uncontrolled, it will transform your product from a lucrative asset to a liability. In the long run, sacrificing quality will have detrimental and irreversible effects on your business.
Peter M. Senge documented this organisational behavioural pattern in a 1990 book, The Fifth Discipline. Eroding Goals was the name Senge gave to an organisational dynamic describing a positive feedback loop where managers increasingly accept lowering standards to retain the same delivery capabilities.
In software development, Eroding Goals can be seen with rising technical debt. Technical debt makes the next delivery harder, requiring managers to accept more technical debt to keep deliveries on track. At some point, these become so slow that you risk being completely outrun by competition.
Keeping quality above a certain mark prevents organisations from slipping towards a path of earning goals.
II. Levels of Software Quality
Technical debt can be subdivided into four categories, not all equally problematic. This means managers can be selective when deciding which to carry and which to avoid. Let’s see what these look like:
III. Draw a Line Below Which Quality Does Not Go
The best way to remedy such situations is to avoid being exposed in the first place. This can be achieved by having an open and transparent discussion with business stakeholders every time the backlog is saturated with high-priority items and not waiting for it to overflow. A positive outcome of these discussions means reshuffling priorities, deadlines, or resources.
However, there will be times when moving things around (deadlines, scope, or resources) would not be feasible and when the only option left is delivering on time, regardless of the (technical) risk or cost (such as when the organisation’s reputation is at risk). What should managers do in this case?
The short answer is to draw a line below which quality doesn’t go. The long answer is in the following paragraphs, where we list a few guidelines and best practices for keeping software quality up to scratch.
IV. Guidelines for Maintaining Product and Delivery Quality
Though not mutually exclusive, product and delivery quality might collide head-on with scarce resources or aggressive deadlines. Product quality means building the right thing right, while quality delivery means fast and affordable delivery. Here is a list of actions managers can take when struggling with product vs. delivery priorities. The list is ordered from most recommended to least.
A fourth option, which must never be applied, is sacrificing long-term quality (carrying architectural debt and ignoring technical debt) for short-term wins. Despite its undeniable irrationality, managers may focus solely on the present if their jobs, bonuses, or careers depend on it. This can be observed in a system where the individual and the group’s interests are not aligned or contradictory. Therefore, the rewards system of incentives, benefits, and promotions must favour strategic goals.