Better Software - May 2008 - (Page 43)

"Some people prefer passive communications so they have time to absorb and reflect on the information. Others favor passive communication because they work best in silent contemplation." day, c) by the time he leaves work, or d) at least one second before midnight? When someone says “I’ll try,” what are your expectations of how hard? Will he try a) until death takes over, b) until he is exhausted, or c) until his fingers are cramped? What are your expectations of how long? Will he keep it up a) until the task is complete, b) until something more pressing comes along, or c) until he gets bored? With all of these different meanings, how do you avoid misunderstanding “I’ll try to have that done for you tomorrow?” Ask about, and then agree on, the interpretation of these communication tokens. If the meanings are too embedded in people’s minds and not easily subject to change (for example, the connotation of “done”), then create some new shared tokens with different meanings (such as “code done,” “tests done,” and “customer done”; or “done,” “done-done,” and “done-done-done”). ment is not done for documentation’s sake. It’s using the document to enhance communication. If someone has trouble receiving oral communication, write the information down on a whiteboard and take a picture. Sensing/judging people often need more detailed information that follows a particular format. For example, a written use case that details a requirement story can help satisfy these needs. In communicating, keep it simple. Developers often like to draw diagrams to explain a design. A diagram can illuminate how code modules relate to each other more easily than text. When many symbols are added, simplicity can be lost. Some people fall in love with all the potential symbols contained in a particular notation, such as the Unified Modeling Language. I call them the symbologists. Instead of using a small set of symbols and adding clarifying words, the symbologists want to use all of the correct symbols. The result is a diagram that they understand. Other people may need to decipher it by constantly referring to symbol descriptions. Some people prefer passive communications so they have time to absorb and reflect on the information. Others favor passive communication because they work best in silent contemplation. Their productivity decreases when they have to work in an environment filled with sound. Many agile teams work in bullpens, which often have a noisy atmosphere. Overhearing conversations, which happens in many XP environments, can be counterproductive for www.StickyMinds.com some people. If your team has individual cubicles, as well as a team space, those who work better in silence could have “In/Out” labels on their doors. If they are in their cubicles, they may put up the “In” label if they are available for interruption and put up the “Out” label when they are performing work that requires concentration. Summary Communication Modes To ensure good communication, communicate about your communication. Take the time to understand each other’s communication style. Talk about how you like to receive information, how much exactness and detail you require to be comfortable, and the meanings of the words you use. When gathering information and having discussions, practice active listening and active writing. Use the Satir interaction model to help you analyze why misunderstandings occur. Be proactive about communications to avoid a “failure to communicate.” {end} Active communication involves talking—usually face-to-face. Passive communication employs documents. Active communication involves two or more people working on the same task, such as discussing at a whiteboard or programming as a pair. Active communication is usually oral but also includes body movements and hand gestures. As much as we like to communicate orally, it is not necessarily the most effective means of communication for everyone. Some people read more effectively than they listen. For them, creating a docu- Sticky Notes For more on the following topics go to www.StickyMinds.com/bettersoftware. n n n Communication strategies MBTI type test Satir Change Process Model MAY 2008 BETTER SOFTWARE 43 http://www.StickyMinds.com/bettersoftware 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.