People new to the idea of agile software development think that you can only be agile with small, co-located teams where you have no political constraints. Yes, that's ideal, but most teams aren't lucky enough to be in that situation. Does that mean they should give up on agile techniques? No! It means that they need to be smart about how they apply agile concepts and be as agile as possible given their current situation. This month, I explore strategies that people have used when they found themselves in not-so-ideal situations.
Dispersed Agile Development
In June I participated in the Perspectives on Systems Informatics at Akademgorodok, Siberia where I ran a tutorial on agile software development. After the tutorial, a couple of people came up to me and said this agile stuff was great in theory, but that it wouldn't work for them. One person worked in an outsourcing company where their clients were in Europe, and another worked for a company where the development team was split between Copenhagen and Moscow. Both were convinced that because their team wasn't co-located that they couldn't be agile. Nothing could be further from the truth.
Ideally, you want to co-locate your developers and stakeholders to improve their ability to collaborate and communicate, thereby reducing cost (they don't need to document as much) and risk (you increase the chance that they understand each other) on your project. In practice, many teams find themselves in a dispersed, multilocation environment and must find ways to overcome the inherent communication barriers. In "Bridging the Distance" (www.ddj.com/dept/architect/184414899), I describe strategies for doing exactly that. Dispersed agile teams will begin a project together so as to build a common vision, will get together occasionally to fortify that vision, and will have people traveling back and forth between locations as needed. They'll also adopt collaborative tools such as chat software, desktop sharing software, and Wikis. They'll communicate with each other via e-mail, telephone/video conferencing, and (egads!) even some written documentation.
Large Team Agile Development
As I describe in "Supersize Me" (www.ddj.com/dept/ architect/184415491), it's possible to have large agile teams. In fact, the first Feature Driven Development (FDD) team was 50 people and the second was 150 people—and both projects were a success. It's quite common to hear about agile teams of 30 or 40 people, and one of the most successful software development teams in history (see the sidebar "Large, Dispersed, Complex, Political, and Yet Still Agile") is much larger than that (and they're agile).
Large agile teams typically follow several common strategies.
- First, they organize themselves into several small, co-located subteams.
- Second, they model their requirements and architecture at a high level early in the project so as to set a common vision.
- Third, they deliver working software on a regular basis, often once every four to eight weeks, to ensure that the subteams are working toward the same goals.
- Fourth, they coordinate their efforts via regular communication.
- Fifth, they hire good people with the skills to work effectively with others and to produce actual working software.
- Sixth, they adopt common philosophies and guidance (such as coding conventions) to support consistency within and between the subteams.
