Distributed Agile Day to Day

"Distributed" isn't a word that always has appeared favorably in works about agile methodology. After all, the proximity of agile team members while working is highly regarded. In this article, an excerpt of which originally appeared in the May 2009 Iterations eNewsletter, Chris McMahon takes a look at how "agile" and "distributed" can work together successfully.

I have worked as a tester and QA person on a successful agile team distributed across the US and Canada for two years. This is a little description of how that works.

What Stays? What Goes?
Suppose we forget Scrum and forget XP. Forget war rooms, forget sharing hardware, and forget snacks on a common table.

Instead, suppose we want to hire the brightest, most capable, interested, well-informed technical staff we can find, regardless of where they live. Suppose that such a team not only succeeds, but thrives. How much of Scrum gets abandoned? How much of XP gets abandoned? How much of the Agile Manifesto gets abandoned?

I have worked under these circumstances for the past three years. The answers, in order, are: a lot, not much, and nothing. Scrum has some good ideas to start you out. XP practices are pretty critical on a distributed team. And the Agile Manifesto remains a remarkably astute document to this day.

Scrum and Management
Iterations are important. To commit to releasing running, tested features at a specified time is critically important. My team tried a kanban-like system for some time, but the lack of release planning was detrimental.

On a typical agile team sharing a single workspace, daily standup meetings take seconds to organize and proceed quickly. Not so for a distributed team. Any meeting takes minutes to organize, and participants will likely have to schedule time for unusual help or pairing requests.

My team has standup-like meetings three times a week. These typically last thirty minutes or less. We start with the state of the current iteration (on track or not) and the previous iteration that might be in play, and then proceed with the typical person-by-person status. We bring to light tricky problems, illuminate tricky bugs, and point to unhealthy trends if necessary. Finally, we hear from our development manager any concerns from other corners of company management.

We do not do this daily because we have at our disposal a number of important real-time communication tools.

First and foremost of these is Internet Relay Chat (IRC). Instant messaging, Yammer, and Twitter are only pale imitations of what is possible on IRC. There is a role for such "Web 2.0" tools, but for flexible, hackable, real-time communication among technical staff, IRC is hard to beat.

Also, every story, story test, test result, and status report is kept up to date on a sophisticated wiki. When we start up the Voice over Internet Protocol client for the standup meeting, we all have read every wiki page pertaining to the current iteration.

Regardless of where we are in the iteration or what else is going on, I do four things every morning: sign in to IRC, check the wiki page dedicated to the current iteration, prepare for the day's meetings, and check the results of the automated GUI tests.

XP and Practice
As of this writing, my team maintains automated tests comprising more than 17,000 unit-level and integration-level assertions and almost 10,000 UI-level assertions about the product.

We do pair-programming. In practice, that usually means working on source code by connecting to a dev or test machine via SSH, starting a *nix screen() session, and having the programmers (dev or test) all connect to the screen session. We also update common wiki pages in this way during meetings using a sophisticated text editor for wiki pages. When we need a UI, we connect to a VM running an appropriate version of Windows and share the appropriate browser.

We do test-driven development (TDD). That's how we generated those 17,000 assertions about our code behavior. We care less about code coverage than we do about catching important problems before they get to production.

We do a couple types of continuous integration (CI). We don't use a standard CI tool. On the unit/integration side, we have changed our minds several times about the proper way to run technology-facing tests, so we have always had a custom test runner. On the UI side, we are a Web app, so we have a custom keyword-driven framework wrapped around Selenium. The full suite of unit/integration tests takes minutes to run, and we run it for every build. The full suite of UI tests takes about two hours to run, and we run it continuously from a test runner written in Ruby that makes full use of our internal tools as well as our powerful public API. Since we sell systems based on wikis, our test data resides in wiki pages that are managed under source control.

AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.