5 Whys in practice

 

For want of a nail, the shoe was lost,
For want of a shoe, the horse was lost,
For want of a horse, the rider was lost,
For want of a rider, the message was lost,
For want of a message, the battle was lost,
For want of a battle, the war was lost,
For want of a war, the kingdom was lost,
For want of a nail, the world was lost
‘The Want of a Nail”

– T. Rundgren
Warner Chappell N.A., Ltd., 1989

We all must have read the above poem or heard about the proverb “For want of a Nail the kingdom was lost” at some point in our lives. Both the poem and the proverb illustrate anecdotally how disasters happen seemingly due to innocuous causes. It is fascinating how something seemingly unimportant could have caused great failures. It is also a subject of lots of research across the world for the past hundred years or so. Research to find solutions which prevent these tiny errors that cause cascading yet seemingly minor effects in a complex system that eventually cause it to fail.

Many effective solutions, methodologies and frameworks have come out from that research. 5 Whys is one of those frameworks. The definition of 5 Whys is as simple as it sounds, it is just a process of asking the question why 5 times. In practice it is a lot subtler than that, as you will see further in this blog.

It is, simply put, an iterative way to discover root causes, hidden or otherwise.

A more formal definition can be found on Wikipedia.

5 Whys is an iterative interrogative technique used to explore the cause-and-effect relationships underlying a particular problem.[1] The primary goal of the technique is to determine the root cause of a defect or problem by repeating the question “Why?” Each answer forms the basis of the next question.

This blog goes into detail about how to effectively use 5 Whys in practice.

This technique was developed in the 1930s by Sakichi Toyoda one of the early pioneers of the Japanese industrial revolution.  He was an inventor, industrialist and was the founder of Toyota which uses this technique to solve problems to this day. Infact the 5 Whys technique was so effective that another Toyota pioneer Taiichi Ohno in his book Toyota Production System: Beyond Large-Scale Production,  says that it is “the basis of Toyota’s scientific approach”

The picture below is an illustration of the 5 why’s in action.

3768260_f1024

That is all there is to it. The key is in asking why something happened till we find a reasonable root cause, which itself is usually caused by something beyond our control

Now what if we had not asked why enough times in the previous case. We probably would have done one of the following.

  • ‘Un-tripped’ the machine from overload: The machine would have run fine till the next time it tripped because of overload. In the long term we would have damaged the machine by over using it in spite of it being overloaded.
  • Change the oil pump drive: Doing this would have solved the problem for some time until the new oil pump drive ‘wears out’

Here in both the cases we took some action which would solve the problem only temporarily and the problem comes back sometimes in a more severe form or accompanied by one or more new problems. This could have been avoided if we would have spent time analysing why the problem itself is happening in the first place instead of directly jumping to fix the visible symptom.

We need to temporarily suspend our thinking of  “How to fix the problem ?” and start thinking “Why is the problem occurring ?” and when we get an answer we start over again by suspending the “How to fix it” thought to think about “Why is it occurring”. Then repeat until we find the real root cause of the problem.

Before I conclude, here are a few points that one needs to keep in mind while using the 5 Why technique.

  • The number 5 is not set in stone:

While the technique recommends asking why 5 times it may so happen, that you found your root cause before the fifth why was asked. It is also possible that it took more than 5 whys for your root cause to be found. This is subjective and depends on your core problem.

You are the best judge of what your reasonable root cause is. A rule of thumb is whether you can do anything about your root cause. For example, lets assume that you have down time because of spare-parts not being available in your warehouse because of a labour strike in the country where the factory which produces your spare parts is located. You probably cant do anything about a strike in a foreign country. Then an exercise on finding the whys behind the strike happening in that country would probably be futile. Then your reasonable root cause is the lack of reserve spare parts. Also if you find that a root cause is something you can fix, there is no harm in asking a 6th or a 7th why till you reach one that is beyond your control.

Although one thing to remember is if too many of your 5 Whys sessions are ending in 1 or 2 whys or you are ending up with root causes that are way out of your control, then you may not be doing 5 Whys correctly.

  • The root cause is not the only thing that needs fixing:

If A is caused by B which is caused by C which in turn is caused by D and you find that D is your reasonable root cause, then the first obvious step is to fix D. Also in many cases it might be prudent to make sure that If D happens, then that shouldn’t lead to C happening which in turn should not cause B and B shouldn’t cause A.

In summary, while the purpose of the 5 Whys exercise is to establish causality, your resultant action should be counter measures that not only prevent the root cause but also break as many links as possible in the chain of causality from the root cause to your problem. Many people fix the root cause and neglect breaking the chains of causality.

  • Multiple Applications:

