Keynote - Quality vs/and Speed

Clarke Ching organised the online conference ToC Down-Under Summit 2021 at Sydney time. I was able to attend the first two presentations of each day. These are my notes of the keynote of day 2 given by Ian Larsen.

Pretty every conflict is a conflict between speed and quality. – Ian Larsen


Speed: the pressure to deliver an outcome within a reasonable time frame

Quality: the pressure to deliver an outcome that works as expected

Outcome: an outcome normally solves a problem. The pain/risk of the unresolved problem is reflected in the intensity of the pressures for both speed and quality

we see often people come into this conflict:

they want a solution fast, so they cut corners, the job is not good enough, deliver a better outcome, some of those outcomes are pretty hard to implement => takes for ever, as a customer, my outcome is not resolved => the pain and risk increases => customer creates pressure, we keep being in this loop

Endemic to all human endeavour

Many of us have heard these sayings many times in different cultures and languages:

  • Rome was not built in a day
  • Measure twice, cut once
  • A stitch in time saves nine
  • Haste makes waste
  • Fools rush in
  • Slow and steady wins the race

These are all answers to the speed/quality conflict

What they actually say: slow down and do it right from the first time

There is a natural tendency to speed

The conflict between Speed and Quality is endemic to all human endeavour

– Richard White, Founder and CEO, WiseTech Global

First Mantra - Slower Today, Faster Forever

Conflict: Speed vs Quality

Injection: Quality is Speed

By default, we want both speed and quality, but if you are forced to choose, choose quality.

It does not mean, you can slow down forever. You need to slow down at first to get quality.

Nine core mantras

at WiseTech Global

The Foundation Mantras:

need to be in place to enable all the other mantras

  • Slower today, faster forever
  • Lead with content
  • Anyone can talk to anyone at anytime for any reason

The Creation Mantras:

bring out the creative spirit within us all

  • Find the root cause and solve for that
  • Creative abrasion fuels collaboration
  • Win-win or no deal

The Force Multiplier Mantras:

build and reinforce our culture, our infinite fuel

  • Lead others, manage yourself
  • Culture eats strategy for lunch
  • Productivity at the centre of everything

None of these mantras are specific to software development

They are applicable to any kind of creative endeavour

The mantras are published on the website of WiseTech Global

The WiseTech Way

this is about software development

but each of them could be picked by any business

  1. Chunking

    smaller items are easier to design, build and test - speed and quality go up

    => small batch sizes

  2. Test First

    code fits the test, instead of test fits the code

  3. Defect First

    fix rate needs to exceed create rate consistently

    the moment we detect a defect we fix it => our backlog of defects is very, very small

    if you have a huge backlog of defects it impacts your customer service and your image

  4. Containment

    all failures are a failure of containment

    any time we have a defect we have a containment issue

    containment: review, quality checkpoint, …

    we have all sorts of containments, not only in software development: in marketing, in sales, in finance, … the containment is there to make sure that what you make is right

  5. Finish What You Start!

    multi-tasking and interruptions are enemies of productivity and flow

We go for quality first and speed tends to follow!

Once your quality is right you can improve speed

At the heart of every important conflict, is a breakthrough waiting to happen

Quality is Speed!


What about due dates

4 inputs to a creative endeavour: Scope, Quality, Budget, and Time

because software development is a creative endeavour, the output is uncertain, we are always writing new software, always creating

  • scope is fixed
  • quality is fixed
  • budget is fixed: budget is team size, you don’t want to increase time size because it will slow you down at first
  • so this leaves time that has to be flexible

what happens when time is fixed (deadline)?

corners get cut, quality will break first, because it is the hardest to measure, then it goes to reducing scope and then the consumer complains, then they insist to add more resources to the project to deliver, this actually slows things down even more

=> due date pressure => cuts quality, cuts scope and you won’t be able to deliver on time

we want project to be managed, we don’t want project management

the first thing project managers do is putting a due date on everything => people blow their estimates => it’s just a shit show

traditional project management overemphasises due date and due date pressure impacts quality and scope

Note: customers are not always right! they express what they want, not what they need

How do you align multiple efforts when you cannot commit to a due date

We don’t commit to a due date until very late

We continuously commit to a lead time: we can deliver this 2 weeks after you have met this condition

We typically communicate with customers when we expect to deliver, without committing, without signing a paper