Debate #11 – Can Agile work with offshore / distributed teams?

This is the 11th episode of “20 Controversial Topics of Debate in Agile“, and the topic of this blog is whether Agile can work with offshore, remote, or otherwise distributed teams.

In my opinion, it’s not ideal for Agile to have a dispersed team. Per the Agile Manifesto, the Agile philosophy states:

“Individuals and interactions over processes and tools”

Agile Manifesto

However, there is nothing prescribed in the Scrum Guide saying that events must be conducted in person, although it’s probably the “better” practice (at least Pre-COVID). So, can Agile work remotely?

Due to where I live, I have been a remote worker for many years, only traveling to one of my company or client’s offices for the Sprint Review, Retrospective, and Planning meetings. Since the pandemic hit, I have worked fully remotely.

While it’s slightly harder to do certain things online, I still think remote Agile teams can work. Based on my experience, here are some tips that can help:

Meet in person, if possible; if not, meet on video

Picture of a man wearing a mask on a video conference call

Try to meet in person at least once, if possible. It’s important to put names with faces and get to know people on a personal level.

Establishing rapport is difficult to do from a distance, but you still need to do it. This is an important first step in working with people who are far removed.

If it’s simply not possible to meet in the same physical space, conduct your Agile events and meetings via videoconference. This is as close to meeting in-person as it gets. With the video turned on, you get to see body language, which is half of all communication.

Establish overlapping working hours

Photo of an analog clock on a desk next to a laptop

With distributed teams, team members are often on opposite sides of the country, or even across the world. If this is the case for your team, try to find a window of business working time that overlaps, and plan for communication/meetings during these time periods.

If there isn’t an overlapping time that works for everyone during the business day, you may need to agree to either start early or take evening meetings. This isn’t always fun, but everyone needs to be willing to adjust.

Then, rotate the schedule to keep things fair. One group shouldn’t always take precedence over another.

Use available technology communication tools

Photo of connected people

Leverage the amazing technology that exists to improve communication, including (but not limited to):

  • Video conferencing
  • Digital white-boarding
  • Collaboration tools
  • Instant messaging
  • Audio conferencing
  • Whatever other tools can enable better communication

Tip: while it might be a little harder to have fun retrospective activities remotely, I have found that Miro is a great tool for this. Be creative with your remote retros so they don’t get boring or repetitive.

Establish a shared calendar

Create a shared team calendar that can be accessed by everyone. Then, make sure all team members are aware of each other’s holidays and time off. This is especially important when working with people in different countries. If you don’t consider or aren’t aware of other countries’ holidays, it can cause real problems. If you know about them, you can then plan for these non-working days.

Also, when looking at capacity at the beginning of each Sprint Planning session, make sure you ask everyone if they have any planned time off. Then, reduce capacity accordingly.

Record important sessions

Due to time zone differences and work schedules, it’s not always possible to have all relevant parties in attendance at important meetings. Record those meetings and make them available for later consumption by additional stakeholders.

One caveat on this is to make sure that you get the consent of everyone on the call to record it. Not all companies are willing to have meetings recorded, and you want to make sure that you don’t violate any agreements or laws.

Create a Glossary of terms

To avoid problems with different languages, create a glossary of terms with definitions (and don’t forget aliases), so there’s a shared vocabulary for the project.

When creating your glossary, pay special attention to acronyms. These may mean different things to different people, depending on the context. An example that instantly comes to mind is “PBI”. When I hear this term, my mind goes straight to “Product Backlog Item”, but I’m working on an Enterprise Data Warehouse project right now, and in this situation, PBI means “Power BI”, not Product Backlog Item.

Learn about each others’ cultures

A little of bit interest and respect goes a long way toward bridging any cultural divides that may exist. If there are different cultures represented on your team, do a little bit of research so you can understand others’ perspectives.

taj mahal in india

Recognize that your approach to doing things may be perceived differently by people from other cultures and that some adjustments may be needed on both sides to ensure a successful working relationship.

Have fun!

People don’t work just so they can earn a paycheck (well, maybe some do – but not me). You should love what you do and do what you love.

So, inject some fun into your job! Have virtual happy hours, lunch-and-learns, or team-building activities. Laugh together as often as possible!

Wrapping Up

Agile is about people having relationships with other people and working together as a team. Just because your team is spread out across the globe does not mean that you can’t be successful. Try out some of these tips. If you have any other ideas that could help remote Agile teams succeed, drop me a note and let me know! I’m also looking for improvement opportunities.

Next up in this blog series:

  1. Can you use a Sprint 0 in Agile?
  2. Do you need Documentation in Agile?
  3. Is there a “right” way to write User Stories?
  4. What’s the best way to write Acceptance Criteria?
  5. How long should your Agile sprints be?
  6. Should all your Agile teams be run the “same” way?
  7. Which “flavor” of Agile is best?
  8. Can Agile co-exist with Waterfall?
  9. Story Size – What’s an Epic, Theme, Feature…?
  10. Can the Scrum Master be a team member, too?
  11. Can distributed Agile teams work?
  12. How should you estimate in Scrum & Agile?
  13. Is it OK to add items to the current Sprint?
  14. How should you manage your Agile backlog?
  15. Can an Agile team have more than one Product?
  16. What is the optimal size for Agile teams?
  17. Should Agile teams stay together?
  18. How should you handle defects in Agile?
  19. Can a hybrid of Waterfall and Agile succeed?
  20. What are the official roles on an Agile Team?