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.