I’m reading the excellent Switch: How to Change Things When Change Is Hard. And in it I stumbled on a interesting story, and when I started to think about how it could be applied in the Software development world I really got excited. But all in due time. Here is the story, in my shortened and simplified form (be sure to buy the book):
BP
The example is taken from a chapter (4) called Point to the destination that talks about good ways to show people where the goal is. Surrounding this example they are talking about sending a postcard from the future; Hey, look how warm and wonderful everything is here in the future when we have changed all that stuff…
Then the authors gives an example from BP (Yeah, I know that might sit bad with most people nowadays but forget the well in the Gulf for a while). In 1989 BP was best of breed in drilling holes. They struck oil in 1 of 5 holes they drilled, way better than the branch average of 1 of
- But drilling oil wells are expensive… very expensive and they needed to get better.
So to change that (record/attitude/fact) Ian Vann, the head of explorations at the time, gave them a crystal clear goal: “No dry holes!”.
Yes, that zero holes without oil is acceptable. Of course that sent chock waves through the organization; “That cannot be done!”, “It’s just ridiculous”, “Haha – well get back to the real world, for a while!”. But after a while the people in the organization started to think about how they could change their work to support that goal. “What could we do so that no more dry holes appear?”, “What in our way of doing things is making them drilling dry holes?”
And of course the story wouldn’t have been included in the book if BP didn’t succeed. They drilled only 1 of 3 dry wells. And is not satisfied. The relentless search for better results continue.
Software
OK – what would be the equivalent to “No dry holes!” in the Software business… Well that’s easy: “No more bugs!”
Here is my postcard from the future: It’s wonderful over here. The code we’re writing is matching the requirements and doesn’t contain any errors. Also the customer is always satisfied with all our releases. Finally the application runs like a dream – it hasn’t been down in two years…
And now I can almost hear you all: “That cannot be done!”, “It’s just ridiculous”, “Haha – well get back to the real world, for a while!”.
Well that’s our goal!
- How should we define bug? Right now it’s used as a work item tracker in many organizations.
- What would have to be changed in your department to reach “No more bugs!”?
- How would we have to change the way to cooperate with others to reach “No more bugs!”?
- What would change in the way we write requirements, code, test, deploy to reach “No more bugs!”?
I thought that it was interesting to think about. And I realized that we, at least, have much knowledge at our disposal. We know good ways to write great code, we know good ways to cooperate around demands, etc.
But – WE DON’T DO THEM (amazingly?!). We have come to accept bugs as part of the normal flow when creating systems. And we blame each other for them… “If only the requirements have been clearer”, “Well, the testers need to check that…”, “It doesn’t take longer to code right than it takes to code wrong”
At Toyota they have as one of the pillars of the TPS respect for the individual. One place where you can see this is when something goes wrong; say that someone drops a piece on the floor. The Toyota way never blames the individual worker – they blame the system. “What is wrong in our process that make him drop that piece?”
What if;
- we stopped to accept bugs as normal things
- we stopped blame each other and looked to our process to find the problems
- we, as a team, took responsibility of the whole process – instead of blame each other for problems in our small piece of the complete flow
Well, that’s just some thought that have been working in my brain this morning.