Distributed Agile: The Why and How of Remote Scrum Teams

In my first real developer job I was working in a very small team in a startup. We were building a new front-end application from scratch. The team at the time consisted of only me, a junior front-end developer, and one more senior colleague.

There was one particular challenge that gave us a hard time in getting the project off the ground: My senior colleague was based in Sydney while I was based at the company’s main office in Berlin. I was surrounded by other developers in that office but the person I was working closely with – and the only other front-end developer in the team – was a couple of thousand kilometers away.

Making design decisions together and getting help from my remote colleague was a big challenge. Most of the time I had to wait until the next day to get an answer. Some written conversations dragged on for days. Because of the time difference it was also extremely hard to stay in contact over the phone. When I was just starting my day in Berlin, he would be finishing his day in Sydney.

After my initial experience with that mini remote team I’m now facing a similar challenge in my current role at AND Digital: I’m working with a Scrum team which is distributed between the UK and India. This team is much bigger and altogether we are spread between four offices.

This raised a question in me: Can you do agile in a distributed team? Does it make sense or should a Scrum team always be in the same location together?

After doing some research it turns out that in the world of software engineering it’s actually considered highly controversial whether or not having a distributed Scrum team is a good idea or not…

Why it’s a good idea:

  • Hiring offshore or remote developers can help closing the gap of finding enough tech talent in the main country you are operating in.

  • Per-head cost can be cheaper for remote developers.

  • When the decision to go with remote developers has been made, mixing them in a team together with on-site colleagues facilitates a greater exchange of knowledge in comparison to separating the teams per location. This makes it also more likely that both sides are working in the same direction.

  • With workers in different timezones a product can be worked on almost 24 hours a day and so the time to reach the market for new products and features can be significantly shorter (with excellent management).

  • Being able to work remotely from home can help better the work/life balance of team members and so can boost morale.

Why it’s a bad idea:

  • Working in different locations and timezones adds a lot of communication overhead when working on the same product. Looking at the agile manifesto it says: ‘Individuals and Interactions over processes and tools’. The interaction part is hard to put into practise over long-distance when you can’t just go over to someone’s desk and start chatting.

  • Related to the latter point the 12 principles of the agile manifesto also mention: ‘The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.’ How efficient can a Scrum master remove impediments if part of the team is not in the same place? Similarly how effective can a tech-lead give advice to people in another place and time zone?

  • The 12 principles also say: ‘Business people and developers must work together daily throughout the project.’ With business people often onshore while most or all of the developers could be remote this constitutes a definite challenge. How well does an offshore team understand the product and the requirements when there is no analyst or product owner on site with them?

  • Another one from the 12 principles: ‘Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.’ How do you keep a remote team motivated in the long run? How do you build trust and personal relationships over a long distance?

  • It’s debatable if hiring offshore developers actually decreases costs because of the added process and management overhead. My opinion is that with good management it can save costs, but the danger that it just adds frustration and effectively costs the same because of lower productivity is very high.

  • There might also be a cultural challenge e.g. if you work with an offshore team based in India. The people working for you might expect clear instructions from a project manager instead of the shared ownership and responsibility that agile propagates. How do you transfer the agile/Scrum culture and approach onto a team that might have been trained to agree with everything they are asked to do?

If you are in position to decide if your Scrum team is going to be distributed or based in one location you might consider the above mentioned points and make your decision. Happy days!

But what if you don’t have that power or if your organisation already has distributed teams? What can be done to improve the agile ways of working between continents or countries if you have to work with distributed teams?

What can be done to improve team feel and productivity across a distributed team?

  • Both sides could consider sending rotating ‘ambassadors’ to the team on the other end. When they are on site those ambassadors can then build personal relationships with the other team. In the future this can help facilitating communication much more easily because they know the ‘remote personalities’ and their surrounding work conditions much better. People are also much more likely to raise issues when the have a good personal relationship.

  • Having informal meetings that are focused on how the remote teams work together and that should contain a good amount of small talk.

  • Consider installing a Scrum Master who speaks the languages of all team members across the different locations. Being able to translate will foster a good understanding of the project requirements on both sides. Understanding the cultural differences better should also help making the communication between both sides much smoother.

  • Celebrate successes together to stay motivated. It can’t be that the offshore team members don’t get any of the (metaphorical or literal) cake when a release went well. They need to be included so that they feel part of the team and know what they are working for.

  • In terms of core working times you should try to agree to a window of time overlap that works for everyone. If the agreed time is an inconvenience for anyone try rotating the time to make sure that the inconvenience is shared between everyone.

  • Being mindful of holidays onshore/offshore for scheduling releases and workload.

What can be done to improve technical collaboration in a distributed team?

  • When kicking off a new project in a distributed team the senior developers should work on the base architecture together in the same location for a while to make sure that the project is built on stable ground.

  • Developing your software in a modular way allows teams in different locations to work autonomously on their modules. The technical communication overhead and potential for misunderstandings will decrease when only APIs and integrations need to be discussed.

  • If on the contrary the remote team members work on the same codebase then remote pair programming using screen sharing can accelerate knowledge transfer and a coherent coding style. Make sure that code reviews are shared between locations for the same reason.

  • Using CI and small increments and reviews can help immensely for onshore and offshore to keep in sync.

  • Written documentation that both parties can turn to when the other party is off due to the time difference can be very useful.

  • Consider transferring knowledge to remote developers by transferring analysis capacity to the remote location. If this can’t be done on a permanent basis then analysts from the main location should travel between locations regularly to give the remote developers the business context. Understanding why something is build will influence many small decisions that need to be made every day and eventually result in a product that is more appropriate for the purpose it was intended for.

For tips on specific tools and techniques that can help improve collaboration between remote teams please also see this article by my AND Digital colleague Dan Parkes.