in

Ative at Work

Agile software development

Ative at Work

The Five Whys of Lean

Root cause problem resolution is one of the core practises in agile. If the engine requires new oil every 500 km we don't just top it up with oil. We fix the engine.  Adding oil is just a hack that leaves technical debt in the system and slows down our journey. It reduces our sustainable pace.

Good operations people get this. Many developers, however, do not. We would happily work overtime walking with a stone in our shoe rather than stopping for a moment to remove it.

To increase the awareness of removing the cause rather than treating the symptoms of the problem, Taiichi Ohno of Toyota implemented the simple practise of asking "Why?" five times when something went wrong. As we keep on asking, we get closer to true cause of the problem, not just its symptoms.

It is a simple technique and it works very well.

In my career I have seen many systems that take weeks or months to integrate and deploy after the developers declare them "done". When integration is very expensive people tend to put it off and build up huge batches of work-in-progress - software that the developers have declared to be done but which cannot be deployed to production yet.

From a Lean perspective that is a waste.

Taiichi Ohno's "5 whys" technique proves quite useful in a situation like this.

"Why not release to production at the end of each sprint instead of just once per year?" "Well, yeah, that's a good idea, but we can't do that."

"Why?". "It is very expensive".

"Why?". "We have to test it all and get all the bugs out."

"Why does that take so long?". "It's a manual test, and we have to deploy to a very complex environment and there are a lot of bugs."

"Why don't you do automated testing, then?". "Oh, we tried that - it does not work."

"Why?". "You see, we create tests but when we run them two months later they are all red....".

"Why?". "Time passes and so the monthly batch jobs run and update the data. This breaks the tests... so we can't do automated testing.".

"Why not let the tests create a set a known test data when they start and then test against that?". "No that wouldn't work. You see the test data is a snapshot of the production data."

"Why?" "So that we have examples of all the kind of data we need to test on. Creating the test data is very complex and takes too long."

"Why?" "Well, there is so much data to enter."

"Then why not automate it then?". "We cannot do that - you see, the legacy system does not really have the hooks for that."

"Why? - who wrote it?" "Don't be stubborn. We wrote it... but , you see management doesn't want us to change the legacy system since it costs so much to test."

"But that's the problem we are trying to solve!"

Getting to the root of the problem and fixing that is the core of lean and agile practises. Next time you encounter a problem, try asking the five whys, and ask yourself - "are we treating the symptom, or removing the cause?" This is the way to go faster and improve quality.

Published feb 20 2007, 01:06 by Martin Jul
Filed under: ,

Comments

 

Jan Daniel Andersen said:

I counted more than 5 why's :-).

Good post though!

februar 20, 2007 9:17
 

Jesper Rugård said:

Why'ing is a useful technique. The problems I have encountered as a consultant using this, is that I often haven't got enough knowledge of the domain to ask the really pertinent questions. And that just  blind why'ing feels like you are asking questions in order to ask questions. Often there are "good" reasons for why things are as they are, of course - or maybe I am just to easy to placate/convince.

This is had to guess at what meant. You need a test-driven sentence writing process :-)

"Why not let the tests to create a set a know test data when it starts and then test against that?"."

marts 21, 2007 11:48
 

Jesper Rugård said:

"This is had to guess at what meant. You need a test-driven sentence writing process :-)"

It seems that I need that too.

What I meant was: The following sentence makes no sense.

marts 21, 2007 11:56
 

Jan Daniel Andersen said:

LOL...

Jesper, I like your statement by example tecnique :-).

My guess is that what was meant was:

"Why not let the tests create a set of test data when it starts and then test against that".

BTW: I used WordUnit (http://www.waterfall2006.com/beck.html), when writing this :-).

marts 21, 2007 2:46

About Martin Jul

Building better software faster is Martin's mission. He is a partner in Ative, and helps development teams implement lean/agile software development and improve their craftmanship teaching hands-on development practises such as iterative design and test-first. He is known to be a hardliner on quality and likes to get things done-done.
© Ative Consulting ApS