Distributed Agile Day to Day

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.
Communication is Key
For many readers, the following might be unbelievable: all communication is broadcast. When I sign on to IRC in the morning, everyone sees me. When I ask a question, anyone may answer.

When I check in code, my check-in is sent to an email list and to an IRC channel. If my test fails, the failure is sent to IRC and to a public wiki page. If a story test passes, the wiki page is updated. If a story test fails, the wiki page is updated, and I file a bug in Bugzilla. If I file a bug in Bugzilla, that shows up on the wiki page, on IRC, and in email. Every update to a story page for the iteration automatically updates the wiki page for the iteration itself.

I only have two kinds of one-to-one communication: communication irrelevant to work and communication that might be an HR issue.

We have a few mottos regarding such circumstances, beyond simple common decency:

Say What You Mean; Assume Good Intent. We recognize that bandwidth is very limited, and we choose not to play politics. We are blunt to the point of rudeness sometimes, but we have to assume that the people we address will understand our point and not be offended at our tone.

Disagree, but Commit. Make your best case, but if your idea is overruled in favor of something you don't like, work to bring about the best possible outcome anyway.

Patching Holes
If you hire the brightest people you can find regardless of geography, you are allowed to treat communication as an engineering problem, not a social issue. When you discover that someone is not informed, you find a way to make him informed. When you discover that information has gone missing, you find a way to recover and preserve that information. Fixing the problem is often less important than making certain that everyone know how the problem was fixed.

Indications and Counter Indications
Many of the values of distributed agile teams are shared by contributors to open source projects. Both groups are familiar with working in public and sharing every aspect of the work.

One important case of remote work on agile teams I have encountered numerous times bears mentioning: the case of a single remote worker on an otherwise collocated team. In my experience, this arrangement works only when the single remote worker had been a member of the team for an extended period before moving away and continuing his role in the team. The situation where an agile organization hires a remote worker because of a particular skill and attempts to make him part of a collocated team tends to fail in my experience.

Where the Rubber Meets the Road
I am convinced that distributed agile teams will be critical to the success of business in the future. I am also convinced that the Agile Manifesto is a document that will continue to survive every test to which it is put. It is worth reading again and again.

The triad of XP practices is essential: pair programming, TDD, and CI. All of these make it possible for a smart, small team to accomplish immense achievements in software. Certain aspects of the practice (like Selenium tests) are expanding beyond the original descriptions of XP, but I think that is a good direction to go.

I am not so convinced about Scrum. Scrum is a great place to start. But one of the best things mandated by Scrum is periodic retrospectives for the purpose of refining the team's software development practice. Given a bright, involved team, effective retrospectives likely will have dissolved the canonical Scrum practices after a year or so. And after two years (or three, or four, or five), some distributed agile teams should be publishing management practices of their own.