Running a Distributed Agile Project
In many ways, the IBM team works exactly as a colocated agile team would. They begin an iteration with a planning session where the team identifies the tasks to be completed during that iteration and who would do the work. These planning sessions include modeling where each user story is elaborated by the people who are going to work on it. The goal is to work through enough of the details to plan the iteration effectively, although greater detail is model stormed throughout the iteration as appropriate.
Daily stand-up meetings on distributed teams are a bit different than on colocated teams. The people in a given geographical location hold local stand-up meetings where they discuss basic status informationwhat they did since the last stand-up meeting, what they hope to do next, and whether anything is blocking them. Then representatives from each location hold a shared coordination meeting. Whereas local stand-up meetings are typically held first thing in the morning, the coordination meetings are held at different times due to time zone differences. A good practice is to rotate the time that the coordination meetings are held to spread out the time-zone pain.
Distributed teams need better tooling than colocated teams because index cards, cork-boards, and whiteboards don't work well from a distance. One option is to do a lot of toolsmithing to integrate open-source tools, another is to use a collection of non-integrated tools and simply accept the resulting loss of productivity, and a third option is to adopt a toolset that specifically addresses the needs of distributed development. The project team uses IBM Rational Team Concert (RTC), which can be downloaded from www.jazz.net, which offers a fully integrated distributed development environment (IDDE) features such as distributed requirements management, distributed defect management, online team member status, integrated chat with full traceability, and process enablement. The team chose to invest in automation early to keep up with the rapid rate of development and the volume of change. RTC isn't just for developers, for managers it also offers dashboard capabilities which displays automatically generated real-time project monitoring capability including burn down charts, defect trend charts, build status, and resource allocation statistics based on the actual activities of team members (as opposed to the reported activities of team members which can often miss critical information). The integrated tooling significantly reduces the reporting burden on team members, enabling them to focus on actual development activities, providing the information required by remote people governing the overall effort.
Finally, two other critical practices for distributed agile teams are to have ambassadors and boundary spanners. Ambassadors are senior technical or business experts who travel between sites to share information between the subteams. Getting the team together at the beginning of the project sets the foundation for communication, but without continual investment in maintaining effective collaboration between teams you run the risk of your subteams deviating from the overall strategy. Boundary spanners are located on site who focus on enabling communication between subteams as well as within their subteam. There are typically three flavors of boundary spannersteam leaders who take on project management responsibilities on the subteam, product owners who are responsible for representing the business within the subteam, and architecture owners responsible for technical direction on the team. These boundary spanners will work closely with their peers, having regular coordination meetings across all subteams as well as impromptu one-on-one meetings to deal with specific issues.
Greater Distribution Requires Greater Discipline
On a distributed project, agile or not, communication challenges are your greatest risk. The good news is that agile approaches focus on communication and collaboration, so we've already taken a step in the right direction. Being willing to invest in travel, doing a bit more up front modeling, organizing your team around the architecture, and adopting more sophisticated tools are key to your success with distributed agile. If you're interested in learning more, I highly suggest the IBM Redbook entitled "Global Development and Delivery in Practice: Experiences of the IBM Rational India Lab" (www.redbooks.ibm.com/abstracts/sg247424.html). The approach is a bit heavier than I would prefer, but it's written by people with years of experience at geographically distributed development.
I'd like to thank Rajesh P Thakkar, Lead Architect of the project team at the IBM software lab in Bangalore, for his invaluable input into this column.
Scott is Practice Leader Agile Development for IBM Rational.