Typically, distributed teams have constraints in collaborating face-to-face. I’ve been part of a distributed agile team for quite some time now. My project is distributed across two countries - India and the US. We have a small team onshore and a larger team offshore. Despite the constraints, there’s a lot that I have learnt as a project manager on the team and I would like to share my takeaways from it.
#1 - Communication
As our smaller team is present on-site, they have the advantage of sitting next to the Product Owners. They also get to interact with the architecture team, database team and other third party system experts who are present on-site. Communicating with these people is very critical for developing the product. Better communication results in better decisions and eventually a better product.
At times, communication between the on-site team and the offshore team can also be a challenge. The offshore team ends up playing a smaller role in the decision making process, which usually happens on-site. As the offshore team is largely responsible for the execution of decisions, they lose the opportunity to be involved and learn from the discussions. We tried to fix this communication gap by having a distributed developer huddle once a week - where the whole team got together to discuss and prioritise work items.
#2 - Trust
To deliver a goal, you need a team bonded by trust. The offshore team needs to trust the on-site team and vice versa. Inceptions are a great place to build trust, where the whole team gets together to discuss a common goal. For those who haven't heard of an Inception, it is a workshop which varies from two to five days, and is specifically designed to ensure that the development team and the key stakeholders share the same vision of the project.
Another way to build trust is through co-location. Travel plans on a rotation basis work very well for this. If the offshore team is small and there is a budget, then moving the team to one location in order to run at least one iteration would really help build the trust. If there are budget constraints, then a proper travel plan needs to be factored in. This should mostly be on a rotation basis and across roles so everyone gets a chance to interact with the on-site team, Product Owners and architect teams in order to establish trust and confidence.
# 3 - Promoting a Shared Vision in the Team
Agile teams emphasise heavily on iteration planning, retrospectives and daily stand ups. These are opportunities for the entire team to get involved. Participation brings in a sense of ownership. Picking the right project management tool can play a big role in promoting the shared vision. A common agile wall can help all developers pick their work from the same pool, thereby diffusing knowledge silos.
In distributed teams, there is a challenge to find that common time when the whole team can be present. Having the whole team present in a distributed stand up adds to this shared vision. Apart from stand ups, retrospectives are a great place to bring up what's not working in favor of the team and what needs to be done. Ideally, both the teams should do a joint retro every iteration. Due to time constraints, if it is not be feasible to have one joint retro, then both the on-site and the offshore team should share retro notes with each other.
# 4 - Short Iterations and Continuous Integration
Short iterations help you track progress on a regular basis. It allows you to seek feedback regularly as well. Short iterations also help break the tasks down into smaller steps, thereby helping you make accurate estimates. Almost every project that I’ve worked on, we have implemented Continuous Integration. CI with a good test coverage is a must have for distributed teams. It helps you find the build issues immediately. Both teams endeavor towards a green build. CI is not about the tool, but more about the discipline and taking team responsibility to ensure a working application with every check in.
So these are my takeaways from working in a distributed agile project. While they are not easy to implement, the results are rewarding in the long run. This is certainly not an exhaustive list, so would you have more to add to this? Leave me a comment!
Disclaimer: The statements and opinions expressed in this article are those of the author(s) and do not necessarily reflect the positions of Thoughtworks.