Individuals and interactions over processes and tools
The Agile Manifesto also goes on to state the following principle that more specifically addresses co-location of the development team:
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
So if face-to-face conversation is important in the practice of Agile software development, and development teams are increasingly becoming more and more distributed, then is “Distributed Agile Development” an oxymoron? No. The fact that Agile development and distributed development teams are both rapidly growing trends would indicate that they are compatible. However, there are some best practices that I’ve found help overcome the geographic barrier inherent in a distributed development team, while at the same time supporting the Agile principles that make it valuable. In no particular order, here are the 5 things I’ve found that help distributed Agile teams be consistently successful.Continuous Integration has been a best practice of high functioning product development teams for years. The benefits of keeping the source code in a continuously working state helps with efficiency and productivity. Continuous Integration is even more beneficial when team members are distributed geographically and may have different working hours due to time zones, such that they can’t always communicate in an ad hoc way to diagnose source code build problems or branching and merging issues. In short, great build discipline is efficient, especially when communication isn’t easy. I have found that in-person visits to work with distributed team members always provides me with insight that I could not have gotten any other way. Traveling to whatever location you choose to work with, and traveling there often, is a price you have to pay. For example, I once worked for a software product company that was going through a period of extreme growth. We decided to grow a team in Santiago, Chile to help us with our scalability challenges. We were about 6 months into the relationship before I decided to visit the team in Chile. The first thing I noticed upon arrival was a row of about 10 workstations where new developer candidates were watching training videos of our product. I didn’t even know these videos existed, and I came to find out that our partner had created a sort of “boot camp” to train new technologists. I quickly realized that our partner had become better at training people on our product than WE WERE! The partner’s greatest challenge was adding technical talent to the team, so they solved that problem. I immediately took the same training concept back to the US team and put it to work training our new developers as well. Travel not only helps solidify relationships, it is always enlightening. Software development is largely a social process. The most effective teams rely on accountability at an individual level and trust at an organizational level. While distributed teams can’t reside in the same physical space, it is very possible to create an online community with the goal of knowledge sharing. This collective community (however it’s created) promotes things like:
- Collective code ownership
- A culture of learning
- An expectation of accountability
- And an environment where interactions among team members happens voluntarily
Make it the team’s responsibility to find the most effective ways to share knowledge, and then support them.With any development team, one of the best ways to ensure an efficient development process is to drive the process with consistent and clear requirements. Agile principles encourage that you use “just enough” documentation (typically in the form of user stories) when it comes to requirements. Know that with distributed teams “just enough” might mean more documentation than just a simple user story to take the place of the face-to-face conversations that are possible with co-located teams. In addition to user stories I have found that focusing on high-value requirements such as User Experience, Story Boards, Wire Frames and Graphical Design often are an efficient way to tie many user stories together, while also conveying a lot of context that only seems to come with visual input. Think of this kind of work replacing what you might normally do on a whiteboard with a co-located team. Another valuable way to augment user stories is to include explicit test/acceptance criteria. This not only helps the developers understand how a feature is intended to be used, but also helps the test team tremendously. One thing that has greatly improved the productivity of distributed teams is the widespread use of good, reliable collaboration tools such as Skype, Google Hangouts, Microsoft Lync and others. Instant messaging has nearly replaced in-person collaboration (even when people are in the same office). Most collaboration tools now provide a visual status to indicate a user’s availability at a glance. And when working with teammates whose first language may not be English, often chatting is a more comfortable way to communicate. Another feature of most good collaboration tools is that they allow a natural “escalation of communication”. For example, what starts as a one-to-one chat, can evolve into a one-to-many chat, then a voice call, or a video call, then screen sharing, and even collaborative content composition. In many cases I find that geographically distributed development teams can be as productive, or even more productive, than co-located teams. Agile principles encourage focus and maturity on several critical aspects that otherwise add “friction” into the development process. When you add in geography, this focus is often magnified out of necessity. The teams simply don’t have the option to fall back on face-to-face interactions to remedy normal everyday challenges such as fixing a broken build, or asking for real time clarification on a requirement. Therefore the tendency is to invest in preventing these kinds of ad hoc challenges that add “friction” to the development process rather than just living with them.