I started off my career in IT as a tester or test manager and I’ve had twenty odd years of working around the world on companies big and small.
Just when I thought the IT industry had stagnated and was subsiding into a morass of blunt instruments and simplistic aphorisms — along came a paradigm shift, the like of which I believe we have never seen before.
Cheap storage and virtualisation led to the cloud revolution which led to continuous integration which led to devops… well it hasn’t been quite like that, but you get the idea. …
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 “Australian Multimedia Testing Centre” (now Access Testing in Sydney), I flew to Seattle, to a place called STLabs. They did testing for Microsoft and Adobe and a bunch of other software companies on the west coast of America. …
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.
But about fifty years ago a revolution in manufacturing started at a company called the Toyota Motor Corporation. A unique combination of individuals came together to develop a system that became known as the “Toyota Way” or Lean. …
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 Dies. …
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 I want!” …
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 a business to deliver value via software is determined by the throughput of its software development process. …
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 old chestnut that the vendor didn’t understand the requirements… or that the customer didn’t specify them properly, depending on which view point you took. …
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? She elegantly illustrated that by creating autonomous, cross-functional teams you just trade ‘vertical’ silos in your organisation for horizontal ones. …
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 my favourite anecdotes comes from Kahneman’s time working with pilot instructors for the Israeli Air Force. He tells them that positive feedback works much better than negative feedback, an observation hotly disputed by the senior instructors. “When we yell at pilots, they get better,” they say. …
One problem I often encounter in business (startup or otherwise) is a lack of clarity, a lack of direction.
As I detailed in an earlier post linking your strategic goals to your day to day activities is essential to stay on track, to stay focussed and ultimately to deliver. And while people are often able to construct a set of high level goals and link low level tasks to them it often becomes confused as complexity emerges and the links become tangled and obscure and people lose their way.
At any given point in the day people turn to me and say “What should I be doing now?” …