The Speed of Quality

Too often I see businesses struggling with their software delivery — leaving leaders frustrated that their software teams are not moving fast enough, and conversely, software teams are frustrated they never have time to do the job they aspire to do.

Leadership inherently win — and another ‘last exception we’ll make’ is rushed into the project, making it more brittle, staff more frustrated, and the overall development process slower.

Yet if we were to step back for a moment — we can quickly see just how important quality is to fast and adaptive delivery.

The compromise that is Quality

Now traditional project management would tell you that you need to negotiate three constraints: Scope, Time, and Budget.

The old ‘Iron Triangle’ of Project Constraints

Yes — we see whole chapters of standards like PMBOK dedicated to ‘Project Quality Management’, where they sensibly link the management of quality to some company standards:

Project Quality Management includes the processes for incorporating the organization’s quality policy regarding planning, managing, and controlling project and product quality requirements in order to meet stakeholders’ objectives.⁴

So while project management has quite old mechanisms for managing quality, the reality is they aren’t employed in many projects — due to a number of reasons including:

1. Traditional project management methods are too heavyweight for many deliverables —with little justification for specific management plans for each paradigm of delivery.
2. Rarely do organizations have an appropriate quality policy documented in the first place — nor do delivery teams have a clear and common understanding of the quality expectations
3. When policies or standard exist surrounding quality — they tend to either be too specific to apply to all deliverables — or with most software projects delivering new functionality, it’s rare that old quality standards apply to new problems
4. Quality is commonly seen as a technology problem alone and not one that concerns the business or customers.
5. The impact of quality adjustments is rarely quantified — compressing quality in lieu of time prevents the business from being available to properly capture the quality concerns and their impact.

The power of quality

To many — the old iron triangle implies that quality is some fixed point that is pre-determined. But the reality is it needs to be flexible, but still kept high enough for the problem at hand to avoid incurring significant technical debt.

We also often see quality as the area of software project delivery that is seen as the most flexible throughout delivery. Indeed, if you have fixed scope, time, and cost — the only thing left to flex is quality.

And with that flex we inevitably see flow-on effects broader than the technology itself — as culture cares less about quality over time, the connection with the people we’re delivering this for is lost. We lose touch with Human Quality.

Human Quality is about more than just technology — AccessHQ.com

It impacts the customer for whom we’re building the product, and it impacts the business in which we need to be profitable and competitive in our market.

How does quality impact technology?

In the technical space — quality compromises manifest themselves as technical debt, which has a number of consequences to the business as a whole⁶:

Unpredictable tipping point
Increased time to delivery
Significant number of defects
Rising development and support costs
Product atrophy
Decreased predictability
Under performance
Universal frustration
Decreased customer satisfaction.

And with every compromise on quality, we incur more technical debt — be it:

1. Naive Technical Debt (aka. Reckless Debt) — Irresponsible and avoidable debt incurred through immaturity and deficiencies that lead to sloppy design. Can be avoided through training, understanding, and sound business decisions.
2. Unavoidable Technical Debt — Unpredictable and unpreventable debt, often a result of early implementation decisions that need to change as validated learning occurs, and changes are identified as needed.
3. Strategic Technical Debt — Deliberate debt incurred in a strategic manner, trading off debt for leverage against some important or time-sensitive need.

What this creates is a build-up of ‘cruft’ — “the difference between the current code and how it would ideally be.”². Over time that deviation compounds, and creates more challenges for our technical teams to overcome — slowing the delivery of new functionality further as time goes on:

Keeping quality high pays off in the long term, https://martinfowler.com/²

As Ron Jeffries noted:

If slacking on quality makes you go faster, it always comes at the cost of longer term quality.³

Establishing a culture of Quality

We need to stop thinking of quality as the first item to flex, and instead, look at quality as a pre-requisite for the outcomes you’re after — including technical, customer, or business outcomes.

We should think of quality as a natural speed limit on our ability to deliver and adapt our projects and initiatives — remembering that:

Everything that goes wrong in a process shows up as a time delay.¹

Quality is at the heart of speed and outcomes on delivery of anything — compromising it is a compromise across all aspects of delivery and should be avoided at all costs.

References

1. Poppendieck. M & T (2006), Implementing Lean Software Development: From Concept to Cash, Pearson Education (US)
2. Fowler. M (2019), Is High Quality Software Worth the Cost?, martinfowler.com
3. Jeffries. R (2010), Quality vs Speed? I Don’t Think So!, ronjeffries.com
4. Project Management Institute (2017), A Guide to the Project Management Body of Knowledge (PMBOK® Guide) — English, 6th Edition, PMI
5. Pink. D (2009), Drive: The surprising truth about what motivates us, Riverhead Hardcover