The power of “Why” in software development

History

Sakichi Toyoda (also known as the “King of Japanese Inventors" ) created the technique and it was the first time used by the Toyota Motor Corporation to find the root cause of particular problems. The technique's purpose hasn’t changed since then, but now it is used in many more domains — business, negotiations and interviews as more examples.

Deep Dive

The whole idea of this technique is to ask “Why?” up to 5 times, to get to the root cause. It is essential to make a clear distinction between the symptoms of the problem and the cause-effect relation and the real problem. You really need to pay attention if you want to get to a result. It’s not meant to be used, only because it might sound cool. It won’t work for sure and you’ll lose your time if you don’t pay attention. Sometimes, asking why over and over again might sound boring or even stupid, but this is a way to get to the cause of the problem and you can’t skip any step.

Examples

1. Let’s say we are in a retro am try to use this, and it will be a discussion between the mediator (scrum master, agile coach, facilitator, mediator, whatever the role name will be) and the team: Why the Sprint wasn’t finished? * We committed to too much and we didn’t know how to do the stories Why do you say now that you didn’t know how to implement them? * We didn’t know, because in the refinements we never looked over the code how to do the implementation, and bugs and stories are inserted in the sprint after the planning having a higher priority without getting anything out of the sprint. Why you don’t look over the code and why do things get added after the sprint starts? * We don’t look over the code because we never find the time or the PO doesn’t want to stay in a call that is technical dive and things get added because they have a bigger priority we guess. Why do you think you don’t find time, and why do you think it is wrong to add new things if they have a bigger prio? * We focus on the wrong things and try to deliver more, but don’t really understand the whole codebase. It is not wrong to add things with higher prio, but we committed to a certain number of story points and if more things are added, we can’t deliver what we committed plus the new things, we switch contexts more than we anticipated and committed to and we don’t finish the sprint. Why do you think you switched contexts so much and didn’t get things out of the sprint with the same estimation? * Because no one is there to enforce the DoR that we agreed upon.

Small remarks:

(a) If you don’t know how to actually implement something on the current code base, that’s the root cause for sure, since even if you created something similar before, it’s not like you can bring your “module”, and just “plug and play”. (b)would be that if the PO doesn’t want to stay in the call due to a technical deep dive, there are 2 possibilities: give time to be team, at least 30–40% of the sprint to deep dive over code, and accept the fact that the things delivered might go down by a lot until the team will understand how and why the code works, either he should stay in the call as shadowing and be ready for business questions that might appear, or even ask questions himself. (c) If none of the upper solutions are taken you will end up with a guestimation without any real value (if it is actually used like an estimation).

2. Let’s say we have a discussion about a specific user story: Why did the customer complain about feature X? * Because we introduced a bug with it, and on production it is not working Why did the bug appear and wasn’t caught on stagging/testing? * Because we didn’t cover that scenario and we have totally different data on the testing environment. Why didn’t we cover that scenario and why do we have totally different data? * Because no one from the business side gave us any / that test case, we don’t have testers and we have different data due to GDPR. Why haven’t you asked for more testing scenarios? * We have but we don’t get any, since they are doing their own kind of testing. Why are they doing their own kind of testing not testing together all the features? * Because each stakeholder is responsible for a specific part of the app and does not know the others, we can’t test all the features, because this kind of regression would take 1 sprint for the entire team due to how big the app is. We need testers to do that.

3. Let’s imagine an interview, in which the guy who wants to job starts asking the interviewer some questions about the project: Why is the project so important to you? * Because the competition launched their own project with the same functionalities. Why do it now, wouldn’t it make more sense to wait until you see how they are doing and if it actually makes sense to invest in something like this? * No, because we already have clients that leave us and go to them Why haven’t you started earlier with the project if you already are losing customers? * We have but the project didn’t go so well. Why do you think this time will be better? * We will take a closer look at what it is developed and we think you are the perfect match for us. Why don’t you go with a cheaper guy? * We have only one more shot and we can’t lose any more time on attempts. We need an autonomous expert.

Note: I’ve added in italics, some key things that the mediator should note down and they might be root problems and symptoms for other root problems that might be investigated.

What you might find out

People (usually at least) don’t fail. The processes are wrong or misunderstood. Think about our examples, in the first one, the is not a clear vision for everyone about what a sprint should be, why DoR exists, why sprint backlog shouldn’t change, and so on. In the second example, the team is just struggling to deliver the best they can, but there are no QA processes, for the entire product, and the stakeholders behave like testers without really caring about the entire product.

The most common causes that you’ll find are lack of communication, not clear requirements, misunderstood or not existing processes.

Random good to know about this technique

It doesn't need 5 whys all the time, but usually using 5 you’ll get more information than expected, information that you might want to investigate further in another meeting. One good example would be the feeling of never having time, from example 1.

Get everyone involved. It is not ok a conversation only between 1–3 people. Everyone in the room needs to get involved since everyone has his own mindset.

It is pretty normal to get resistance, as a mediator, because at first at least, people might feel threatened and uncomfortable.

False positive. You might think that you got to the root cause, but you got only a symptom. You need to push further.

Accept mistakes. No one can learn without doing them. If the same mistake is made multiple times, you need to take it into investigation. Something more might be in there and have another root cause. No one starts his day with only one idea in mind: Let’s make mistakes!

Always do something with the root causes you found and be transparent about it. If you just identify the root causes and you don’t do anything with them, it is totally useless, and believe me, the people from that room will smell your blood.

(Article copied from https://medium.com/@cosmin-vladutu/the-power-of-why-in-software-development-155e5befc901)