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

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

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 —

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?

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,²

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 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.


  1. Fowler. M (2019), Is High Quality Software Worth the Cost?,
  2. Jeffries. R (2010), Quality vs Speed? I Don’t Think So!,
  3. Project Management Institute (2017), A Guide to the Project Management Body of Knowledge (PMBOK® Guide) — English, 6th Edition, PMI
  4. Pink. D (2009), Drive: The surprising truth about what motivates us, Riverhead Hardcover



Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Trev de Vroome

Information technology program and agile transformation leader, change catalyst, and educator.