Agile teams are often distributed over space and time. SpiderLogic is an extreme example with 11.5 hours separating the two India offices from the two US offices. We are able to successfully address this challenge by focusing on communications and a sense of team. Incidentally, communications and team work are the two main reasons for co-locating teams.
Communicate, Communicate, Communicate
Process and Tools
Like any good team a distributed team also needs shared agile processes and the tools to support them. Processes included solid engineering practices like continuous integration, automated deployments and agile frameworks like Scrum or Kanban. They also need web versions of agile artifacts like the product backlog, iteration backlog, team backlog tasks, Scrum or Kanban board, acceptance tests, planning poker etc. Finally they need communication tools such as Skype, web conferencing, virtual whiteboards and Google Docs/Office 365.
Delta Time Compensation
To minimize the impact of communications delays use process and roles. To allow more time for the communication delay, complete defining the user stories and acceptance criteria the iteration before development. To facilitate rapid communications, we have more defined roles than Scrum (later blog). Almost always we have a PM/BA/CSM and architect in the US for rapid communications with the product owner particularly around requirements and technical architecture. The product owner works for and at the customer. The rest of the team or teams are in India.
Even in co-located teams we think we have shared understanding but do not. Co-location compensates for this. Distributed teams need to constantly strive to communicate in multiple ways and multiple times on the important stuff. The process of discussing, documenting and reviewing helps everybody else think. Typically two days before an iteration ends, we review the potential backlog items for the next iteration. We call this over-communicating to avoid hesitancy in ourselves and others when reviewing what we may feel is obvious or that we should have understood or brought up the first time. Synergy is based on shared understanding triggering ideas off of discussion.
Expanded Daily Call
With distributed teams there is a small window of overlap. A good practice is to plan for time after (or during) the daily call to discuss anything that needs to be discussed. We will discuss this further in the next section.
A Sense of Team
A team takes time to build and become a cohesive unit working effectively together. This is more challenging when teams are distributed. We are not interchangeable cogs in a software machine. We strive to maintain long-lived teams as much as projects and staffing allow. Most often this also includes the Product Owner(s) and/or customer. Long-lived teams also allow more opportunities to get together and build relationships over the course of multiple projects and releases.
Take time for small talk and to have fun. Have periodic calls to discuss anything including technical challenges, process issues or personal happenings. Don’t be afraid to make jokes and enjoy the team time together in the daily call or the team call.
Teams are formed around shared goals. They should also have shared ownership of the code, product, process, acceptance tests and team. Fundamentally teams are about sharing.
The Magic of Distributed Agile
During the summer when the US has more sunshine, the sun never sets on our teams. The magic is most evident during system test when issues or enhancements are found one day and fixed or implemented, tested and ready to deploy the next morning. One other added advantage is you can collect your updates, answers, questions etc. and send them all at once at the end of the day because the team will not read them until their morning. It also naturally minimizes interruptions to and from your remote team members.