From Wikipedia

The 5 Whys is a questions-asking method used to explore the cause/effect relationships underlying a particular problem. Ultimately, the goal of applying the 5 Whys method is to determine a root cause of a defect or problem.
Example

Why? - The battery is dead. (first why)
Why? - The alternator is not functioning. (second why)
Why? - The alternator belt has broken. (third why)
Why? - The alternator belt was well beyond its useful service life and not replaced. (fourth why)
Why? - The vehicle was not maintained according to the recommended service schedule. (fifth why, a root cause)
Why? - Replacement parts are not available because of the extreme age of the vehicle. (sixth why, optional footnote)

Start maintaining the vehicle according to the recommended service schedule. (5th Why solution)
Purchase a different vehicle that is maintainable. (6th Why solution)

Tendency for investigators to stop at symptoms rather than going on to lower level root causes.
Inability to go beyond the investigator's current knowledge - can't find causes that they don't already know.
Lack of support to help the investigator to ask the right "why" questions.
Results aren't repeatable - different people using 5 Whys come up with different causes for the same problem.
Tendency to isolate a single root cause, whereas each question could elicit many different root causes.

It’s very easy to lose focus on the exercise and start talking about solutions or ideas when only a couple of whys have been followed.
We went down a dead-end a few times where our 5th why ended up being something quite broad which we couldn’t do anything about.

We ended up going back up the chain of whys to see whether we could branch off a different way on any of the and it was actually reasonably easy to think of other whys the further up you went.

By going beyond surface reasons for things you actually end up with much more interesting conversations although I think it does also become a little bit more uncomfortable for people.

For example we ended up discussing what ‘minimum viable product’ actually means for us and a couple of the group had a much different opinion to the product owner. It would have been interesting if we’d been able to continue the discussion for longer.

For our particular topic we ended up discussing why the deadline we have was set when it was and couldn’t really come up with any reason for why it couldn’t be changed other than we’d been told it couldn’t.

It would have been more interesting to have the people external to the team who set the deadline so that we could understand if there was more to it.

's observations/learnings:

Douglas started off with a similar approach to the one we tried in our last attempt whereby he listed all the initial problems across the board and then worked through them.

One thing he did much better was ensuring that the 5 whys were covered for each problem before moving onto the next one. He described this as ‘move down, then across‘ and made the interesting observation that when you get to the real root cause (in theory the 5th why) there will be a pause and it will hurt.
I don’t remember noticing that in any of our 5 whys which means, Douglas suggests, that ‘you[/we] are not doing it right’. In terms of actually getting to the root cause he’s probably right but you can still learn some useful things even if you don’t dig down that far.

He also made the suggestions that we shouldn’t follow whys which we can immediately see are not going to go anywhere – we’d be better off going down one of the other nodes which might lead us to some useful learning.

I think we made the mistake of following some odes which we could tell were going to go nowhere the first time that we did the exercise and ended up reaching a 5th why which was so general that we couldn’t do anything with it.
On the other hand I think it probably takes a couple of goes at the 5 whys before you can say with certainty that following a why is going to go nowhere.

Another suggestion was to ensure that everyone linked with the problem being discussed is in the room, partly so that they don’t end up being made the scape goat in absentia.

In the two exercises we’ve run we only included the people on our immediate team and we did reach a point where it was difficult to work out what the answer to some of the whys should be because the person who could answer that question wasn’t in the room.
It does obviously make it more logistically difficult to organise the meeting, especially if you have people working in different countries.

Squirrel suggested then any actions that come out of the meeting should be completable in a week which helps to ensure that they’re realistic and proportionate to the problem.

If something goes wrong once then we don’t necessarily need to make massive changes to avoid it in future, it might be sufficient to just make some small changes and then observe if things have improved.

Travel of Software Developer