Skip to main content

Author: Gil Broza

8 Conversation Tips for Checking Your Understanding

Written by Gil Broza on . Posted in Articles.

Think back to a time when you observed two colleagues in an important conversation. Did it appear like a true exchange of information and ideas, or was one person:

  • Interrupting the other?
  • Putting words in the other’s mouth?
  • Raising her voice if the other did not seem to understand something?
  • Checking her mobile phone?
  • Giving her planned answer, regardless of what her colleague said?

The two sides probably didn’t gain anything useful from this exchange. In fact, they likely hurt their relationship somewhat, because the impatient listener was not respecting the interaction. Her conversation partner might have felt frustrated, ignored, looked down upon, or annoyed.
The active listening technique is much more than basic manners (e.g., don’t interrupt, don’t raise your voice). With active listening, you demonstrate that you’re listening and verify what you think you heard. Use it to improve your conversations’ results, to enhance your ability to influence and negotiate, and to sustain long-term relationships.

In active listening, you focus attention on what the other person says, with both his words and his body language. The central tactic is that of feeding back the message. It comes in three degrees: repeating (using the exact words you heard), paraphrasing (using similar words), and reflecting (using your own words).

Suppose you are having a conversation with Vijay, a team member:

Vijay: “Our defect count has been trending up this year. I don’t think it’s a matter of testing better and discovering more defects; we’re simply introducing more than we’re fixing.”

You (repeating): “So you’re saying we’re introducing more defects than we’re fixing, and that makes our defect count trend up?”

You just demonstrated that you’ve paid attention to Vijay’s words, which invites him to contribute further:

Vijay: “I think that’s the reason. The code we develop each iteration is not perfect, but we’re so busy building new features, we don’t dedicate enough time to fixing defects from that iteration or previous ones.”

You might respond to Vijay’s concern at this point. If his argument isn’t clear to you, or you have doubts about its validity, you could feed it back to him:

You (paraphrasing): “Let me see if I understand. We’re paying so much attention to coding new features that we don’t have time to clean them up, which makes the defect count go up. Right?”

Or:

You (reflecting): “Hmm. So you’re saying that new development is out of balance with defect fixing, which is why our quality is going down?”

Repeating retains the most of Vijay’s original intent, while paraphrasing retains less, and reflecting may even lose it entirely. When you reflect a message, you inject your beliefs into it. In this case, you’ve posited that defects trending up means quality going down, and that maintaining quality requires a balance between new development and fixing. This might be quite different from Vijay’s intent, which is why it’s so important to voice your interpretation of his words before responding to them.

Active listening is suitable for many kinds of conversations. It is particularly powerful in emotionally charged situations, where it is extremely important that the other party know you are engaged, that she feel heard, and that you know what she is saying and thus are not responding to the wrong message.

To get the best results from active listening:  

Minimize distractions. Your phone, email, and open door are obvious invitations to interruption. If something repeatedly tugs at you (such as your mobile phone vibrating), turn it off and say that you’re doing that. If it’s the other person’s, ask him respectfully to turn down the notification.

Face the speaker. Eye contact (not staring) is best. If it makes you uncomfortable, at least have your body roughly angled toward the other person. Move away from your computer or other electronics. While looking downward or averting your eyes is hardly an optimal response, at least she will feel less slighted than if you were still typing on your computer.

Stay focused on the conversation. If your mind keeps trying to pull you toward other mental pursuits, don’t just check out mentally. Either force yourself to focus or gracefully back out of the conversation. You could say, “I’d like to give this matter the attention it deserves, and I’m having trouble concentrating right now. Can we resume this conversation in ?”

Supplement your words with simple acknowledgments Nod for acceptance. Smile. Talk with your hands. Say “Uh-huh,” “OK,” “Hmm…,” or “Right.” Use “Interesting!” and “Really?” sparingly, since they have the potential to sound fake.

Use preambles. Before you feed back the message, say something that signals the feedback. “What I’m hearing is…,” “So are you saying that…,” “Sounds like you’re referring to…,” “If I understand you correctly….”

If you don’t understand what they said, slowly repeat it word for word. That will help you comprehend what the other person said or it will encourage him to rephrase.

Don’t prepare your counterargument before the other person has finished talking (even if she says more than you think is needed). Otherwise, you’re clearly showing that what she says isn’t all that important to you.

