11 September 2015
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 in 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 from my projects to explain Agile practices that work well in large multi-vendor distributed teams.
I have been working on distributed (offshore) teams for more than 14 years and practicing Agile & XP for eight years. In this post I attempt to list down things that have worked really well for us.
For a 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 teams’ day-to-day operations independent from one other. I agree sometime overlap is unavoidable, and they need to be identified, discussed and planned ahead of time.
On our current project we do cross-team planning every three months face to face. We define a backlog for three 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:
Two Week Workshop: two weeks of face-to-face collaboration
Slog Time: The team is prepared to stretch, but these two weeks will gives us clarity for next three months of work. So the effort is worth it!
Tips: During workshops, deep dive into solution, architecture and design discussions 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 no 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 a three-week production release cycle (an iteration) across teams.
The following are the list of cross team communications and meetings:
Tips: Apart from 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: Set up a separate call to discuss specific topics with invitations to relevant people only. Do not let meetings drag on. 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’ actually means, ‘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 ‘we 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 were no mis-communications.
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 makes 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:
1. Maintain healthy product backlog with clear separation and ownership by each team.
2. Have a clear architecture and design guidelines across teams, especially for teams working on same codebase/repositories.
3. Choose the right tool for the right purpose. Sometimes existing tools do not fit the distributed nature of project. Push back and convince people to get the right tool in place from day one.
4. Build a trusted environment across teams with clear and honest communication. A healthy environment allows people to share thoughts openly without any fear of repercussions. Take feedback positively and give feedback sensitively.
5. Run online meetings effectively, with visual aids, and good equipment, since it is not easy to find out if others are following or not.
6. Adapt practices and meetings with distributed and large teams in mind, and don’t be afraid to experiment to see what works for your team.
7. Also, it is equally important to give individual teams the full freedom to operate in their own space within a team e.g., having physical wall, retrospectives using stickies, huddles and discussions on whiteboards.
Lots of you may 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.
This post was previously published on Insights.