You may have noticed that I no longer refer to the development team, or Dev Team, in the title of this series and this is for a good reason. Ken Schwaber and Jeff Sutherland abandoned the use of “Development Team” in favor of, simply, “Developers” in the 2020 update to the Scrum Guide. Their reason for doing so was to make it clear that a Scrum team consists of a Product Owner, a Scrum Master and Developers. The previous distinction of Development Team left some people wondering if there were “two teams” involved.
Back to high performing teams…
The first three articles in this series focused on Scrum team performance as a whole, skills needed for dev team performance, and team composition for dev team performance, the latter being the second of three things developers require to help them achieve high performance.
To review, those three things include…
- Rudimentary development skills
- Cross-functional team composition
- Excellent communication skills
This post is about the third and final requirement.
Excellent Communication Skills Needed
We humans are sensitive creatures, albeit the list of those sensitivities is vast, meaning that different external influences affect each of us in different ways – but each of us are affected – and subject to exhibiting all sorts of behaviors in the face of differing environments, circumstances and treatment: Treatment by others and our treatment of ourselves.
The best way to help build a team’s communication skills is to provide, and insist upon the practice of, psychological safety, which means…
- Meetings are a safe space for all to share, devoid of criticisms
- Participation is inclusive of all active members¹
- What is said in team meetings is confidential
- Meeting participants provide their full attention to one another, so mobile phones and other distractions are left behind
A positive outcome to providing this safety is… safe environments are also excellent learning environments. We learn faster when we feel safe. Learning is accelerated when two things happen:
- We get to know the other learners on the team
- We allow other learners to get to know us, and that requires vulnerability
And since being vulnerable requires us to suppress the fight-or-flight parts of our brains, a safe environment is what is called for. High performing teams rely upon heightened awarenesses and the shared knowledge of what we – and the other team members – like, care about, are capable of doing, etc.
Vulnerability
When I hear the word vulnerable, my mind goes straight to an image of a cornered animal, just waiting to escape or perhaps preparing to attack if threatened. In parts of the world where trust and respect are relatively high, it is easier for individuals to be open with others. In yet other places – including many parts of our own society, and especially where misogyny, racism, xenophobia are culturally persistent, allowing oneself to be vulnerable is a scary proposition.
Non-Verbal Communication
Depending upon which study you read – for example, here’s one from Psychology Today – up to 93% of all communication is nonverbal in nature. Examples of what I mean by nonverbal include…
- Posture and other body language
- Gestures
- Facial expressions
- Tone of voice
- Direction and gaze of eyes
…and many others; convey information the speaker is communicating, and this is likely a combination of both voluntary and involuntary bits of information. Because of this, face-to-face communication conveys more information than virtual communication (Zoom, MS-Teams, etc.) and virtual communication conveys more information than voice, such as with a phone call.
According to the University of Minnesota’s Communication in the Real World,
“A primary function of nonverbal communication is to convey meaning by reinforcing, substituting for, or contradicting verbal communication.”
∴ If we can’t see the communicator, most of what they are conveying may simply be lost to us.
Barriers to Effective Communication
There is a very real cost associated with allowing poor communication to exist anywhere in an organization, but this is especially true in teams. Good communication results in a positive flow of information. It is an enabler of bigger and better things to come, and faster and clearer learnings. Poor communication results in effectively stepping on this flow.
External barriers are those things that, at least in part, exist outside of ourselves. We will examine internal barriers at another time.
Some obvious external barriers to communicating effectively are…
- Control Structure
- Conflict
- Shame
Control Structure
When describing agile ways of working to others we frequently compare waterfall methodology with agile methodology [See my earlier post on agile methods for a refresher]. The two methodologies are effectively worlds apart. Typically, waterfall methods were used in industry throughout the world – particularly in software engineering – and were associated most strongly with a top-down, command and control management structure. Regardless of where knowledge resided most abundantly, power was centralized. Note that “top-down control” and “waterfall” did not have to be linked, I’m just observing that they were.
Many companies have a difficult time in letting go of their old management structures, particularly if the company’s culture supports it. For companies that are trying in earnest to transition to agile ways of working, a heavily top-down control system results in work delays or even work stoppage at the team level. Control of teams must reside with the teams for agility to have a fighting chance at successful adoption company-wide.
Conflict
Conflict is a part of the human experience. In two extremes it can be used as a reason to attack others or it can be used as a learning tool. The trick to deriving a learning experience from conflict is to develop new awarenesses from one another when conflict occurs. What does it take to resolve conflict in a positive way?
Providing Clean Feedback
Clean feedback is exactly what it sounds like: When used correctly it helps bring people together rather than wedging them farther apart. To my mind, “dirty feedback” might be something that is designed to undermine confidence, somehow manipulate others, or is simply ineffectual and therefore potentially harmful. If you cringe when you hear the word feedback then perhaps dirty feedback is what you’re used to receiving.
Clean feedback is formulaic; it has three distinct components that are used in the same order every time, as follows…
- Provide Evidence – What did you see or hear?
- Express Inference – What did you make of this evidence?
- Opine on Impact – What did you think were the impacts to yourself and/or others?
So… what’s so great about clean feedback? First and foremost, good evidence can speak for itself. For example, “The team door was left unlocked last night” leaves little room for guessing what happened. But what someone infers from the door being left unlocked could be altogether wrong or misguided. Therefore clean feedback, by its very nature, leaves the way open for discussion.
Let’s extend our door example to demonstrate why this is so effective:
Team Member Giving Feedback – to the other team members:
- “According to the Security Audit from 9pm last night, the Team Room was left unlocked” [evidence]
- “This makes me wonder if one or more of us are somehow less concerned about keeping our customers’ information safe” [what FG infers]
- “This possibility feels demotivating to me and it could be catastrophic for our team’s reputation in our business division” [what FG thinks the impact(s) could be]
Team Member Responding to the Feedback provided by GF:
- “It is true that the Team Room door was unlocked last night at 9pm – actually, both before and after 9pm – but only while several of us were actually here, testing several possible solutions for the next release. I was the last one to leave and I made sure the door was locked on my way out.”
In the above example it is clear that GF had a good point to make and that RF was able to extend GF’s evidence to show a bigger picture. When executed well, clean feedback is quick and efficient. It heightens good communication and dispenses with hurt feelings.
In addition to mastering clean feedback, people who are new to agile ways of working may find the following useful in their journey to communicate more effectively…
- Courage – It takes courage to say the things that must be said to one another, especially for those who would rather avoid conflict of any kind
- Respect – Navigating conflict effectively requires us to be respectful of one another’s experiences and opinions
- Openness – Conflict becomes less scary when we’re able to listen fully and with curiosity – to understand one another’s viewpoints.
- Transparency – At best, communication can only be partially successful in resolving conflict if anyone involved is keeping secrets.
These values and behaviors are exactly what are needed to move past conflict to a better mutual understanding. If you recall from a previous post (Scrum, the Essential Agile Method for Software Development) that the first three things on this list are Scrum values and the fourth is one of the three pillars, or precepts, of empiricism.
Shame
Shaming of any kind does not belong in the workplace. In fact, IMHO shaming should be abandoned in all human-human interactions. Shaming is toxic. Shaming is the antithesis of Agile. The Agile Mindset encourages individuals and teams to take small, calculated risks in order to accelerate learning; to “fail early and fail often,” as it were. Shaming, on the other hand, is a sort of punishment for having taken any risk at all.
If you are a shamer, stop doing it. If you work in a toxic, shaming workplace and do not have the ability to reshape it, go find work where people embrace the Agile Mindset. It will change your life for the better.
Author Brené Brown does a brilliant job of describing the harm in – and some remedies to counter – shaming. If you’re not already a devoted fan, starting with Men, Women and Worthiness: The Experience of Shame and the Power of Being Enough will help you understand shame and what’s at stake.
Additional Information
As I’ve discussed before culture plays a big role in successful agile adoption. For a list of other values and behaviors that are both supportive of – and not supportive of – agile adoption, see my post on how culture drives agile transformation.
Are You Listening?
Something I’ve learned in my journey as an agile coach is listening to others is a skill. By learning to listen deeply, with intention and with the speaker’s wants and desires in mind, we model excellent communication for all others to see and learn from.
Long term agilists – those who’ve belonged to, and helped to build long lasting teams – sometimes make the best agile coaches, specifically because they’ve honed their communication skills and have learned how to listen well to others.
To become a high performing agile team, each member of the team must master the skills discussed above as well as the art of listening to others.
Author’s Note
¹The Daily Scrum is an example of an event that contains a prescribed set of active participants, the Developers, plus an optionally active participant – the Scrum Master. Although the Product Owner is encouraged to be present at all such events they are not a participating member.
