5 Whys is a great way to get at the root of quality problems. On my last three projects, when I felt like code quality was dropping, I ran a “5 Whys” session. I have found it adds variety, solves a very specific problem, and plugs right in as an alternative to an agile reflection.
It’s not in every agile software team’s bag of tricks. Asking around our fairy savvy office, I discovered it’s far from universal. In the “State of Agile” report from Version One, which includes survey results from 2500 software developers, it wasn’t mentioned. Since I haven’t seen it show up that much in other agile writings, I thought I’d share my experiences here.
What is “5 Whys”? I picked up “5 Whys” from the lean software movement, which sprang from Toyota manufacturing. You can read about its history on wikipedia, but it’s pretty simple: at the end of the assembly line, when a widget comes out with a problem, you stop the line and ask “Why?” Whatever the reason, you ask the “Why?” again. Repeat at least 5 times. The goal is to discover the “root cause” of the defect, and fix the root cause, not just some symptom. Wikipedia has a good example around car repair. Here’s a software example:
1. Why did Sheryl say the sign-up flow was broken?
A: Because she was trying to sign up a second time. Duh.
2. Yeah, but why did the flow break if the user is already signed up?
A: It’s a bug. We didn’t have a test case for that.
3. Why didn’t we have a test case for it?
A: I just didn’t think of it.
4. Why didn’t you think about it?
A: The story seemed easy– I guess I didn’t think it through.
5. Why do you think you didn’t think it through?”
A: I guess I was working alone and was in a hurry.
…
Obviously you don’t have ask “Why?” exactly five times, but that does seem to be a pretty good number. The point is you start articulating the behaviors and procedures that cause the problems.
Taking It for a Spin. I’ve come up with exercise for agile software teams. Like I mentioned, when quality drops below your comfort level, give it a try:
Some of the root causes we’ve gotten to recently:
Just like in agile reflections, the changes made coming out of these meetings stick with the team. During one session, the developers decided that there were just too many mistakes that someone else would have easily caught– so they always needed two sets of eyes on every checkin. I’d advocated this before, but it was never applied consistently. To my surprise though, after the reflection, everyone was disciplined about this policy– and our quality was much better.