Better Software - December 2008 - (Page 38)

stories or experiences. These are a few questions that were useful to learn more and often led to new or related stories: • What else would you like to tell us? • Is there anything else you’d like to share with us? • What else should we know? To find out what really happens on projects, avoid asking questions that require the interviewee to judge his peers. Avoid questions that would place blame on individuals or teams. Instead, focus on behaviors and deliverables rather than the individuals. cident was different from others. We tried to trigger objective and subjective comparisons. Better or worse?) • Is this recent? (We tried to get the interviewee to give us a place in time to anchor the story.) • Can you give me an example? (When an interviewee used a generalization we tried to elicit a specific example that demonstrated the point. Occasionally an interviewee offered a generalization—“We always do this”—but has trouble identifying a specific example.) Making discoveries Interviewees occasionally need guidance to help them advance their narratives. Developers and testers can get pretty absorbed in describing a single activity, losing sight of where it fits into their stories. Some questions helped interviewees become better story tellers. They learned to question themselves as they spoke. As interviewers, we needed to prime the pump a few times, but once the juices were flowing, a rich narrative often followed. Some questions that helped to move the conversation along include: • What happens next? (Sometimes the interviewee just stops the narrative; prodding about the next step helps it advance.) • How was it previously? (We encouraged the interviewee to elaborate on why this particular in- clariFYing Questions Filling gaps with an occasional clarifying question can help build a better understanding of objects, actions, roles, responsibilities, and the relationships between them. Mind mapping the interview can really help find holes in the story. Clarifying questions can also remove ambiguity. Some clarifying questions we used are: • Which attribute is associated with which object? • Which object was input? • Which was output? • What do you mean by ? • When you say , do you mean all? Some? Many? Few? • Repeat a word or phrase with a question mark at the end. • Can you give me an example of ? We used these tactics when the interviewee pivoted to a new topic or prematurely concluded the story: • Make a statement; wait for response. (Something like: The requirement document is always reviewed before development starts [PAUSE].) • Make a statement; then ask, do you think it’s like that? • Tell a story to trigger a response. (We interviewers know many relevant anecdotes. Each can be used to elicit related insights. These mini-experience reports only take a couple of minutes to share and they ask the question “Does something similar happen here?”) When we are concerned that the interviewee is overgeneralizing, a clarifying question can help us understand scope. For example: • Are there different types of ? (Is this an isolated example or are there other related objects or actions or roles?) • Could you give us an example? (This question helps ground the narrative to a specific example— essentially we are saying “show me.”) • Let me tell a story to explain (Take a small part and make a story around it because that is a story in and of itself.) • Who should we talk with to find out more about ? (Can someone else help complete the narrative?) Story Telling In Qualitative Research and Evaluation Methods by Michael Quinn Patton, many different elicitation and interview styles are discussed. Patton’s research indicates that story telling can help add depth, detail, and meaning to qualitative analysis. Some organizations referenced use story telling to interchange knowledge. Story telling can help in sharing key process information and illustrate to future projects what worked and what failed. Stories that are real, recent, and relevant provide compelling evidence of what current processes are and may become credible evidence supporting process improvement initiatives. Lee Copeland’s StickyMinds.com article “Telling Our Story” is another useful reference. Not all are great story tellers even though they may have important stories to tell. The challenge is eliciting and elaborating these stories so that their retelling spreads the lessons learned across the organization and into different product or project areas. 38 BETTER SOFTWARE DECEMBER 2008 recaPPing and reFlecting It is vital that we understand key concepts from the interviews, so we ask interviewees to validate our interpretation by restating the story from our notes. This recap often leads to additional clarification. We sometimes retell the story in a chronological order to make sure all events are understood in sequence. We ask interviewees to identify missing activities or gaps in time: • Could I review this to make sure I understand? (Repeat the story back to the interviewee to make www.StickyMinds.com http://www.StickyMinds.com http://www.StickyMinds.com

Table of Contents Feed for the Digital Edition of Better Software - December 2008

Better Software - December 2008 Contents Mark Your Calendar Contributors eLightenment Technically Speaking Code Craft Test Connection Management Chronicles What's a Manager to Do? Six Thinking Hats for Testers The Key to Good Interviewing 2008 Salary Survey Product Announcements 10 Things You Might Not Know About … The Last Word Ad Index

Better Software - December 2008

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.