How Agile Principles Make Distributed Software Development Better
by Vin D'Amico, @BrainsLink
Distributed software development is difficult to do well. Anyone who has tried it can attest to that.
If you're building a large software system composed of two or more subsystems, you can assemble development teams in multiple locations and divide the work along subsystem boundaries. There will be synchronization and integration issues but those will exist even if the teams are co-located.
If members of a small team are spread across multiple sites, you face a more complex problem. 
As the team is spread farther and wider, time, language and culture differences become progressively greater challenges. Just because your core team is based in the USA, England or Germany, doesn't mean that people in other remote locations have to conform to your norms.
There are no simple solutions but agile development techniques can help in either circumstance. Most companies fall back on contracts, detailed specifications, and paper trails to govern distributed software development. There's no empirical evidence supporting that approach. There's a better way. First, let's examine the challenges faced by distributed software development teams.
The Waterfall Development Challenges
Waterfall software development relies on extensive documentation. Sending large documents to people whose native language is not the same as the author's is a key failure point. Subtle differences in interpretation of the words and phrases often result in major software defects.
Waterfall's reliance on system integration testing and QA testing late in the effort after much of the software development is completed is another failure point. By the time defects are identified, developers have moved on to something else (or somewhere else). Even simple issues then become hard to identify and fix.
The Agile Development Challenges
Agile software development relies on frequent information exchanges. Ideally, developers sit near one another so issues can be raised in person and resolved almost immediately. Distance and time make such exchanges difficult, if not unreasonable.
Agile teams like to setup physical status boards and conduct daily standup meetings around them as a way to exchange information and track deliverables. Who maintains the status board when teams are distributed? What time of day will the daily meetings take place? There are no easy answers.
Go Back to Agile Manifesto Principles
There are four principles forming the core of agile development as defined in the Agile Manifesto and two of them help address the above challenges:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
Doing distributed software development well requires satisfying all four principles and the first two are most challenging. We need to find a way for the teams to communicate and collaborate. We need to see and touch working software as the only reliable means of measuring progress.
(Note: Customer collaboration should not present any new challenges for distributed teams. In fact, distributed teams may find it easier to work directly with customers or clients because they can be wherever the customers are. Similarly, responding to change should not be any more difficult for distributed teams, as long as changes are communicated quickly and clearly.)
There is no standard approach to building software systems in a distributed environment. Here are a few options:
1. Architect the software system as a set of components or building blocks. Define the components such that they are highly cohesive and loosely coupled. Assign a component to each team and hold them accountable for delivering it.
This approach is not agile because it seeks to limit interactions. It also introduces a variety of synchronization problems. Each component may work well in isolation but they may not work well together. This is a legacy approach to software development and is not recommended.
2. Use a standard design pattern such as model-view-controller and assign a subsystem to each team. You may have a UX team, a database team, a business rules team, etc.
This isn't agile either because it encourages specialization. It's slightly better than option 1 but still struggles with synchronization issues. The interfaces among client systems and server systems may be complex though some of this can be mitigated by using an application framework like Spring.
3. Define stories in such a way that they can be collected into sets and assigned to a particular development team as a set. This essentially means building multiple backlogs, one for each distributed team.
This is closer to true agile software development. For large projects, this approach makes sense. Big systems with multiple subsystems need to be broken down into subprojects. However, there is an anti-pattern that often occurs. If the stories are defined in an overly restrictive way, this approach regresses to #1 or #2. Remember, stories should be vertical slices through the entire system wherever possible, not horizontal blocks of functions.
4. Ignore team distribution and simply approach the project as if the entire team is co-located.
This is clearly the most agile approach though communication and collaboration will be major challenges. There will be a common set of backlogs (product, release, sprint) and every team will draw from the current sprint backlog. In the interest of being the best we can be, let's see what it takes to make this work.
The Status Board
A single physical status board (e.g. Scrum or Kanban board) will not work. Anyone not co-located will be unable to update it. If the project is big enough to require multiple status boards, they will need to be consolidated at some level to get the big picture state of the project.
Instead, make the investment in an electronic status board. There are many choices available, both as services and as downloadable software. Either way, everyone can access and update the status board at any time. During the daily standups, the board can be projected onto the wall for everyone to see and discuss.
Beyond Email
Email will not be good enough to keep everyone updated and informed. There's too much email and it's too easy for items to get lost or be ignored.
Find good collaboration tools. You'll need some form of instant messaging for quick conversations -- preferably one that can accommodate online meetings and archive the conversations. A private Twitter-like tool such as Salesforce.com’s Chatter or Yammer will also help. People will be able to subscribe to information channels and stay up to date with what's happening on the project. Also invest in video conferencing. Even if you only use inexpensive webcams, the advantages of (virtual) face to face communication cannot be over
stated.
Short Sprints
Keep your sprints or iterations short. 1-2 weeks is best though you can go up to 4 weeks if you must. These frequent checkpoints will show whether or not the teams and the individual developers are in sync.
Don't simply ask people if the understand what is needed or have any questions. Get them to deliver working software based on a common definition of done. Ask the stakeholders and end users to critique new software features and respond via email. Get everyone engaged.
Meet as Often as Needed
Daily standup meetings are difficult to plan when many hours separate the team(s). You'll need to be creative. Some people won't mind meeting at unusual times like 8:00PM or 6:00AM. Others will find it highly objectionable but may be unwilling to complain.
Is there something you can offer those who are severely inconvenienced in exchange for accepting the odd meeting time? You could try holding meetings at different times of day so as to spread the inconvenience around but that often creates confusion.
Don't be bound by dogma. Do you need to meet daily? If communication is good and occurs often, meeting 1, 2 or 3 times per week might be good enough. Also consider that if sprints are only 1 week long, daily meetings might not be needed at all.
Nothing will make distributed software development easy but there are advantages to it that may be impossible to ignore. Abandon what I'll call the classic contractual commitment approach where every detail is written down, signed-off and approved in advance. Instead, adopt agile principles. Let the team and the software lead the way.
brainslink.com
