Better Software - May 2008 - (Page 41)

identity is lost (at least theoretically). Each idea then can be considered on its own merits, not on the relative status of the originator. The best ideas often are compilations of many ideas that have been thrown on the table. Another example of introvert/extrovert interaction is in estimating the time needed to implement a requirements story. Often an extrovert will start by announcing a value. Introverts can appear to acquiesce to that value, since they may be internally analyzing that value as well as others. The Planning Poker game allows introverts to have the means to ponder their responses. In Planning Poker, each estimator has a deck of cards with various values on them. To estimate a story, each person selects a card with his estimate and places it on the table face down. When everyone has chosen a card, the cards are flipped over. If the individual estimates are far apart, the estimators briefly discuss their differences. The estimators listen to the discussion to see if it alters their estimate. Each person then selects a card with his new estimate, and the cards are again flipped over. The process continues for a few rounds until there is either convergence on an estimate or an agreement that the effort required to implement the story is difficult to estimate or unknown. There are many other areas in which differences in styles may lead to problems in communication. For example, in many agile environments, story cards capture requirements. Each card includes a brief description of the requirement and an estimate of the effort to completely implement the requirement. Judgers might want preprinted templates for these story cards and a check that each card has been completely filled in. Perceivers may be happy with blank cards. The brief description can satisfy intuitive people, while sensing people may want more details recorded on the cards. The differences between the styles of judging types who prefer exactness and perceiving types who are comfortable with inexactness often emerge with different ways to track time estimates and progress on the completion of the story card implementation. The time needed to implement a requirement story is commonly estimated in story points. Story points represent the relative effort to complete a story rather than absolute time. To emphasize that story points do not correspond to exact times, the values they can take are usually limited to those in a Fibonacci series (i.e., 1, 2, 3, 5, 8, 13, …). The time to complete a story is estimated based on velocity (approximate number of story points that can be implemented per iteration). While perceiving types are comfortable with that inexactness, judging types may prefer actual day or hour values. During the planning for an iteration, the tasks required to implement each story are typically estimated in hours. Having two levels of estimates—story points for rough estimates and hours for detailed estimates on tasks—can help satisfy both personality types. Progress of story completion can be communicated in ways that suit both intuitive and sensing types. Agile teams commonly track progress of stories on a large board called the storyboard. The movement and location of the requirement story cards on the storyboard demonstrates the progress. An intuitive type can get a picture of progress with just a quick glance at the board. Sensing types typically prefer seeing a numerical tracking mechanism, such as a spreadsheet. Using the spreadsheet, they may create intricate measures of progress using graphs or formulas. Updating a storyboard and entering the details into a data-manipulation program usually can satisfy the communication needs of both types. Active Listening When you gather information that is presented orally, you can practice active listening. Active listening focuses on understanding what the other person is www.StickyMinds.com saying and giving feedback on how well you understand. Clear your mind and focus on what the speaker is saying, not on what you are going to say next. You are not trying to have a debate; you are trying to understand. If you follow what the other person is saying, periodically signal your understanding with either an oral response such as, “I understand” or a body language response such as nodding. Never pretend to follow if you really don’t comprehend what the speaker is saying. If you don’t understand, ask the speaker to expand or clarify. Simply make a request, such as “Can you give me an example?” when you feel the need for more clarity, or simply say, “I’m not following you.” In gathering requirements or performing root-cause analysis, you might employ the “Five Whys.” The Five Whys suggests you ask a speaker “Why?” five times in a row. For example, if he states, “I like the Dallas Cowboys,” you ask, “Why?” When he responds, “Because they’re a great football team,” you ask, “Why?” And repeat this process until he gets down to the real reason, “They have the best cheerleaders.” However, asking “Why?” can put the speaker in a defensive mode. What you want is for the speaker to reflect and expand on his thoughts. So when he says, “I like the Dallas Cowboys,” you could respond, “Tell me more.” Once you have the information gained from active listening, then you may want to ask the “Whys” to help you better understand the requirement and its purpose. An accompaniment to active listening is active writing. When taking notes, many people just write them on a pad of paper. The speaker does not get any feedback from you as to what you are capturing. You could be writing down the groceries that you want to buy at the store later. With active writing, you use a whiteboard or a flip chart to record your notes. Those who want to save paper can write on a whiteboard and later capture its contents with a digital camera. Having your writing visible to the speaker makes apparent your understanding of his words. It also helps control the pace of the discussion. If you MAY 2008 BETTER SOFTWARE 41 http://www.StickyMinds.com

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

Better Software - May 2008 Contents Mark Your Calendar Contributors eLightenment Technically Speaking Code Craft Test Connection Management Chronicles Cover Story: It's A Bug! The Chivalrous Team Member Let's Talk Agile Product Announcements 10 Things You Might Not Know About... The Last Word Ad Index

Better Software - May 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.