Application development is no longer about one individual working on a project. Today, application development frequently consists of multiple teams, located across the globe, collaborating on a software project. As more and more organizations implement agile development to varying degrees, it is becoming clear that distributed development is not only a fact of life for many teams, but it is a growing segment of the agile community. This is despite the fact that the very idea of physically distributing teams seems to conflict with agile communication practices. Agile practices rely heavily on face-to-face communication as a replacement for lengthy and often tedious documentation; being geographically separated will, of course, interfere with face-to-face communication.
Risks and Rewards of Team Distribution
So if distributed teams are such an impediment to communication, why risk separating teams at all? There are certainly benefits to a distributed team and obviously these need to be weighed against the hindrances to communication. I’ve found that the top three reasons for distributing are:
- Expanding into global markets may require a local presence in the various locations.
- Access to global talent.
- Reducing cost through offshoring or outsourcing.
If the decision is made to distribute a team and sacrifice communication, we must take steps to make up for it in other ways, with one of the most common ways being to improve the management of requirements and specifications.
Good requirements and specification management does not take place in spreadsheets. You need to invest in a system that can offer your team a high degree of traceability and speed. Nothing slows the adoption of a tool faster than a lagging interface. Other nice features for you to look for in a system are change management and base lining, notes and events, and a robust suite of reports.
Let’s take a look at Jerry, a product owner at Texas Toasters. Jerry wants to add email functionality to his company’s flagship product, a toaster. It’s important to note that Jerry works on a small, co-located agile team and that the stakeholders have already approved his email feature. All Jerry has to do is create a user story, which can then be scheduled for the next development cycle. The user story may look something like, “As a maker of toast, I want the ability to send myself an email when my toast is done toasting.”
Simple right? Keep in mind all those little technical details like where you configure your email address and SMTP settings, the decision as to allow for multiple recipients, and what will be the email’s content. In Jerry’s case, it’s pretty simple to sort these details out. Whoever ends up developing the feature can just walk over to Jerry’s desk and partake in quick brainstorming sessions on the best implementation method. Once the implementation details are sorted out, the developer will document them according to company standards.
What happens when this same scenario takes place with Jessica, a product owner, at Global Toaster Corp? Since Global Toaster Corp is the world’s largest manufacturer of cutting-edge toasters, there is a bit more work involved when adding a feature like email. Once the feature is approved, Jessica still creates a user story that might go something like this: “As a maker of toast I want the ability to send myself an email when my toast is done toasting.” This story, however, will have to be implemented by the development teams that happen to be in Madagascar, Uzbekistan, and Fiji. Since Jessica works in the Wichita office, quick face-to-face brain storming sessions are not feasible. Also, because of the time differences, any gaps in information will tend to cost more since they will take longer to catch. Time is money after all.