An article by Stefan Mintert and Jens Thiemann. Jens is a Management 3.0 Facilitator and Community Founding Member who is driven by developing and building people and organizations. He brings more than 25 years of experience in leadership roles from his work in different types of organizations, including distributed team setups. Stefan’s mission is to let people thrive and grow at work. He does so in different roles from Scrum Master to leadership coach as well as in his new role as Management 3.0 Facilitator.
In this article you will learn:
- What are distributed teams?
- What are the challenges for the distributed team in agile?
- How do I deal with distributed teams in agile?
- How do you become a high-performing distributed agile team?
What are distributed teams?
Distributed teams are teams whose members do not all work in the same location.
As simple as this statement sounds at first glance, the spatial distributions in practice are very diverse. And for the management of the teams, the details of the distribution are quite important.
Two examples:
Consider a Team A consisting of two groups. Each group consists of five members. Each group has its own location. The group members meet daily at their location.
In such a scenario, probably each person will perceive their group as their team. In fact, this case can also be seen as two teams working on the same project or product. It is more of a scaled agile situation than a distributed team. In terms of leadership, the question then is: how do I lead multiple teams (at different locations)?
In the second example we have Team B with ten members. Seven of them work at the company headquarters every day. The other three each work alone at other locations, at home, for example.
In this case, one center of collaboration is obvious: in the company’s offices, where the seven people work. The other three work remotely. They are satellite workers.
For meetings, that’s difficult. A meeting in the meeting room, with three people video-called in, is a challenge. While the seven people in a lively conversation may interject or continue a colleague’s sentence, the three satellite workers stand apart. Their contributions are to be announced by a show of hands or in some other way. The flow of conversation in the room comes to a halt, and the remote colleague takes over for a brief moment. After work, the seven colleagues can spontaneously grab a beer. In doing so, they strengthen their connections with each other, while the three satellites remain on the outside.
In our understanding, a truly distributed team only exists when there is no center, or centers, of work. Given this, neither Team A nor B, is a distributed team. This is because in a distributed team, cohesion is at risk due to the lack of personal contacts. In Team A, this is not the case, but it is very much the case if all team members work in a home office.
For more information on different team topologies, see the blog article Remote versus Co-located Work by Martin Fowler, where he describes the different situations in detail.
In terms of terminology, we prefer “distributed” for teams without a center and “remote” for all cases where a center of work exists, and team members are not equal in terms of their “remote” status (hybrid).
What are the challenges for the distributed team in agile?
How can leaders handle the challenges of remote teams in an agile environment?
Agile teams are characterized by a high degree of self-organization and self-management. The Manifesto for Agile Software Development values interaction between team members more than following predefined processes (also see: Agile Product Development module).
This interaction and finding out which is the right way (emerging practice) requires a team culture in which conflicts can be dealt with productively. A prerequisite for this is, among other things, the certainty that one’s own team values failure as a consequence of courageous experimentation and not as a faulty decision. But it also requires the security of being able to bring an opinion that differs from the majority into a dialog without negative consequences.
For this kind of safety, you must be able to rely on belonging to the team, the tribe. Emotions play an important role here, which in turn are strongly influenced by personal contacts. A handshake, a high five, a pat on the back after a success, they all signal belonging and release happiness hormones such as dopamine and oxytocin. In the absence of such contacts, team cohesion can erode.
In distributed teams, another challenge is that a lot of body language is lost in video calls. (Also see: The Power of Face-To-Face Communication) If the camera is turned on at all, only the face and part of the torso can be seen. Loose or tense posture can not be easily seen. Bouncing feet, or an unsteady slide on the chair, are not visible. Due to the screen resolution, small signals in facial expressions are more difficult to identify. Did my conversation partner just look angry or thoughtful? Was he amazed or shocked? Such questions are not always easy to answer in a face-to-face conversation; in a video call, it is much more difficult to find the right answers.
If the team already knows each other better, for example because they regularly have office days together or worked together before the pandemic, there is certainly a level of familiarity. However, if a new team member is taken on in this situation, or a new distributed team is forming, then further efforts to get to know each other must be taken.
These include using real names and real profile pictures in the team’s collaborative tools. Whether editing a document together or viewing the team board, it is much easier to build a relationship with team members when they are identifiable. This sounds like a no-brainer advice, but please check how many of your team members follow it.
Also read: What is Collaborative Leadership?
How do I deal with distributed teams in agile?
The lack of personal contacts and the reduced bandwidth in communication require strong team leadership. The task of a manager is to recognize the challenges and to guide the team to deal with them. And this, by the way, can be done by anyone in the team.
Leading distributed agile teams is a responsibility for all: management and team
Leading Distributed Agile Teams: Communicate more
If communication through body language is lost, that needs to be compensated with more communication such as asking questions and clarification. For example, if the team has made a supposed decision, you might want to explicitly invite each team member to comment on the decision. If a comment does not clearly indicate agreement or disagreement with the decision, the team should express this ambiguity and ask about it, if necessary.
Leading Distributed Agile Teams: Express emotions
More situational and spontaneous is the use of emoticons to respond to statements during a video call or in a chat flow. This sounds trivial, but it should be part of any team culture. Moreover, emoticons correspond more to a “silent” body language than a “loud” written “okay” and thus close at least part of the communication gap. It’s not for nothing that tools like Teams or Zoom offer the possibility to express one’s own mood by “thumbs up”, “smile” or “heart” in the flow of another person’s speech.
Leading Distributed Agile Teams: Listen more
Managers who practice “management by walking around” in the co-located case can replace this with “management by talking around” in the distributed case. This means keeping time free in the calendar to attend team meetings as a listener or to specifically address individual team members.
These conversations should also provide space for personal topics and not (only) focus on work. Transparency as to who is working on which topic should be provided by an actively maintained Jira board and a “work-out-loud” channel, and should not have to be clarified only upon explicit request. Work-out-loud means that you regularly write in the team chat what you are currently working on. Especially when changing tasks, you offer your colleagues an opportunity to join in or ask questions. This can turn into spontaneous pair programming or a small learning session.
Leading Distributed Agile Teams: Provide space to talk non-work
Social contacts that are normal in everyday office life are often lost altogether in distributed teams. Here, a manager should set an example that conversations about non-work topics are okay during working hours. If such conversations take place in the co-located case, for example, during a joint lunch, the manager can invite people to the “digital coffee kitchen” after the distributed lunch break. In doing so, we recommend doing it without an appointment. Instead, we prefer to start a video meeting in a channel for “off-topic” topics and send a spontaneous invitation in the chat. Such an invitation might read, “I just made myself a coffee and would like to chat. Who’s joining me?” This should not remain a one-off, but become a habit. If a team tends to meet after work, a “digital campfire” or “after-work” can be a good alternative.
In the invitation, you then replace coffee with your favorite drink and see who comes along. It goes without saying that the design must fit in with company rules; if alcohol is not allowed on site, this should also be respected in the distributed case.
Also read: The Best 6 Virtual Team-Building Activities
Leading Distributed Agile Teams: Use great tools
The basis for these messages to reach everyone is that everyone uses the same communication tool. Ensuring that this is the case and, in particular, preventing the formation of subgroups is a key task for leadership. For example, prevent team members from working with each other in a different chat tool, separate from the rest of the team.
We’ve worked with companies where one area was using MS Teams and another was using Slack. And guess what the result was: communication between the two areas was miserable or almost non-existent.
In addition to classic tools such as video call and chats, newer tools such as Welo, Topia or Gather also offer the opportunity to experiment with the team and bring a good portion of fun into the daily work routine.
Leading Distributed Agile Teams: Apply Management 3.0 Practices
Another way to maintain and strengthen a team by becoming more personal, is inviting team members to draw and share their own Personal Maps. You could add the maps to the Intranet profiles and seek opportunities to follow up on these: “Hey Bob, I saw in your Personal Map that you are a big wave surfer. Can you share something about that in the digital coffee kitchen? Do you have any photos? Where did you surf the biggest waves?” or “Hey Alice, your Personal Map reveals that you worked for an NGO in Central America for 10 years? I’d love to learn more about that in the digital coffee kitchen.”
In teams that practice a daily stand-up, it sometimes happens that one or the other doesn’t know what to say on Mondays. On the weekend, other topics were in the foreground. Therefore, it is a good idea to address these topics as well. Perhaps it can become a ritual if everyone reports in the Monday stand-up what they did on the weekend for their 12 Steps for Happiness.
If team members want to express their mood more frequently, dedicated channels or the hashtag #mood in the chat have proven effective, such as “#mood nervous (important demo today)” or “#mood happy (just like this)”. A bit more formal is the use of a Niko-Niko calendar, which provides a good overview of the current status and mood development in the team.
How do you become a high-performing distributed agile team?
The prerequisite for successful teamwork is the establishment of trust. We described at the beginning how relevant this is. This trust forms the basis for the team to deal with conflicts constructively.
Also read: Four Ways To Build Trust With Remote Employees
High-performing distributed agile teams have healthy conflicts
Conflicts can only be constructive if they do not take place between people, but rather conflicts are carried out in the matter at hand. In other words, it is about something, not someone. It is also not about winning (debate), but finding the best idea for a problem (dialog).
However, unnecessary conflicts should of course be avoided. Avoidable conflicts and uncertainties often arise when there is no clarity about the goals or about the way of decision-making. The team is then either paralyzed or stumbles into a conflict.
High-performing distributed agile teams agree on decision paths and have clear goals
It is good and helpful to compile agreed decision paths transparently and clearly for all, e.g., by means of a Team Decision Matrix.
Clear and comprehensively formulated goals need not only be sprint and product goals, but can be described and tracked as Object Key Results (OKRs). A Scoreboard can prove to be a useful tool here.
For a high-performing distributed agile team, enhance the team setup
Returning to the article by Martin Fowler mentioned at the beginning, the final note is that a distributed scenario significantly increases the possibilities of team composition. Not only in terms of team diversity, but especially in terms of the skills of the individuals. Those assembling a new team have the choice of hiring the best people who want to work in a specific location (co-located team). Or they hire the best people who want to work on a specific target (distributed team), which can add up to a more powerful team. For an overview of the current and missing team strengths, a Team Competency Matrix can be useful.
Do you already have a team agreement in place for your distributed team? A step by step guide on creating a team agreement.
High-performing distributed agile teams have time to recover and experiment
But even when a team is high-performing, it needs phases of recovery. This is another way in which leadership can create the right system or environment: give each individual space to experiment or solve problems that they feel are important. As a side effect, this can also lead to great successes, as the development of Gmail has shown.
These free times can be regularly scheduled into the calendar and team members encouraged to use them.
Summary: Leading Distributed Agile Teams
Distributed work offers many advantages. The challenges are the lack of personal contact and the resulting disadvantages that erode team cohesion, trust and psychological safety.
But it’s not solely a management responsibility to work on this. Rather, team members need to look out for each other, and should take on leadership roles themselves as the situation arises.
Thus, leading distributed agile teams is even more of a management and team responsibility than it is for co-located teams.
Management 3.0 offers tools and suitable workshops to support managers and teams.
For further information check our Remote & Hybrid Collaboration module on how to better manage remote teams
Interesting reads:
- Top Tips for Transitioning Employees Back to the Office
- The Key to Being an Excellent Remote Manager
- 8 Remote Team Leadership DO’s and DONT’s
- How to Effectively Manage Remote Employees in Multi-Locations
- Agile Leadership explained
Photo by charlesdeluvio via Unsplash
