In past few years, it has become quite common for software development teams to be distributed across time-zones and comprise of multiple vendors with 50-100+ people.
Agile practices encourage in-person interactions to foster collaboration, whereas, distributed and large teams force communication into the opposite direction. Therefore, it is important to achieve agility albeit with different, or modified mechanics, that work well for distributed and large team.
I have shared examples for my project to explain Agile practices that work well in Large multi-vendor distributed teams.
I have been working on distributed (offshore) teams for almost 14+ years and practicing Agile & XP since 8 years. In this post I attempt to list down things that have worked really well for us.
For distributed team to be productive, it is important that each team knows clearly what they are working on. Having a healthy backlog is a good sign for any agile team, and it becomes very important when we are working in distributed mode.
It is also equally important that there is a clear separation of work, which helps in making the team’s day to day operations independent from each other. I agree sometime overlap is unavoidable, and those need to be identified, discussed and planned ahead of time.
On our current project we do cross team planning every 3 months face to face. We define a backlog for 3 months and iteration level planning for next iteration, so that every team knows what they are working on.
The mechanics of our ‘Quarterly Planning & Prioritisation Workshop’ is:
Signs of not having a healthy backlog,
Tips: During workshop deep dive into solution, architecture and design discussion for cross cutting features, so everyone is heading in same direction during implementation.
Choosing the right tool for collaboration is important and one should not hesitate to drive change in organisation. Agile and distributed teams are different, so why use tools that are not meant for such purposes.
Here are a few noteworthy tools:,
Tips: Buy a new project specific domain and register to Google Apps for Business and you will have everything up and running without maintenance and upgradation worries.
Distributed agile is a big change and very difficult to do effectively unless everyone in the organisation is willing to extend help to each other. This is a good opportunity to challenge and retire some old legacy tools from the organisation. :-)
Standups, retrospectives, iteration planning, demo and showcase, etc are all important practices of agile development. However, we need to tweak them appropriately to make them effective in distributed team. My mantra is that each team should have the freedom to define their own internal processes with some cross team cadence.
In our project we follow 3 week production release cycle (an iteration) across teams.
The following are the list of cross team communications and meetings:
Tips: Apart of above cross team cadence, each team can define their own way of operation like standup, internal huddles, internal retrospectives and showcases, etc.
Something that worked well for me in facilitating and driving online meetings,
Tips: Setup a separate call to discuss specific topic with invitation to relevant people only. Do not drag meetings. Prepare for them in advance.
In face to face communication, it is easy to judge if someone is saying 'YES', but their body language is saying 'Maybe'. Or, if 'Okay' mean, 'YES' or 'NO'? Such observations are difficult over a call, and therefore it is very important that you speak clearly and honestly in calls.
If we cannot do something say I can’t do it, otherwise reputation gets destroyed over time. Also, it is equally important to say 'I Agree' or 'I liked the idea' so that others know you received the message and everyone is aligned. Similarly, at the end of a sub-discussion, it is important to summarize the discussion, and ensure there was no mis-communication.
Many times, we share our screen with an open editor (Notepad/Sublime) to type the minutes as they are being discussed, so that people who may have missed parts of the discussion because of poor audio quality at their end, can also keep up, and further, writing down issues make attendees feel that the point has been noted, and a follow-up will happen.
Signs of broken communication,
Tips: Do not hesitate to travel and meet people in-person if conference calls are not working well or turn out to be ineffective for certain complex (political or technical) discussions.
As a summary:
Lots of you would have worked on such projects. Please feel free to leave comments about your experience and learnings with distributed agile projects, and what tools and techniques have helped you along the way.
Disclaimer: The statements and opinions expressed in this article are those of the author(s) and do not necessarily reflect the positions of Thoughtworks.