Better Software - January 2009 - (Page 18) Management Chronicles Questions You Should Ask by Michele Sliger 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 finally to 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. 18 BETTER SOFTWARE 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 XJ912 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): www.StickyMinds.com 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 it needs to help spark innovation in de- JANUARY/FEBRUARY 2009 ISTOCKPHOTO http://www.StickyMinds.com
For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.