Because of its simplicity, 5 Whys can be used in a lot of places. It can be used for personal improvement,  sprint retrospectives and fact finding enquiries both corporate or otherwise. The only thing to remember is to keep finding causes till we find the root cause.

  • Not only for retrospecting failures:

Although it is predominantly used for finding root causes to problems or failures, it need not be the only place we use it. It can be used even to study successes. A 5 Whys inquiry is about finding a chain of causes and arriving at a root cause, no one says that the root cause should only lead to a failure.

It can be used to find reasons behind an unexpected success so that the ingredients of that success can be replicated. It can also be used – for example – to compare,  contrast and find out the real hidden differences between two systems that seem to give different outputs when inputs and preconditions seem to be same.

 

References

  • The picture above illustrating 5 Whys is taken from this awesome blog post on the same topic.
  • You can read more about the proverb ‘For want of a nail’ here.
  • The Wikipedia definition of 5 Whys is taken from… well wikipedia.

 

Agile Faux-Pas: Lack of a Product Owner

Agile Software development has taken the world by storm and its adoption is at unprecedented levels these days. Almost everyone these days talks about Agile software development and agility as a discipline. So you would expect that everyone learns and practices Agile Software development the right way at the right pace. Sadly that is not the case. There are countless examples where Agile Software development is not practised correctly.

That is the point of this new series of blogs, the Agile Faux-Pas series. While none of these will kill your software development (or may do in extreme cases), they definitely make you less Agile and often defeat the purpose of going Agile.

One very common ‘faux-pas’ is the lack of a proper Product Owner.

It usually manifests itself in the following ways.

  • Many teams and companies assume they don’t need a Product Owner(PO) or they have someone take over this role part time.
  • Others go the waterfall way and use a requirements document as a product owner.
  • Still some others improvise and have neither a requirements document or a PO. They just get the senior most team member or someone from management to act as a PO when needed.

This is a clear departure from Agile Principles. One of the main reasons for this is a wrong understanding of the PO’s purpose. Or even a total lack of understanding. Let me elaborate on that a bit and also throw light on how the PO is essential to the success of Scrum. For that let us first see what are his roles and responsibilities (in no particular order) and why they are important.

  • Demos and Constant Feedback: For the dev team’s point of view, the PO is the customer. In every Sprint review, the team gives the PO a demo of an incremental version of the product that has more value (features, bug fixes, enhancements) than the last one. This demo gives the PO an opportunity to look at the product and answer queries about whether the stories taken up for that sprint were done right. The PO should already have talked to the real customer or their representatives to get detailed product specs and the priority of each spec. Armed with that info, the PO should be able to answer any product specification related question the developer might ask. Also, the PO should be available to answer requirements related queries at any time during the sprint. Overall this provides much better feedback than a document, even a constantly updated one. The point to note is that while the PO maintains requirements in the Sprint and Product backlogs, they are not alternatives for him being personally available to look at the product, give feedback and clarify queries. It is this face to face communication that allows the dev team to constantly build the right features in the right order. Without that, there would be a great deal of wasted effort and rework.
  • Backlogs and their grooming:
    • Product and Sprint Backlogs are the most important artefacts maintained by the PO for each product under development. The Product backlog contains stories that need to be go into the product while the Sprint backlog has stories that need to be completed in a particular Sprint. In both backlogs, items are arranged according to Priority and this Priority is sacrosanct. At all times only the highest priority items should be taken for processing. These backlogs and their priorities are the PO’s responsibility and they are arrived at by constantly talking to the customer or their representatives.
    • Also before a sprint begins, the PO along with the scrum master works on making user stories for that Sprint “Sprint Ready” which essentially means the following.
      • Latest requirements: Requirements can and will change while the product is being built. The PO makes sure that before each sprint begins, each backlog item contains the latest specs.
      • Clear and well defined stories: The PO makes sure that there is no lack of clarity about what each story means. This can be achieved by mentioning the specs clearly with the stories in the backlog and also by being personally available to resolve queries face to face.
      • Acceptance criteria: The PO defines what constitutes successful delivery of each story before the sprint begins, allowing the team to demonstrate success (or not) for each feature developed.
  • Business inputs for the product: For any product, business inputs are key development drivers. As I mentioned earlier, the PO is a virtual customer for the dev team (including QA). The PO has all data about how the product is supposed to run in the field and is the single point of contact for the dev team to be able to get these insights. And since the PO has all the data, he usually is the best judge of the correct expected behaviour of the product in the field. The availability or lack of these insights could make or break a product.

As you have seen, the PO overall brings clarity to the developers, a clarity that probably cannot be matched by other substitutes. It is this very clarity and constant availability for face to face clarifications that make the PO’s an indispensable role for a truly Agile team.

