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?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.
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.
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:
- (2 minutes) Make a list of the most recent bugs you've uncovered. I've found that the last 10 is usually enough-- if not too much. You can put these on a white board, index cards or a wiki page-- all will work.
- (2 minutes) Prioritize them based on the ones you want to talk about. Which caused the most embarrassment or cost? You usually only have energy to talk about 5 or 6 of them.
- (15 minutes) For each bug, ask "Why did this happen?" Then, probe deeper until you can't get much further. Write the answers down where everyone can see.
- (5 minutes) When you're done with all the bugs (or out of time), circle common root causes.
- (10 minutes) Brainstorm ways to mitigate or eliminate the root causes. Come of with one or two SMART goals for the team.
- we didn't pair on hard features
- we didn't ask for clarifications on the requirements
- one engineer didn't understand the intent behind the code
- nobody looked at the app on Internet Explorer 6