After working with various teams over the past years, I’ve noticed that a specific group of communication habits significantly help speed up the delivery. When the team members practice these, the delivery flows smoothly; otherwise, there are lags and misunderstandings along the way, and the work in progress builds up. This post presents only three of these habits; the overall framework is still only partly formed, and I’d like to have more discussions and testing before putting together something more concrete.
The fundamental idea underpinning these habits is that the development team is doing well when it is delivering the right, high quality features quickly, with an emphasis being on the quick turnaround time for each feature, i.e. the cycle time. To do that, all team members need to be on the same page, and the development process for each feature should be moving along with minimum lag or rework. Basically, the development should be lean.
The corollary of this is that the team members need to:
- Be able to work together, possibly in the same complex codebase, with a large subset of the team working on the same feature until it’s done and then smoothly moving on to the next one;
- Continuously keep each other up-to-date on major developments;
- Smoothly hand over the work to the next person as it becomes ready, e.g. hand over the requirements to developers, hand over built features to QA or product owner for testing, etc.;
- Proactively unblock themselves if unforeseen blockages occur, such as a need to consult someone or get an external dependency moving.
To do that well, the team needs technology, architecture, and development practices that support rapid, quality development; good planning and product management practices; and, of course, great communication.
To build great communication, I found it useful to help the team members develop these specific communication habits.
1. Communicate continuously
Here, “continuously” being in the sense of “continuous integration“, not “constant, non-stop communication”; constant communication is undesirable because then no work gets done. Instead, continous communication, like continuous integration, should happen as soon as it needs to happen, not on a set schedule or at the end of some task. This practice is best illustrated by an example.
Meet the team
Let’s say three developers, Sam, Mandy, and Ali, are working on the same codebase and they’ve agreed on the technical design. Sam starts writing the code, but as he works, he keeps noticing imperfections in the design and gradually adjusts the code to account for those. Next day, when the time comes to integrate the code with Mary and Ali, it turns out that Sam’s code has substantially deviated from the original design, and the other two have to do a significant amount of rework.
Sam could have avoided this by letting his teammates know that he found a problem with the design and offering a correction. Mandy and Ali could have reviewed the correction and suggested improvements. Thus, for the cost of a quick interruption, Sam could have ensured that the team delivered faster and better.
Similarly, Mandy doesn’t need to dot every “i” in the code before handing the feature to the product owner for testing or showing the code to the other developers for a code review. Instead, she could start showing partially ready work, so that her colleagues could sooner discover any issues with the code, the requirements, or the design.
Building the habit
This continuous communication does not naturally occur to everyone, especially if they have worked in environments that do not encourage it. There are several mechanisms to make it happen:
- Suggest it to the team; some team members will likely agree and will start doing it.
- A technical lead managing junior developers could just decree it.
- In a team with more experienced members, it will likely be necessary for the team to meet, discuss, and agree that this is expected.
- With new hires, I have set the expectation of continuous communication in the interviews and during the onboarding.
In either case, it is worth emphasizing that the regular communication is not for the scrum master, the manager, or the product owner to check on the work, but for the team to keep the work flowing and to discover surprises as early as possible.
Whatever the method, it’s essential to keep the team members accountable to this standard. In the case of Sam above, if he is new to this habit, someone could casually ask him whether he needs to update Ali or Mandy on anything. If Sam shows a persistent pattern of not updating his teammates, this may warrant a 1-on-1 discussion with a warning that his actions are affecting the team.
2. Shared communication channels over 1-on-1 communication
The purpose of shared communication channels is to make the communication scale efficiently.
Discussing something one central place is more efficient than discussing it one-on-one and updating each teammate later. If Ali sends a pull request approval privately to Sam, then Mary will not know about it. She may not be needed to review the pull request, and may not even be interested in it now, but by posting the request in a shared chat channel, Ali would give her an opportunity to be aware that it is happening without doing any extra work.
Shared communication channels could take many forms, all of them with the purpose of making the communication scale:
- Scheduled meetings to review or discuss something;
- Chat channels, group email, and mailing lists;
- Ad-hoc conversations;
- Shared task boards, task lists;
- Wiki, or other documentation;
- Whiteboard with a design on it and a big “do not erase” sign.
Whatever the channel, I find the focus on the efficiency is critical; otherwise the team could get bogged down with needless meetings. Not everyone needs to show up to talk with an external vendor for two hours; instead, one or two people could go, and then update everyone in a 5-minute meeting, or, better yet, by email.
Similarly, I’ve given up on multi-hour planning on the first day of a sprint because most topics are not interesting to half of the people present, and detailed plans for work later in the sprint tend to change anyway. Instead, by combining the principles of efficient and continuous communication, we could shorten the sprint planning meeting to a 15-minute overview of upcoming features, and do the detailed design and planning as the team gets close to starting the work on the next item.
Well-organized written communication, such as documentation, or diagrams, tends to scale well but has a higher upfront cost. Chat channels and email tend to scale moderately. Meetings tend to drop in efficiency as more people join them, so it’s important to keep them focused and require presence only of those people who need to be there. Ad-hoc, one-on-one or group communication scales the worst but is best for resolving blocking questions.
Building the habit
The two parts to building this habit are figuring out the right communication channels and developing the habit of using them.
If the team does not meet regularly to discuss and decide something, Agile frameworks such as Scrum provide a good start, with meetings like planning, daily scrum, and retrospectives. These build the habit of regularly meeting together for a specific purpose. Over time, however, the team would benefit from reorganizing meetings, reducing some and adding others, like group code reviews or requirements reviews.
With written communication channels, I’ve gotten excellent returns from having a Wiki and a group chat like Slack.
The other side of this habit is redirecting the communication to the shared channels as much as possible. In my experience, repeated suggestions usually get the team most of the way there. For example, if a developer would ask me to review a piece of code, I’d suggest doing this with a substantial subset of the team instead. Or when someone sends a request for another team to do something, I’d ask to CC the rest of our team. Repeating the message of the importance of using the shared channels in the retrospectives also tends to help.
3. Proactive resolution of blockers
Extending the idea of not waiting to communicate, this habit has the team members act immediately when they find an unforeseen blockage.
For example, suppose a business analyst Fiona is almost done preparing the requirements when she realizes that she still doesn’t know what the source for a specific field should be. She could wait until the next scheduled meeting with the client, Bill, to find out, but that could mean delaying the implementation. Instead, ideally she would either call Bill right away or walk over to his desk to clarify this. Failing that, she would preferably email, or leave a voicemail, and only then fall back to the scheduled meetings.
Like with any interaction, this depends on whether Bill is receptive to unexpected calls. If they are infrequent and help resolve blockages, he probably will be. In fact, he may be glad that Fiona asked the right question that helped deliver a better product.
Similarly, if Ali (the developer) is troubleshooting a complicated bug and needs to involve another team, he should first try to walk over or call them right away and ask them to help, instead of sending an email and waiting a couple of days for a response.
Since ad-hoc, one-on-one communication scales the worst, this should be generally reserved for unforeseen blockages or urgent situations that were not identified during the planning.
This habit also helps in larger organizations where requests sometimes tend to fall between the cracks or get stalled at the bottom of someone’s to-do list. A polite in-person or phone question about the delivery timeline sometimes gets the request moving surprisingly quickly.
Building the habit
This habit requires the team members to overcome the anxiety of interrupting or inconveniencing someone. Unfortunately, the only way to become more comfortable with interrupting others is to do it enough times. Here, a more experienced team member could help someone new to this habit by setting an example or taking them along to talk to someone who did not expect them.
I usually introduce this to the new team members as soon as possible by taking them with me to talk to someone the first time they need something. With existing team members, often just a suggestion is enough (“Why don’t we ask her now?”), with an offer to come along if necessary.