Offer the occasional recap. It can be quite useful to summarize your understanding of the conversation to that point. Don’t worry about taking longer to interact; making sure that you’re both agreeing to the same thing can be more valuable.

About the book and the author

The book The Human Side of Agile: How to Help Your Team Deliver, from which this article is excerpted, will be released tomorrow, September 12th. With this book, Gil Broza has created a practical, universal guide to navigating the least manageable, understood, and appreciated asset in an Agile environment: its human side. Even if your customers are reasonably happy and your developers seem to be doing okay, you know your team is capable of more: delivering great products and staying ahead of ever-changing demands. You want to feel good about using Agile and to create the conditions for great results, but the skills you honed in traditional environments don’t always apply to the role of Agile team leader. The Human Side of Agile fills this gap, guiding you to:

·         Establish yourself as a confident and capable leader who adds value

·         Build and lead an engaged team that can handle almost any challenge

·         Cultivate collaboration and a continuous improvement mind-set

·         Reap the full benefits of Agile in the real world with real people

Gil Broza has mentored more than 1,500 professionals in 40 companies within the last 10 years who then delighted their customers, shipped working software on time, and rediscovered passion for their work. Gil offers much-needed services (beyond basic education) to help ScrumMasters and other Agile team leaders grow in their roles. In addition, he provides workshops, consulting, facilitation services, and enablement programs to fix lackluster Agile attempts and support ongoing Agile improvement efforts.

Click on www.TheHumanSideOfAgile.com to discover the “virtual loot bag” you’ll receive from Gil’s network of collaborators and experts for ordering your copy on the 12th.

Don’t forget to leave your comments below.

What Should I Do If My Agile Team Can’t Be Co-Located?

Written by Gil Broza on . Posted in Articles.

One criterion for team selection is member co-location. Whether working in nearby cubicles or in an open space, short distances between members contribute to communication and collaboration. The ease of casual interaction, the ability to observe facial expressions and body language, and the immediate sharing of artifacts facilitate team evolution. When a co-located team experiences conflicts, they are more likely to manage them healthily, rather than to pretend they don’t exist.

Depending on your office layout, you might be able to secure a team open space, also known as a “bullpen.” If your office is all desks or cubicles, and members work in various parts of a single office, see whether they can switch locations to be within walking distance of each other.

A new Agile team was spread all over one huge floor, with no hope of desk switching or dedicated space. When I suggested that they take over the windowless, cramped classroom in which I taught them the Agile fundamentals, they were excited! Their project manager obtained the right approvals, and for several weeks they worked happily and productively in this otherwise-dismal space. In the meantime, other arrangements were made for them.
If team members’ locations are fixed, hopefully they are not too far apart. A 30-foot distance (about ten meters) suffices to deter people from leaving their chairs to engage colleagues in face-to-face conversation.[i] In closer quarters, your team may be more inclined to communicate in person and use phones and chat software the rest of the time.

But what if your team cannot all be in the same place? Industry experience shows that, despite the extra challenges, the increased overhead in time and money, and the loss of productivity, dispersed teams can nevertheless be quite Agile.

The alternative to direct communication tends to be technology. Nowadays, person-to-person video calling costs next to nothing, works reasonably well, and is fairly easy to set up. Group conference calls are still at the shared-screen and conference-call evolutionary stage. More powerful, almost-in-person solutions are becoming more commonplace, but they are not immediately and constantly available at the individual team level.

However, once a team cannot make do with visual and presence-based communication, they must rely on tools to capture and track their plans and artifacts. These tools make some parts of planning and tracking easier, and some harder. They might also have the following negative effect: even when many of a team’s members do inhabit the same space, they may gravitate to the tools, email, and chat to converse among themselves, rather than leveraging the potential of closer in-person communication.

Teams are quite vulnerable to “out of sight, out of mind.” If you see a teammate — on screen or in person — for only two hours a week, you’re less likely to feel the bond of shared purpose and mutual commitment. If most of your communication is on the phone, that’s another discouraging factor. Most team members are likely to process information visually rather than auditorily, [ii] which makes concentrating on a phone conversation difficult for them. And the remote people participating on speakerphone usually have a rather poor experience; for the most part, they struggle to hear and identify speakers. Their temptation to disengage and multitask during a conference call is huge. They might tell you “I can’t hear,” but they won’t tell you “It’s hard for me to focus and be on the phone for so long.”

