Software development organizations have evolved to meet the challenges put forth by ever increasing complexity in both the problem spaces and the technologies applied. Unfortunately, the right people for a project may not all be located in the same city or at the same time. The skill, experience, and ethics of personnel have risen to the top of our list of essential factors when assembling teams. Our search for optimal teams has gone global and we need to find ways to work together in the face of these new challenges. At Band XI, we have adopted and adapted agile methods to make high-performing distributed agile development teams a reality.

A Short Story
Over the past twelve years, I have engaged in agile development practices with a twist - working remotely from a home office. Given the proscribed strictures of such agile practices as extreme programming and daily scrums, this would seem to be an outrageous claim. One assumes that a distributed team cannot perform in an agile manner. Yet, I would argue that only agile methods can be adapted for successful distributed teams. A couple of years ago, I assembled a team that had no more than three team members in any single location, and was globally distributed in Seoul, Turin, Toulouse, Hartford, Phoenix, Grand Rapids, and Raleigh. We employed a loose collection of agile practices, scheduled periodic face-to-face meetings and successfully delivered the project.

Early in 2004, we had written a proposal to construct an embedded Java reference implementation for an automotive telematics (vehicle based information systems) {sidebar id=1} client located overseas. Although we expected the decision to be made within sixty days, it was actually six months before the proposal was accepted and the project initiated. In the interim, some of the key people we expected to work on the project had engaged on other projects and we needed to find comparably skilled folks. Choosing to have people with the right skills and experience took precedence over simply choosing people because of where they were located. As a result, we had a team that spanned the globe. Fortunately, the team members had all worked together in various combinations on prior projects.

We punctuated our work effort with monthly weeklong workshops where we would all gather together. The effort was book ended with kickoff and closing workshops, but the interim workshops addressed critical technical risk items and enabled the team to spend some time together after hours in a social setting. The most effective teams demonstrated a capability to both work hard and play hard together. That provided a solid foundation for the relationships that could enable effective and candid communication. Everyone on the team had significant practical experience with the tooling and technologies that we used, as well as the pace and style of working in a continual release mode.  Below, I briefly outline the key elements that enabled us to successfully work as a team, even as we were distributed across continents and time zones.

Enabling Technologies
As a small company, we love free software. Therefore, we look to the open source community to find tools that help us communicate and work better together.  We are happy to use the lowest tech option that works. We leverage the pre-existing electronic social interaction skills with which most software developers already exhibit great facility - email, instant messaging, voice over IP, and code itself.

Integrated Tooling: Using a fully integrated tooling platform, such as Eclipse, for our Java development enables us to share work artifacts quickly and easily through online CVS and Subversion repositories. Incremental development and continuous synchronization keep the changes manageable.  For the most part, we let our code speak for itself, but some level of documentation is always essential for communicating concepts and intent.  We create special resource projects to contain our design snapshots, planning and use case documents.

Managed Workflow: Bugzilla is a more than adequate mechanism for defining, tracking, and recording development task progress. Standard project management tooling is overly complex and not targeted at group accessibility for the kind of agile development we typically do. Instead, we use Bugzilla for tracking the status of work items by bookmarking a few common queries against the database. With a bit more time and effort, we could fairly easily generate a nice project dashboard for all to view the current status of the project.

Idea Sharing: By using a free form Wiki for logging and discussing ideas asynchronously, we don't need to have meetings for brainstorming. One person can write up a brief summary and some bullet points on an idea for others to read, comment, and enhance. Being distributed across time zones, this is a nice way for us to capture and share information and ideas. As the wiki page content matures, these ideas are often converted into backlog work items that can be entered into Bugzilla.

Constant Communication: We maintain near continuous communication, not only using telephone and email, but also heavy use of Skype for online chat sessions, both one-on-one and multi-user. We live in an age where most of us - certainly the younger generation - have grown up with instant messaging (IM) technology as second nature. Using IM provides very convenient mechanisms for providing quick informal updates, for asking brief questions to gauge status, or for obtaining indications of whether someone is struggling.

Continuous Builds: We have set up an Anthill server to regularly pull out the committed code and run the build scripts. A quick glance at the web page tells us the status of the build, including acceptance test and code coverage results. Additionally, the system generates emails when the build is broken.  Upon notification, the team takes corrective follow-up actions as necessary.

Shared Desktops: Even though we are remotely distributed, the need to pair program still arises regularly. Some problems are best solved with two heads thinking about them and discussing them. Also, the fastest and easiest way to pick up something new is to have a peer walk you through an example. For these situations, we have been satisfied with Microsoft NetMeeting, even after all these years. It provides for basic desktop and cursor control sharing, which is usually adequate for the task. Used in conjunction with the audio capabilities of NetMeeting or Skype, we can effectively simulate real pair programming.

Effective, Light Processes
Processes provide a degree of utility that enable some predictability for the work effort. However, beware that these processes do not become ends in themselves. The process must remain the means to the end, which is delivering working software and systems.

For requirements gathering, architecture discussion, and design sessions our tooling consists of whiteboards, flip charts, markers, and a digital camera. During the workshops, we collaboratively sketch out our scenarios on a whiteboard, annotate them as necessary, snap a digital picture, and dump it in the online repository for reference. No fancy UML diagramming or code generation tooling. Clean designs can be communicated with minimal syntactical sugar, simple diagrams, and explained through direct usage scenarios.

We have also found that the core elements of Scrum are perfect for the kind of distributed teams we have assembled. With an agreed upon backlog of work items within our Bugzilla database, regular one or two week sprints, and daily online chat scrums, we do what we can as a self organizing team to burn down the work items.

We also employ test-driven development by beginning each new feature as an executable use case, a JUnit-driven acceptance test that uses mock objects and automated scripting to test the core business logic. All test cases, whether acceptance or technical tests, are invoked from automated Ant scripts run under Anthill at build time. We also run these tests under the Emma code coverage tooling to verify that we are indeed testing all that we ship.

The Future of Software Development Organizations?
Over the past year, our company has operated in the same manner as the previously mentioned project. Although we are not currently distributed across the globe, we do cover all the time zones in the United States. We have successfully employed the same technologies and practices to develop Cyrano, a remote sensor fusion system for hazardous materials detection and situational awareness management, in partnership with the US Army's National Automotive Center.

Our success comes from building strong relationships, engaging in candid communication, employing sharing technologies, managing work in short small bursts, and by architecting solutions based on shared programming models. Our processes and documentation are extremely lightweight, but our high value and dense communication content and rapid cycle times provide concrete results. We emphasize the reuse of concepts and conventions, rather than code and frameworks. We punctuate our projects with intensive face-to-face workshops and follow that up with daily interactions over electronic media. As the world continues to flatten and the individual becomes more empowered, this is the future of software development companies that value people and results over processes and interim artifacts.

About the Author
John Cunningham, co-founder of Band XI International, has practiced agile since his early Smalltalk days with Andersen Consulting, CSC, Travelers, and Object Technology International.  While with IBM, he led customer engagement teams applying agile to the embedded Java space. Mr. Cunningham holds the following degrees: BS in Mechanical Engineering (Columbia University), MS in Mechanical Engineering (University of Massachusetts at Amherst), and an MBA in Finance (University of Connecticut).