Today, application development frequently consists of multiple teams, located across the globe, collaborating on a software project. Alex Perec describes how to make teams more productive and efficient without hindering their natural workflow.
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.
To avoid unnecessary delays, Jessica must fill in as many details as possible, make sure stakeholders approve of those details, and then go back-and-forth with the development teams (probably via email or phone conversation) to fill in any gaps. The more details she can add, the better. Things like GUI mockups, pictures, and acceptance criteria tend to go a long way in a situation like this.
Short user stories work because they are supplemented by face-to-face conversations. If these conversations are no longer going to be taking place, we need to add more detail to our specifications and task descriptions. Additionally, it’s important to use a system that ensures linking and enforcing a proper workflow as specifications are turned into development tasks that are eventually tested. This can be extremely useful in ensuring that miscommunications do not lead to work having to constantly be redone. It’s also very important because few things will demoralize a team faster than constantly redoing the same work.
Conway's Law states that any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure. Conway's law is based on the observation that in order for two separate software modules to interface correctly, the designers and implementers of each module must communicate with each other. Thus, the interface structure of a software system will reflect the social structure of the organization that produced it. In the case of an organization with distributed teams, work will naturally be divided up according to the distribution of its developers. Doing so results in an architecture that reflects the distribution or has artifacts that specially accommodate the distribution. Even if this design is not the best from a performance and scalability perspective, it is often then most convenient.
Regarding Jessica, let’s assume that all the requirements and specifications for the email feature have been approved and delivered to the development teams. The original story has now been broken up into three separate user stories that will be developed simultaneously to save time. The Fiji team will develop according to this user story: “As a maker of toast, I want the ability to configure SMTP settings on my toaster.” On the other hand, the Madagascar team will develop according to a different user story that states this: “As a maker of toast I want the ability to configure email groups based on the type of bread toasted.” Finally, the Uzbekistan team will develop based on this user story: “As a toaster I want to send a message to trigger an email when the bread is done toasting.”
Although each team develops its feature as specified in the respective user story, when it comes time to put all the pieces together, we find a problem. Uzbekistan has only coded one message for when the bread is done toasting, but Madagascar was expecting different messages specifying the type of bread. This, of course, leads to delays while the message details are sorted out by both teams. These delays are exacerbated by time zone differences and the fact that each team is unfamiliar with any other teams’ code. Many of these problems could have been avoided if the teams had created stories based on vertical slices through the architecture or if they had considered all the user stories as opposed to just focusing on those assigned to them.
This rather simplistic example illustrates how a distributed architecture can create knowledge silos and cause each team to think in terms of completing work on their piece of the puzzle rather than focusing on the user stories as a whole. Development efforts need to focus on all the user stories since they summarize what the customer needs. The customer does not care about orchestrating a design to effectively accommodate a team's geographic distribution.
Effectively distributing agile teams is about minimizing the impact of distribution; the emphasis here is on the minimization. Clearly there is no substitute for teams having face-to-face discussions with a whiteboard or two programmers sitting together working on a piece of code. All we can do is take steps to improve the communication of our distributed teams.
Give Your Team the Means to Succeed
The decision to distribute teams needs to be coupled with the commitment to provide teams with the tools they need to maximize communication. It’s to be expected that it will take them some time to optimize the workflows and communication processes around the teams.
Although tools are not the primary focus of agile teams, when selected properly they can certainly make teams more effective and efficient provided they are flexible and do not hinder a team's natural workflow. Distributed agile teams may not be able to rely on sticky notes, task boards, or burndown charts on a wall for project tracking. They require a robust system for sharing these items and metrics across multiple locations. Choose a tool with good performance across geographically distributed environments. Slowdowns during simple tasks will cause frustrations that team members will seek to alleviate by cutting corners.
Conclusion
Distributed agile development makes it possible to tap into new global markets and obtain access to global talent while potentially reducing costs. Be sure to understand the risks and rewards of team distribution before making the decision to proceed. One of the key factors for a successful agile project is the high level of communication between team members. If your team is distributed, it must make deliberate efforts to replace as much of the lost communication bandwidth with augmented processes and practices.
Bring teams together as often as possible, especially during pivotal points during projects. Use the points in time when the whole team is together to nurture trust and strengthen working relationships. Agile development is difficult and requires a great deal of discipline, even more so when teams are distributed. Make sure you have someone with a clear mandate to coach your teams and ensure they stay on track with communication practices.
Agile teams work on user stories, not component features or implementation tasks. Organizing your team's work and distribution by component or discipline will make it extremely difficult to focus on what matters—that is, the stakeholders and their stories. Provide distributed teams with tools that will help them fulfill these user stories and work as effectively as possible with as few barriers to the distribution process as possible. Favor integrated systems that offer full traceability from specification design through development and testing. Finally, consider an integrated wiki linked to tasks and stories to store notes from various design meetings and impromptu conversions.