Geographical team distribution has three common forms:

  1. Most of the members are co-located; one or two are remote (probably at home).
  2. Half the team is in one site; the other half is in another site.
  3. The entire team is distributed (for instance, they all work from home).

If you have the choice, avoid form 2. Such a team naturally devolves into two subteams that work largely independently. The situation is even worse from the perspective of team growth and collaboration when one of the halves is the obvious “home team” and the other one is known as the “offshore team.”

Distribution form 1 is less susceptible to the clique problem. It might work well with highly engaged people who already have a previous working relationship. Since onsite folks can easily make progress and decisions, the constant risk is that they don’t remember or care to pull remote ones in and involve them. It’s an effort they don’t always wish to make.

The best option is form 3, since it puts all team members on an equal footing. They will invest in communicating and coordinating with each other. They will set up their technology effectively and adjust their process and practices to their reality. Many successful open-source projects operate this way.

A company in downtown Boston allowed every employee to work two days of every week at home, to reduce their commute time. One of their teams was a hybrid of the co-located and the distributed. All its members chose to work from home the same two days, and the rest of the time they were co-located.

If your team has even a single remote member, one technique to strengthen the entire team is pair programming. Block off several hours every day during which the entire team is available and pair programming is the norm. Help the team make this an explicit agreement. Make sure technology is not an issue: everyone should have personal headsets, fast computers, and fast screen-sharing software. If the pairs switch around at least once a day, this pair-wise way of growing a team will strengthen team bonds in a matter of weeks.

About the book and the author

The excerpt above is from the book The Human Side of Agile: How to Help Your Team Deliver which will be available September the 12th. With this book, Gil Broza has created a practical, universal guide to navigating the least manageable, understood, and appreciated asset in an Agile environment: its human side. Even if your customers are reasonably happy and your developers seem to be doing okay, you know your team is capable of more: delivering great products and staying ahead of ever-changing demands. You want to feel good about using Agile and to create the conditions for great results, but the skills you honed in traditional environments don’t always apply to the role of Agile team leader. The Human Side of Agile fills this gap, guiding you to:

  • Establish yourself as a confident and capable leader who adds value
  • Build and lead an engaged team that can handle almost any challenge
  • Cultivate collaboration and a continuous improvement mind-set
  • Reap the full benefits of Agile in the real world with real people

Gil Broza has mentored more than 1,500 professionals in 40 companies within the last 10 years who then delighted their customers, shipped working software on time, and rediscovered passion for their work. Gil offers much-needed services (beyond basic education) to help ScrumMasters and other Agile team leaders grow in their roles. In addition, he provides workshops, consulting, facilitation services, and enablement programs to fix lackluster Agile attempts and support ongoing Agile improvement efforts.

Don’t forget to leave your comments below.

[i] Thomas J. Allen, Managing the Flow of Technology (Cambridge: MIT Press, 1977). The “Allen Curve” shows that the probability of communicating technical information at least once a week drops below 8% when a ten-meter distance separates people, and levels off below 5% at 30 meters and higher.

[ii] Walter Leite, Marilla Svinicki, and Yuying Shi, “Attempted Validation of the Scores of the VARK: Learning Styles Inventory With Multitrait–Multimethod Confirmatory Factor Analysis Models,” Educational and Psychological Measurement (2009): 2.

What Are the Stages of Team Evolution?

Written by Gil Broza on . Posted in Articles. 1 Comment on What Are the Stages of Team Evolution?

Almost half a century ago, the American psychologist Bruce Tuckman published a theory of team evolution.[i] Agile software development teams did not exist at the time, but Tuckman’s Group Development model applies well to them. According to the model, a team has to proceed through a certain sequence of stages on the way to the desirable stage, performing.

In the initial stage, forming, members learn what the team is supposed to accomplish. They get to know each other and their first-draft idea of roles and responsibilities. In this stage, most of the work is still individual, and some members try extra hard to look good. The forming stage is generally short-lived, overshadowed by the realities of the next stage.

In the second stage, storming, the team experiences conflict and difference of opinion. Some of the decisions they need to make draw out tensions and emotions. There might be some jockeying for influence and leadership. In a new Agile team, the first several iteration planning sessions tend to include disagreements about estimation approaches, the extent of detail in user stories, and task assignments.