There however are many reasons why teams are not able to have a proper Product Owner, I will look into some of those reasons in another blog and hopefully be able to provide solutions for that. I will also be looking into some best practices and anti patterns with respect to a PO in that blog.

Also, please share your feedback in the comments. I would love to hear your opinions and questions. Do subscribe if you feel that this blog is useful for you.

References

  • Implications of your PO being missing in action here.
  • What happens when you don’t have a PO at all. Read a thoughtful perspective here.
  • And here, why you need a dedicated product owner.

 

Tackling hurdles to Agililty

Agile methodologies, in some or the other form, have been around for close to three decades now. They have been immensely popular for software development across the world for a better part of a decade now. But there still are people who do not want this change. There still are pockets of resistance towards Agile and Agile Principles. There seem to be so many reasons why somehow Agile does not seem to be ‘right’ for them. Some are valid, others not so much.

Over the years, I have seen a lot of misconceptions people had about agile people which prevented them from transitioning to agile. In this post I wanted to dispel some of them. This may not be an exhaustive list but here are some of the most prominent ones. I will probably write a sequel to this post as and when I am able to find more ‘hurdles’ to Agile and how to tackle them.

So without much ado let us see how to tackle the first few ‘hurdles’.

‘I don’t want to restrict a well performing team with unnecessary ‘process’.’

No one likes unnecessary and heavyweight ceremonious process that exist only because someone mandated it. And none of the Agile processes are exceptions. Agile only expects a few specific conditions to be met.

  • Each iteration should finish with added value for the customer.
  • Software gets continuously validated.
  • Stakeholders should be actively involved.
  • Self organising teams.
  • Continuous improvement.

Agile doesn’t mandate how you achieve this, nor advocate a standard. If you are able to achieve these then you are agile. So there is no extensive and unnecessary ‘process’, there is no bureaucracy and no process that no one understands. Teams only work on those ‘process-things’ that satisfy the above 5 conditions.  Everything else is extra.

‘A daily status meeting: Oh! Its too stressful’

If you or your company see it as a status meeting, then you are doing Agile wrong. The point of this meeting is that everyone in your team knows what everyone else is doing, with the specific intent of making sure that the goals for that iteration (Sprint if you follow Scrum) is complete. It can serve as a status meeting for management, but if that is all that is happening then it is wrong. The point of a daily short meet is to ensure that everyone in the team knows the progress, can ask help or be of help if possible and to make course corrections if it seems they wont meet the goals for that iterations. And most importantly convey it as early as possible if it seems that the goals for the sprint will be missed.

All Agile methodologies accept failures so long as we learn from them. In fact the Agile way is to fail fast, fail early when too much effort, time and money hasn’t yet been committed to the project. So if you look at it as a status meeting, then you are doing it wrong. For a developer it is a forum where developers tell what they did, what they plan to do and most important try to predict impediments so that the scrum master can work on clearing them as soon as possible.  Also management need not be present in that meeting. If they are, then they need to be only listeners and provide input when asked for. The scrum master can brief the management in another meeting.

‘Agile gives license to throw away all discipline’

This misconception hurts both ways. It scares away people who want a disciplined execution of the project and it attracts those who think discipline is a chore.

The truth is that agile expects a lot of discipline from developers. It just doesn’t expect the processes and ceremonies to be imposed by the management above. On the contrary, it expects the team to be adults and evolve a process that works for them and also helps them meet all agile and project goals. Discipline is not stressed but it is implicit, and without discipline you can’t hope to succeed. The only difference is that the team follows rules and processes that make sense to them and not some company diktat that they comply with without understanding its purpose.

‘Agile is for short-term projects’

It is easy to see why there could be a misconception like this. The dev team usually focuses only on the goals for that particular iteration. So an outside observer might see a very short-termist outlook. And hence the view that this probably wont work for long term projects. And unfortunately many teams do work in this way, hacking up the code just so that the demo at the end of the iteration can be done. If a team works that way, then they are not agile.

Agile does say that you concentrate on just enough architecture and design to make sure that your sprint goals get met. But nothing stops you from having architectural issues and bugs in your sprint backlog. Usually if your architecture and design are not up to the mark, there definitely will be bugs. Nothing stops you from revisiting design once a feature is done. In fact you cant be truly agile without being constant, ongoing, small doses of refactoring. When the product owner is pushing features to the sprint backlog, the team also should be able to push architecture and bugs to the sprint backlog and then prune the backlog to make sure that only those many items that can be finished in the iteration remain. This way you can be truly agile and work on a long term project.

There are many more hurdles to Agile, that I will discuss in subsequent posts. For now I am leaving you with these. Do share your feedback in the comments. And don’t forget to subscribe to BeingNimble to get the latest posts right in your inbox.

References

  • A bit of an explanation about the conditions for agility here.