Test First, Test Driven Development and Distributed Agile

The more I deal with severely distributed teams (long way from Vancouver to Siberia!) the more I have come to view Test First and Test Driven Design/Development as a must for success. It is an uncontested fact that the lack of co-location is the largest downside to a distributed agile team, you can view the communication link within an agile team as a water system.

For a co-located team, the communication is a vast pool of knowledge that everyone can dip into whenever they please. As soon as you divide the team up, even if it is from one room to another, you need to put a pipe in place between these pools. The further apart you place the teams, the narrower the pipe becomes.

Now one needs to ask, how best can we fill this pipe? Are there any ways we can shore up the pipe with other means of communication. This is where I see Test First, TDD, executable requirements, Fit, whatever you want to call it but activities that help the team communicate the requirements and validate that the design and development underway meets those requirements without the constant need to fill up the pipe with clarifying questions.

Now pardon my belaboured use of the plumbing analogy (can't help it, I am an engineer!) but after an initial flood of communication clarifying tests and requirements at the beginning of the sprint/iteration/whatever (we need to start to have a unified language for these things ... a blog post for another time), these agreed upon, well understood, and continuously executed tests leave the pipe free to be used to communicate about creative problem solving and more truly profound questions about requirements, not questions like "should the discount be applied AT $50 dollars or AFTER $50".

Distributed Agile

The question was asked on Linked In on how companies handle Agile development in distributed environment with outsourcing vendors. While team co-location is an ideal (I would say the easiest) environment for Agile development, it is not an option for many companies. Even if you do not outsource, chances are that your development team is spread out between multiple locations. Acquisitions are way too common in high-tech.

So if we have no say in a team’s location, the question really is: which is better - distributed Agile or distributed waterfall?

Personally, I got the answer to this question after implementing Agile a couple of years ago with development teams in Vancouver and Boston. It worked much better than the plan-driven approach we have used in the past.

You do need to modify some Agile practices, of course, by moving Agile process artifacts from their physical environment (white boards, sticky notes, …) to an online one. I used Microsoft SharePoint at that time. You can also look at commercial tools from Rally or Version 1. The way you communicate will change as well, as you supplement face to face meetings with IM, VOIP, videoconferencing, and wikis.

Agile techniques actually help you to address and mitigate the usual challenges of a distributed / off-shored project: lack of visibility on project status, delay in feedback cycle, loss of business and technical contexts, decrease in communication bandwidth, higher documentation overhead, and mistrust.

Short iterations, with a product demo and retrospective at the end, increase visibility of the project status and provide instant feedback as well as an opportunity for process adjustment. Customer involvement facilitates both a shared understanding of business context and communication between business people and the development teams.

Frequent team meetings help to build trust and improve communication on all levels and across different groups. Continuous test and integration cycles tell you where you are in the project.

Functional Test Driven Development helps in removing ambiguity from requirements and clearly communicating them to distributed teams. Fit (Framework for Integrated Testing) is a great open source tool that we are using (http://fit.c2.com/).

In my current company, Luxoft Canada, we successfully use Distributed Agile in a number of projects with teams located in the US, Canada, and Russia.

If you want to learn more about Distributed Agile read the book by Dean Leffingwell: “Scaling Software Agility, best practices for large enterprises”. Dean is a well known name in the s/w industry and was in charge of developing RUP at Rational Software.

He writes that “at scale, all agile development is distributed development. … even the largest or most distributed teams can achieve the faster time to market, higher productivity, and higher team morale that the agile methods provide.”

In the book Dean describes a case study of a Denver company called Ping Identity that is using SCRUM with Luxoft’s team in Moscow.

Agile is getting further acceptance in world of outsourcing and this trend is going to continue. Watch for new tools and techniques that are emerging to make it easier and more efficient.