Training and Onboarding Series: Managing Agile Teams Remotely

Managing Agile Teams Remotely


Well before the recent pandemic, Agile teams were trying to figure out how to be functional while also being distributed.

One of the 12 Principles of Agile is face-to-face interaction, or as it is commonly referred to by the Agile community: “co-located.” The idea is that being in the same room and same space furthers collaboration and improves communication, which in turn benefits both dynamics and output. There is an important thing to remember about the Agile Manifesto though: it was developed as a guide. Even the authors have said repeatedly (and I’m paraphrasing): “It’s there as a guide, but make it work for you.” Many companies are doing what they can to make Agile work, while hosting at least a handful of locations, if not more, for their development teams. Just about anywhere you go will have at least the US and India as two main hubs for work. Add in the heavy amount of developers in Ireland, and now you’re battling 3 time zones that never really align together.

 

What’s the answer? How did we approach this before the pandemic, but especially now when even those that can be collocated are dispersed by the COVID-19 pandemic, what can be done to ensure teams are still producing with quality?

Technology is certainly one important factor. Of the many technologies available, MS Teams in particular has said they saw at jump in usage by 37% in just one week at the onset of the pandemic and stay at home orders. MS Teams is competing with Slack for much of the business sector, but add in Zoom, Google Hangouts, and Facebook Messenger as options for collaboration, and you have a bevy of resources at your disposal for team communication and collaboration.

 

We’ll look at these communication options, as well as a couple other points on how to effectively manage your distributed Agile team. Before we get into solutions, we first need to understand the issues. Most distributed teams are going to have some, or all the following issues to navigate:

  • Team Rapport
  • Coordinating/Scheduling Meetings Across Time Zones
  • Team Understanding of the Business Needs
  • Infrequent Communication

 

The good news is that most of the above issues are only going to hit a team that moves from being co-located to being distributed. If a team starts out fully distributed, then typically they will function at or above similarly structured co-located teams.

 

So, your team was co-located and now they are distributed. How do you build or maintain rapport? In my opinion, team rapport is the number one issue to affect productivity. You can communicate immensely, document all the business needs, and meet regularly, but the team is not going to perform at a high function without rapport.

 

A sport like soccer is the quintessential analogy for Scrum.

It’s fast-paced, our objectives are changing regularly, you need to move at breakneck speed for the full 90 minutes, a star player isn’t going to do anything without a team effort, and there’s someone shouting from the sidelines about everything you’re doing. That soccer team can do drills until they’ve perfected them, and they can collaborate and communicate about strategy until they have mastered it. They can develop and thrive in the ambiguity of the game. What will take that team to the next level and make them unstoppable is the camaraderie that comes with team rapport.

 

Rapport helps the entirety of the team. One individual, most likely the star player, will have realized the defense will perfectly defend your play and make a strategic change in the plan. If the team holds a level of rapport to know that the player is riffing, then they can also adjust. Without that rapport, they will simply follow the plan and it will be defended. I have played on soccer teams in my life that won games primarily because we were a close-knit group that could sense each other’s intentions – those dynamics outweighed raw talent as compared to our competition.

 

Scrum teams may not face a competing force like an opposing team, but they will face changes and ambiguity. Whether those come internally or from the stakeholders, they will come, and that Scrum team needs to be able to adjust as a whole unit. This is much easier to do when you all know and understand each other.

 

So, what can we do during this particular time of distribution?

Use the same techniques you did before but alter the content. For example, instead of an after-work meetup, host a virtual “happy hour.” There are many more ways to encourage virtual rapport building with a bit of research and creativity.

 

Improving communication and collaboration will help team building and is also a very important factor for distributed teams. Learning how to use virtual whiteboard apps is a good start to replacing those sticky note boards. Yes, they aren’t going to be as easy to manage and use as a real-life board, but if done properly, can be a close second.

 

Instant chat and videoconferencing are great compliments here that can really boost the communication and collaboration. You don’t have to rely on videoconferencing just for meetings. Videoconferencing can be leveraged to keep open communication throughout the day by leaving it up and open for people to jump in or even stay on as they work, which can especially useful in paired programming frameworks. It’s also important to remember that your team members may be struggling with the personal/professional aspect of working from home. Keeping a video up needs to be a team decision and one that ensures all voices are heard.

 

You may want to ask the team if there are volunteers to alter their workday hours, which could benefit both the team and the individual. If one were to move to an earlier start time, that would provide more overlap with different time zones as well provide that individual the opportunity to utilize their afternoon for family. Documenting more can also help the gap in overlap. Another misnomer I believe to be prevalent is the idea that Agile teams shouldn’t document things (working software over comprehensive documentation). This principle isn’t saying you shouldn’t document things, it’s simply stating that when it comes down to it, working software is more important than say a test strategy document. However, when distributed, documentation can keep the communication in sync. Improper documentation, though, can add confusion and take away time from the team – so always ensure the documents that are created are shared openly. Any notes taken during team meetings are encouraged to be gathered by all team members so that there is a reference point if any issues arise from a question on a document.

 

A final thought: how the team worked when they were co-located may no longer be the best option while distributed, and I would recommend that you look at your desired outcome. Determine what makes your ceremony/meeting/collab successful, and then define what that looks like now. You can tie in what made it successful while you were co-located and use that as a guide to mimic/alter in order to get the same results while distributed. Try not to abandon what was done prior; simply try and alter it so that it’s still included.

 

If you can manage to keep your team chemistry up, keep lines of communication open and easily accessible and adapt to the circumstances, you’ll find your team well on its way to succeeding. The main keys to success in any Agile team are learning and adapting, no matter how or where your team is located.

 

I hope you enjoyed this series; my previous two articles can be read HERE and HERE. Subscribe to our blog Olenick Expertise to receive the latest thought leadership written by Olenick consultants to your inbox.

 

For information on Olenick’s Agile support services, reach out to us.

Aaron Ring Headshot

Aaron Ring    


Related Content: Agile Assessment

Don't Miss An Olenick Article!

Subscribe to receive our latest blog articles, right to your inbox.