Expecting people to have great communication skills naturally is never a good idea. Everyone communicates differently. How they communicate evolves over time, hopefully to become better, but sometimes not. And with developers, that spectrum of communication skills and styles can be very wide.

So, how can you get your team to communicate well?

The first thing I can suggest is to provide some baseline, default expected behaviors; communication protocols.

Communication Protocols

Communication protocols ⏤ expected behaviors of your team that advance good communication practices ⏤ should not be secret or unexpressed. They should be stated and described in your team's Working Agreement and understood by every team member (and don't forget having new team members buy into the Working Agreement). There's nothing extra special about the Working Agreement. It is a simple contract that spells out the expected behaviors that can make your team successful. You can find out more about Working Agreements at the Atlassian website. Here are a few example protocols which you may find helpful to your team.

The Goal for Team Communications

The Goal

The goal is to have your whole team practicing good communication every day so that when the $#!+ hits the fan, everyone has these practices to fall back upon, these patterns established, and these expectations of others and themselves to lean on.

See Something, Say Something

A great, and very simple protocol to start with is the "See Something, Say Something" Protocol. When team members are working in the application they are developing and something goes wrong --- unexpected behavior, errors, or crashes --- the team should expect that event to be expressed to the team. The wrong dialog message appeared? Say something.

Your developers, product owners, and business analysts have to take responsibility for their application. This isn't about blame. It is about responsibility. Identifying these problems early and often (as necessary) ensures that everyone on the team knows they exist. Having them identified means that your product owner can say something like "Hey, are you working on that feature that calls that dialog? Remember, that bug about the dialog message? See if you can fix that while you're in there!" If the defect has not been documented, it can't be planned.

Side Note: See Something Positive, Say Something Positive

Side Note

Sometimes it is really easy to only apply See Something, Say Something to potentially bad things. That isn't necessarily true. During a recent pull request review I found that a developer had written some code in a way that made the code easier to read and reduced lines of code. It was a new technique to me, so since I saw something, I let everyone know about it.

The See Something, Say Something can absolutely be used as positive reinforcement, as providing recognition, and as a way to celebrate good work.

If your team is taking responsibility for their application, ignorance is not bliss. If your team is not finding these problems through manual, unit, and end-to-end testing, then the users are finding them. And, typically, users seldom report defects.

What form does reporting this defect take? It can be a line of text in a Slack channel, a new User Story or Bug Report, or what ever form your team decides. The important thing is that whatever was seen is documented and discussed, not ignored.

Protocol: See Something, Say Something

Protocol

What: Responsibility of all team members to report any bugs, errors, bad areas of code, user feedback, and any things that may affect your application's performance or perception. It is vital to document the items discussed so that action can be taken.

Who: All Team Members

Why: Communicates ownership and responsibility of the team toward their work.

NAZ: No Acronym Zone

Acronyms suck. I mean, I get it. You think you are saving time by not saying actual words. But, what if someone in the meeting doesn't know what the acronym means? Now, that person has to either interrupt the meeting to ask for a definition, or worse, silently lose the context of the discussion.

Excluding someone from a conversation is disrespectful, even when done accidentally. All just to save the effort it takes to make a few more sounds with your mouth.

Your team should start practicing this protocol in team-only meetings. Normalize team members asking people to "use all your words" when they hear an acronym. This may seem rude, but it is holding everyone to the agreed upon communication standard. Once they get into the rhythm of not using acronyms, your team may find that when a pointy haired manager type attends a meeting, the chances they will understand what is going on will be better.

Protocol: No Acronyms

Protocol

What: Responsibility of all team members to do their best to avoid the use of acronyms when ever possible.

Who: All Team Members

Why: Keeps communications clean, provides context, eliminates confusion.

Not in My Hallway

Remember back in the "before times" when everyone was working in the same office? We were all commuting for hours, going out for lunch, and complaining about that jerk who warms up fish in the break room microwave? (Perhaps you remember it more pleasantly than I do.) And there were hallways. And in these hallways you might see a teammate and have a brief discussion and perhaps make a decision. "I'm going to fix that bug as part of the user story I've been assigned." And the only people on the team who know about this decision are the two members in that hallway.

Let me be clear, I am not suggesting that these conversations not happen. Your team should be comfortable with having all kinds of discussions. The part that is bad is the information hoarding. It wasn't good behavior when we were in offices, and it isn't now. And it can still happen when your team is all remote, just change the word "hallway" to "chat".

The suggested protocol here is "No Hallway Conversations without Reports". That means, have all the discussions, meetings, and chats that you want in one on one situations. But before anyone takes action, ensure the entire team is alerted to any information change or decision that has been made. And, just like "See Something, Say Something", that report can be as simple as a chat message, a new user story, a new bug report, or a meeting invite. But make certain the entire team is notified. By informing the team, you can avoid problems like for instance, deciding to fix a bug that someone else had already been assigned. It can facilitate better decision-making, and generate team buy-in.

Be careful while implementing this protocol as to avoid stifling communication, the exact opposite idea of what these suggested protocols are about. Reinforce with your full team that having that there is nothing wrong with having one-on-one discussions, but not reporting back to the full team is bad. And always reward and celebrate team members when they remember to report back to the team.

Protocol: No "Hallway Conversation" without Reports

Protocol

What: Responsibility of all team members to always follow up any side conversations with a report covering the the information shared and any decisions or actions associated with that conversation.

Who: All Team Members

Why: Keeps communications open, informs and enables the team, supports collaboration, and prevents information hoarding.

I Declare

The act of making your intentions known is a powerful communications tool. These days, with all-remote and mixed-location teams, people need to be purposeful about their intentions. Simple things like heading out to an appointment without letting people know can create confusion (and panic in some). Letting people know you are going on vacation a week (or two) before your last day? Yeah, that would be a great way to set expectations.

The Declare Your Intentions protocol makes it the responsibility of every team member to let their entire team know when they are going to be unavailable. Any kind of scheduled absence is one of the basic items falling into this protocol. Team members should put the event on their calendar (so no one will schedule a meeting during that time), reschedule or find someone to cover any already scheduled meetings, remind everyone of the upcoming absence with as much lead time as reasonable in your Daily Stand Up meeting. And always let people know when you have returned to your desk.

We're not talking about typing "Hey, I'm heading out to lunch" into your Slack channel every day at lunch time. Just things that make you unavailable during expected working hours. And we're not looking to track your every action. Just trying to set expectations well before any issues come up.

Protocol: Declare Your Intentions

Protocol

What: Responsibility of all team members to always inform the team of any scheduled absences with plenty of warning.

Who: All Team Members

Why: Informs whole team of schedule conflicts, and prevents confusion and panic.

Conclusion

These are just a couple of communication protocols that work reliably with teams today. You can use these if you think they can help your teams. Create your own protocols. Generate buy-in with your team for these protocols and be sure to add the protocols to your Working Agreement. Like with everything in your Working Agreement, regularly review all of your protocols. Is the protocol working? Great. If not, update it. Or remove it if it is of no use. As your team evolves, so will your protocols.

Keep striving for great team communications.