 |
Home > Detail: Questions You Should Ask
| A StickyMinds.com Original |
|  | |
Questions You Should Ask
By Michele Sliger
   
Summary: It's a technique children and teenagers have mastered: asking "why" until they get to an acceptable response (or until we're too tired to continue answering). In this week's column, find out how Michele Sliger uses a similar approach designed by Six Sigma to drill down into the underlying cause of any problem within software projects. She then continues the inquisition with a series of other questions in order to find out how these problems affect business value and technology. Read on to learn what these questions are and how you can start using them to find out why things aren't going as planned. | | |
|
|
 |
A long time ago I saw a comedy routine by Bill Cosby that really resonated. He described a scene where he was frustrated by a young woman's behavior in a public place and had decided to confront her. Her response to everything he said was (picture a hand on the hip and some serious attitude) "So?" The conversation went something like this:
Bill Cosby: I saw what you did.
Young Woman: So?
BC: So you need to stop that. You're upsetting those around you.
YW: So??
BC: So it's rude, and it's not fair to everyone else.
YW: So???
BC: So that's not how civilized people are supposed to behave!
YW: So????
BC: So this is how society works! You have to have manners! People can't live together without rules of decorum!
YW: SOOOOOO???
Cosby was increasingly funny as he described his indignation at how this one little word, uttered over and over again, drove him to finally walk away.
Fast-forward to current events where I find myself doing retrospectives with teams who are learning about better ways to develop software. Many are familiar with the Five Whys, one of the analytical tools of the Six Sigma approach to process improvement. This technique, often used in retrospectives or other problem-solving meetings, is designed to get to the true root of the problem. By asking "why" five times, it enables the team to drill down into the underlying cause of the problem, and then solve it. Five Whys conversations play out like this:
Team Member: We aren't able to ship the widgets.
Facilitator: Why?
TM: Because the boxes aren't the right size.
F: Why?
TM: The boxes were just a standard stock order, without consideration for the odd size and fragility of the widget.
F: Why?
TM: The warehouse manager says that everything is considered standard stock unless there is an XJ-912 form filed by the floor manager. Our floor manager did not submit the form.
F: Why?
TM: Because he didn't know about it.
F: Why?
TM: He's new, and training on warehouse procedure is not part of the floor manager’s training program.
In this example we learn about the real problem behind the inability to ship widgets and can take steps to ensure that the likelihood of this type of incident happening again is lessened.
Now imagine combining both "why" and "so" questions in a problem-solving discussion (without the hand-on-hip attitude):
Team Member: We can't design our new phone product this way.
Facilitator: Why?
TM: Because our customers would lose all their existing voicemail messages when we made the switch.
F: So?
TM: So that would be bad, right? We can't ask them to say goodbye to all their saved voicemail ... can we?
F: Why not?
TM: Yeah, why not? If the customer won't miss those saved voicemails, then we can completely redesign this phone system to take advantage of the new platform!
The "why" questions enable us to discover the points of failure, while the "so" questions enable us to learn more about the business value linked to the issue. Would the customers be upset at losing voicemail messages? First, we must decide who could best answer this question about the value this product feature provides to the customer. In most organizations it is the product owner, who can speak with the voice of the customer and provide the design team with the important insight they need to help spark innovation in design and problem solving. This product owner is a customer-facing role and typically works in marketing. Including the product owner in the problem solving ensures that a more well-rounded solution will be developed, one that satisfies proper design considerations as well as providing a useful and valuable asset to the customer.
Challenging teams with "so" not only forces them to justify their logic, it also helps them to begin thinking outside the box. What might the widget conversation have looked like if we'd challenged the team to be creative in that situation?
Team Member" We aren't able to ship the widgets.
Facilitator: Why?
TM: Because the boxes aren't the right size.
F: So?
TM: So the widgets don't all fit in the standard-size box, and they need special packaging so they don't get broken.
F: Why?
TM: Because they're fragile, and we don't have any support packaging designed for them yet.
F: So?
TM: So, what are you asking? Do you expect us to ship them anyway, without the special packaging?
F: Why not?
TM: Well, maybe we could ... if we used enough bubble wrap. We might be able to ship the widgets in multiple boxes, using extra bubble wrap and Styrofoam peanuts. Let me see if that will work.
Using "why" and "so" seems inevitably to lead us to "why not"--and this is how teams transition to being creative and innovative. In software development, the "why not" may be aimed at technologies as well as business value. Be sure to include your product owners in these discussions so that they, too, can ask and answer the "so" and "why not" questions. In today's highly competitive marketplace, asking "why" is only the beginning!
About the Author
Michele Sliger has extensive experience in agile software development, having worked in both XP and Scrum teams before becoming a consultant. As a self-described "bridge builder," her passion lies in helping those in traditional software development environments cross the bridge to agility. Along with co-author Stacia Broderick, their forthcoming book "The Software Project Manager's Bridge to Agility" will focus on that topic, helping PMI-trained project managers make the transition. Michele is a Certified Scrum Trainer (CST) and a certified Project Management Professional (PMP). If you have a question, or would like help with your agile adoption, Michele can be reached at michele@sligerconsulting.com.
Back to Top
StickyMinds.com Weekly Column From 3/3/2008
|