If the team can pull itself out of storming, whether on its own or with your guidance as the Agile team leader (ATL), it reaches the third stage, norming. Members understand the rules of engagement. They establish, follow, and adapt agreements. Everyone understands the team’s goals the same way and cooperates to achieve them. They know and follow their process.
The fourth stage, performing, is the big deal. A performing team doesn’t just hum along — it buzzes. Its members are motivated and delighted to be there. They don’t have to speak with the same voice, but they don’t let conflict turn into confrontation. Consensus and self-organization are easy for them. They don’t worry about making their team work anymore; that has been taken care of, and now they focus on results. They don’t merely cooperate, they collaborate.

The following diagram[ii] shows the change in the team’s effectiveness in the various stages. Note that the qualitative effectiveness level in norming is similar to that of forming. In forming, they are a group of individuals who apply themselves; in norming, the added value of their teamwork may still not compensate for the energy they spend on being a team.

GilBrozaAug71

This model has several important implications for you. The team is at risk of never reaching norming. Team growth is evolutionary, and success is not inevitable. Even with the most suitable people using the best methods with good support, there is no guarantee they will graduate from the storming stage. Some teams may appear to have normed, but in reality they put on a happy face, stifle all conflict and differences, and defer to their product owner and managers.

Three teams were working on a single program. To be cross-functional, each team had been formed with half of the Batch Team (back-end) specialists and half of the Online Team specialists, in line with the main technological divide. Each half was further divided into programmers and testers, working in handoff fashion. Iteration planning sessions were muted and ineffective; retrospectives were louder but resulted in little traction. After a year of using Scrum, they struggled mightily to figure out roles and collective ownership — self-organization was all but moot. Few people seemed happy.

Expect conflict. If you put intelligent, capable people together and ask them to share responsibility for a goal, how likely are they to agree on the means to get there? How likely are they to exhibit a healthy balance of leadership and followership? Conflict is necessary for the elaborate dance of team growth. It is not inherently detrimental, unless it is allowed to devolve into confrontation and one-upmanship.

The road to low performance is paved with good intentions. Whenever you add people to a team, even temporarily (such as contractors), you knock the team down a stage or two as they adjust to their new composition. New permanent members require an investment of time, energy, and goodwill from veteran members. If you redeploy a valued member to seed or help another team, the remaining members will restorm to fill the void and adjust their leader-follower patterns. (You can mitigate the effect by seeking their agreement to the move.) If you remove a noncontributing member, the team will have to adjust the norms they had established to accommodate that person. All these changes in team composition spell a drop in performance, which might last longer than you intend, even indefinitely.

“Our team was originally bolstered with several contractors, who stayed for differing periods. Only once the last contractor had left and we had settled into a stable team — well over a year after the team was first created — did I feel the team really started to jell.”

— Ian, software ATL in a hardware company

About the book

The excerpt above is from the book The Human Side of Agile: How to Help Your Team Deliver which will be available September the 12th. The human side of Agile is tricky. It’s the least manageable, understood, and appreciated asset in an Agile environment. Even if your customers are reasonably happy and your developers seem to be doing okay, you know your team is capable of more: delivering great products and staying ahead of ever-changing demands. You want to feel good about using Agile and to create the conditions for great results, but the skills you honed in traditional environments don’t always apply to the role of Agile team leader. The Human Side of Agile fills this gap, guiding you to:

  • Establish yourself as a confident and capable leader who adds value
  • Build and lead an engaged team that can handle almost any challenge
  • Cultivate collaboration and a continuous improvement mind-set
  • Reap the full benefits of Agile in the real world with real people

[i] The original paper is Bruce Tuckman, “Developmental Sequence in Small Groups,” Psychological Bulletin 63 (1965): 384–99. For a recent review of the concept, see Mark K. Smith, “Bruce W. Tuckman — Forming, Storming, Norming and Performing in Groups,” Encyclopaedia of Informal Education (2005), www.infed.org/thinkers/tuckman.htm. In 1977, Tuckman added a fifth stage, “Adjourning,” to describe the dissolution of the team (Bruce Tuckman and Mary Ann Jensen, “Stages of Small Group Development Revisited,” Group and Organizational Studies 2 (1977), 419–27). While this important stage is potentially stressful for some members, it is outside the scope of this book.

[ii] Based on Jon R. Katzenbach and Douglas K. Smith, The Wisdom of Teams: Creating the High-Performance Organization (Harvard Business Review Press, 1992).

Don’t forget to leave your comments below.