The Distributed Agile Team

Scott examines the myths surrounding agile software development.


December 02, 2008
URL:http://www.drdobbs.com/architecture-and-design/the-distributed-agile-team/212201434

One of the enduring myths about agile software development is that it's only applicable for small, colocated teams. Dr. Dobb's 2008 Agile Adoption Survey (www.ddj.com/architect/207600615) disproved this myth, with respondents indicating that agile strategies are being applied successfully on development teams of more than 200 people that a large percentage of agile teams are distributed. In "Agile and Large Teams" (www.ddj.com/architect/208700162), I discussed strategies for organizing large agile teams, and this month I'm going to describe the experiences of a product development team within IBM that is both distributed and agile.

If someone on a team is working on a different floor, working from home, or working in a different building than other team members, then your team is distributed. Figure 1 summarizes some results from Dr. Dobb's 2008 Agile Adoption Survey, showing that the project success rate decreases as a team becomes more distributed. Although this is alarming, it is not surprising—the greater the distribution, the greater the risk. However, the important point is that many people are succeeding at distributed agile development.

Understanding the Risks

The lower success rate of distributed development teams is primarily due to increased communication challenges. Even with near-location, where team members are in the same geographical region and could easily get together physically if required, there are communication risks such as people having different priorities or understandings of the requirements. Many organizations will try to paper over these risks by requiring detailed specifications, but as media richness theory showed decades ago, documentation is the least effective way for communicating information between people and can increase project risk further.

[Click image to view at full size]

Figure 1: Project success rates for distributed agile teams. The more distributed the team becomes, the riskier your project becomes.

Far-located projects, where planes would need to be involved to get people together, can suffer from cultural and time-zone differences. To counter these risks I make it a habit to ask open-ended questions to determine whether or not the other people understand the topic under conversation. Particularly, I never ask a "yes/no" style of question because the simple answer of "yes" can mean a range of things depending on the culture. It may mean:

When dealing with people at other locations, it's good practice to ask them to summarize the conversation in writing, even if it's a point form e-mail, to ensure common understanding of decisions.

Lack of trust in the abilities of others whom you don't directly work with or know well is also a problem, this is particularly true when multiple groups or companies are involved. This lack of trust will reveal itself with the insistence on the creation and then acceptance of detailed specifications to be provided to people at distant locations, a focus on the legal contracts between the organizations, and too little discussion of the overall process followed by "each side." Having consulted to several system integrators as well as to their customers, I can safely say that everyone involved with offshoring projects could benefit greatly from open and honest discussions of how they're actually working. Most system integrators would love to be able to provide better levels of service to their customers by adopting more agile ways of working, but mistakenly believe that their customers want to work in a more bureaucratic traditional manner. Similarly, their customers believe that the system integrators can't work in this way, mistakenly thinking that CMMI-compliant organizations can't be agile. My advice is to talk with your development partners and together explore more effective ways of working together.

To put my advice into context, I want to share with you some of the experiences of an IBM development team working on a next-generation metrics-based project and program management tooling which is built on the Jazz technology platform (www.jazz.net), providing support for reconciling various project processes such as agile, traditional and hybrids that are anywhere in between. The project team is currently 30 people strong with members in Bangalore, Boston, and Toronto. The project team has iterations of three weeks in length, with internal demos each week to ensure regular feedback from their distributed stakeholders and milestone reviews every six weeks to keep senior management in the loop.

Initiating a Distributed Agile Project

One of the first things that any disciplined agile team will do—and this is particularly true of distributed teams—is some initial up-front modeling, including both requirements envisioning and architectural envisioning. In the case of the project team, they worked with their product manager to identify a collection of core user stories which defined their initial scope, and based on that they defined the initial core architectural concepts to set their technical direction. Defining the architecture up-front enables distributed teams to organize themselves effectively, something discussed below.

Disciplined agile teams also do some up-front, high-level planning to identify their major dependencies and milestone dates—you don't need a monolithic, 1000+ task Gantt chart but you do need to think things through. Effective teams do this planning with the developers actively involved (they are part of the team after all), they strive to consider all associated costs, and in particular they don't overlook the low probability/high impact risks which often prove to be project killers.

Another critical strategy is to get the whole team together physically at the beginning of the project. Your goals are to build rapport amongst the team, to get to know the people that you're working with and thereby facilitate communication later on, and to better understand the situation on the ground. Although flying people around increases your initial expenses, it is an investment that pays for itself very quickly in overall risk reduction. My experience is that the least expensive way to pay for travel is to actually do it, the most expensive way is to not do it and instead increase your communication risks through documentation and bureaucracy. Sadly, this strategy is commonly sacrificed on the altar of fiscal short-sightedness, again increasing project risk.

Organizing a Distributed Agile Team

A best practice for distributed teams, described in detail in "Lean Development Governance" (https://www14.software.ibm.com/webapp/iwm/web/preLogin.do?lang= en_US&source=swg-ldg), is to organize your team structure around the architecture so as to reduce the communication required between various subteams. When you analyze the communication which occurs on software development teams the majority of it is between people who are working together to build a subsystem, so organizing the team around your architecture reduces overall communication risk. This is why initial architecture modeling is so important—by identifying the subsystems, and then investing a bit of time to define the interface to each subsystem, you put yourself in a position to let the subteams focus on their own work. The architecture owners on each subteam will still need to coordinate interface changes with each other, something I discussed in detail in my July 2008 column (www.ddj.com/architect/207600615). This architecture practice is called "API First" in the Eclipse Way, an agile methodology for distributed teams.

A very serious mistake would be to organize your team around job function, for example having a team of business analysts, a team of designers, a team of testers, and so on and so on and then try to shuffle work back and forth between these groups of specialists. This strategy increases the overall bureaucracy, and therefore overall cost, because you need to write more documentation, hold more documentation reviews, invest more effort in traceability, and so on to support this sort of team structure. It also increases the chance of finger pointing when things don't go so smoothly—working software is an order of magnitude more concrete and measurable than documentation that, therefore you can easily determine the value of what a subteam has or hasn't produced.

The one time to break this rule would be on an offshoring project with independent testing, described in "Scaling Test-Driven Development" (www.ddj.com/architect/205207998), where you have a small number of highly skilled testers who do complex forms of testing in parallel with the development team. By having the independent testing done in parallel by a small team at the customer site the customer effectively monitors the overall progress of the team and the quality of their work while decreasing the need for up-front detailed specification, onerous milestone reviews throughout the project, and time-intensive comprehensive testing at the end of the project (you'll still need to do some testing at the end of the project, but nowhere near as much).

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 information—what 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 spanners—team 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.

Acknowledgments

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.

Terms of Service | Privacy Statement | Copyright © 2024 UBM Tech, All rights reserved.