I started my testing career eighteen years ago, mostly by accident.

I was a programmer doing tech support for a multimedia conference when I struck up a conversation with one of the presenters. Peter rang me up a couple of weeks later and said “We’re starting a testing centre, why don’t you come and help us set it up?”

“But I don’t know anything about testing,” I protested.

“That’s okay,” said Peter, “we’ll fly you to Seattle so you can learn.”

How could I refuse?

So after helping set up the hardware and network for what was to become the…

The way we measure production is fatally flawed.

In fact the way we look at work is fatally flawed.

In traditional service and manufacturing, managers are tasked with keeping men and machines busy. If the ‘plant’ is busy then it must be productive. The busier it is the more productive it is.

Typically this means running large batches of product in shifts which produce large amounts of inventory which are then stored in the hope a customer will buy them.

The Toyota Way

But about fifty years ago a revolution in manufacturing started at a company called the Toyota Motor Corporation. A unique…

I first encountered Agile in 1999 in London — and I wasn’t impressed. But in about 2009 I came across agile again, as head of Testing at Bankwest; and agile had changed. It had got smarter — it had grown up.

But it wasn’t until I started studying Lean that I began to understand where agile practices came from and why they were important — take continuous integration. Its a combination of a couple ideas from Lean, translated into the software development vernacular. It combines “one piece flow” and “error proofing” and “SMED”.

SMED stands for Single Minute Exchange of…

The Problem with Specifications

The traditional way of building software is to write down everything that the customer wants in a document called a specification or requirements document.

It doesn’t work very well.

Here’s something I wrote way back in 2005–06 :

In technical software projects, clients are generally unfamiliar with not only the concepts and terminology but also with the functionality that is being described to them.

Typically, the experts go through a lengthy and detailed design process and deliver a custom built solution, tailor-made to fit the client’s requirements.

At this point the client looks at it and says: “That’s not what…

There is a common ‘wisdom’ these days that software development should move faster. From agile to continuous delivery and DevOps, everything is about the need for speed.

But many people struggle to understand the benefits of ‘faster’.

At a gut level people believe that the faster they go the more they are able to do. But is more necessarily better?

Any system is constrained in its throughput by the throughput of its weakest subsystem.

If the purpose of business is to deliver value to customers, and the purpose of development is to modify or create software, then the ability of…

I came across an interesting example of perspective the other day.

A large company I was working with (and shall remain nameless) had commissioned a vendor to build and supply a software product. At the first major review it was discovered that the software was largely incomplete, full of bugs and the vendor wanted to issue a change request for several million dollars.

While there was much noise around the circumstances under which this happened, no one seemed to know what the real root cause was.

I did a little digging.

The locus of the problem seemed to be the…

I was listening to Mary Poppendieck the other night when I surprised myself by answering my own question. The long and rambling question had to do with the prominence of ‘design’ in Mary’s description of management roles.

Mary seemed bemused by the question, as if it was obvious that the managers of a product business should have design experience.

And then the answer dawned on me : ‘Design’ is to product businesses as ‘intent’ is to a military organisation.

Mary had been speaking about the ‘scaling dilemma’ — how do you scale self-organising practices like agile to an organisation level…

I recently devoured “Thinking Fast and Slow” by Daniel Kahneman.

It describes two systems of thought that drive our behaviour — the impetuous, intuitive System 1 and the rational, lazy and structured System 2.

As a very short and inadequate précis of Kahneman’s work: the book demonstrates that while we believe we are governed by our rational mind, our intuitive mind often dominates our decision making — and it’s often wrong.

I love the book.

Everyone seeking to understand decision making, the human mind, economics, society or the human condition should read this book and digest its lessons.

One of…