​Collaboration Techniques for Large Distributed Agile Projects

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. 

1) Healthy product backlog with clear separation

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: 

• Mountaineer Team: 
  • Three or Four members from each team participate and travel to a centrally convenient location. Usually this comprises of a developer, a BA the Tech Lead and sometimes the PM. 
  • Rotating team members, which allows people across teams to meet in person and build rapport and also understand the business perspective and prioritization. This helps in connecting people to the project.
  • We name these members as the Mountaineers for the quarter, who own functionality from planning, development upto delivering it to production.
• Two Week Workshop: 2 weeks of face-to-face collaboration
  • 1st week: Each team creates their backlog, splits them into stories, brainstorm solutions, build a common understanding of assumptions and requirements, and estimate the stories at a high level (S/M/L).
  • 2nd week: Perform Prioritisation followed by dependencies and risk identification across teams and first few iteration level planning. Here some more senior stakeholders are present, who can represent the business and provide clarity and priorities based on next one year vision. 
  • Each team publishes their summary at the end of workshop
• Slog Time: The team is prepared to stretch, but these two weeks will gives us clarity for next 3 months of work. So the effort is worth it!

Signs of not having a healthy backlog,

• Frequently, the team spends a lot of time over a call to identify what work they need to do
• Confusion in understanding scope of the story 
• Cross team integration issues
• Team stepping in to each others functionality and codebase, creating confusion and defects
• Each team driving solution, architecture and design in different directions, resulting in conflicts and frustrations 

Tips: During workshop deep dive into solution, architecture and design discussion for cross cutting features, so everyone is heading in same direction during implementation. 

2) Choose the right tool for team collaboration

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:,

• Good conference equipment with video capability: Tools like WebEx/GoToMeeting/Fuze (min 50 users at a time should be possible) and each team member should have a nice headset and clear sound quality speakers for the room. Poor audio encourages people to get distracted easily.
• Mingle for agile project management and tracking tool:  This is the only tool in the market which will elegantly allow each team to define their own customized information radiators, and provide very nice views to understand project level status. 
• Google Docs for collaboratively creating documents and diagrams with easy sharing. Allows simultaneous editing with history, review with commenting, create and include diagrams within documents. 
• Group Chat like IRC/Hangout/Skype/Slack. We use simple Google Hangouts, one for each topic and add relevant people to reduce noise and increase collaboration.  Slack is quick promising in this space.
• IdeaBoards for distributed retrospectives and collaborative decision making. 
• Trello for short-term ToDo list for distribute teams to follow up.

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. :-)

3) Effective Agile Practices

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:

• Cross team daily standup, 
  • Duration: 30 min, each team 5 min
  • Agenda: quick high level update, any blockers, issues and challenges the team is facing, any help needed from another team, plan for follow up discussions
  • Who: most of the time mountaineers of each team (2-3 people from each team)
• Daily BA call, with limited required people only to discuss story scope, acceptance criteria, release dependency, and a demo of the work in progress and completed stories
• Weekly iteration checkpoint, mountaineer team, to share progress, blockers and any change or impact on release 
• Release/Iteration showcase (including quarterly progress)
  • Duration: 1 hr, each team 15-20 min
  • Agenda: showcase only key functionalities,  team progress for current quarter,  challenges etc.
• Cross team Retrospective
  • Duration: 1 hr 30 min, every alternate iteration (initially every iteration)
  • Use tools like 'Idea Boardz' to capture point before the start of the meeting
  • Agenda: In meeting discuss highest voted topics and take action items
  • Who: Distributed retrospectives are difficult since retro involves discussions and actions. Ask everyone to add points for retrospective and identify few representative from team who can present those points well.  
• Schedule independent meetings for specific topics, and invites only relevant people

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,

• Use some visual artifact to drive discussions like a simple textpad or mind-map or draw a simple diagram or take a snap of a whiteboard discussion.
• Use collaborative tools like Google Docs, Trello
• For specific topic discussions, invite only relevant people, avoid crowd

Tips: Setup a separate call to discuss specific topic with invitation to relevant people only. Do not drag meetings. Prepare for them in advance.

4) Clear and honest communication

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,

• People are not attending calls or avoiding discussions over call or join late in calls.
• Need to do multiple calls to close on a decision, or to come to an agreement.
• People are not paying attention in the call and asking points to be repeated.
• Team says YES in call and nothing happens later. It’s like agreeing on action items of a retrospective and then zip -- nothing happens.

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.

Summary

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 right tool for the right purpose. Sometime 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 other are following or not.
6. Adapt practices and meetings with distributed and large team 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 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.