small world

Agile Development With Distributed Teams – 5 Lessons Learned

Agile Development

The widespread adoption of Agile development techniques have been among the most impactful changes in the world of software development in the last 10 years. While there have been lots of new tools and languages I’ve long thought that the biggest gains to be had in terms of efficiency and quality were to be had in helping the people involved in software development learn faster, and communicate better.

Distributed Teams

Another trend that has become commonplace in software development is the use of distributed teams. There are a variety of reasons teams are split up geographically. It could be tele-commuting, a work-from-home policy, use of offshore development talent, or working as part of a company that has grown through acquisition and now finds themselves managing multiple locations. Many of these scenarios are a part of most development teams in 2014.

Agile Distributed Teams – An Unlikely Pairing?

At first glance these two trends seem at odds. I mean the very first value in the Agile Manifesto is:

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. 529cc1ed 5bdb 4834 a06b 281450ecb391

1. Continuous Integration

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.

2. Travel

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.

3. Knowledge Sharing

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.

4. Requirements

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.

5. Collaboration Tools

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.

Putting it Together

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. d761fd08 ffc9 4ba1 bbed f818f1c3961b

Jamie Bolseth

Chief Operating Officer at Mentormate

Prior to joining MentorMate Jamie held leadership positions for commercial software companies such as Connexions Loyalty Travel Solutions, As One Technologies, and HighJump Software gaining experience in nearly every role related to the successful creation of commercial software. One constant in Jamie’s career has been leading distributed software development teams in several countries around the world. Jamie finds great reward in helping software teams reach their fullest potential through Agile Development methods and by fostering an environment where members are empowered to do their best work. Jamie is a Microsoft Certified Solution Developer (MCSD), Certified Scrum Master (CSM) and has a Bachelor of Science from the University of North Dakota.

0 replies

Leave a Reply

Want to join the discussion?
Feel free to contribute!

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code class="" title="" data-url=""> <del datetime=""> <em> <i> <q cite=""> <strike> <strong> <pre class="" title="" data-url=""> <span class="" title="" data-url="">