Agile Project Planning

ExtremePlanner: Agile Project Management for Distributed Software Teams
Click For Your Free Online Trial

Wednesday, November 16, 2005

Agile Project Management for Distributed Teams

There seems to be a growing trend towards distributed teams. Developers work at one location, and customers do business at another. Or testers are outsourced, working with developers and customers in another timezone. Sometimes even the development team is virtual, with different team members working remotely.

Whether this will continue or not remains to be seen, but with the strong focus on people and communication that Agile techniques encourage, dealing with remote teams can create a bit of a challenge.

So what works well for distributed teams in an Agile setting? Can you use index cards, whiteboards, and big visible charts to communicate? What about daily standup meetings?

In my own experience trying to use agile methods in this kind of environment, a few tweaks were in order. Here are a few things that worked for me:

  • We needed a little more documentation than when the team was co-located. Functional specifications are a little more important when the customer is 3000 miles away. These can be as simple as a few screenshots or drawings with some commentary, and should be easy to read and understand. It's just a way to capture and remember the collective understanding of the team when you can't ask questions in real time.
  • We used a web-based planning tool to collaborate and provide visibility into project status across time zones and physical locations. Index cards are fine for teams in the same office space, but unless you're going to FedEx them back and forth, you'll need another way to share and update project information like user stories, detailed tasks and estimates, and other project artifacts. Customers can check in when they have a chance, if they want to see where their pet feature stands.
  • If you can't coordinate daily meetings due to scheduling or timezone issues, try at least a weekly update meeting, possibly using a Web conferencing software package like WebEx if you want to demonstrate features or do a walkthrough. In my experience, as much as we tried to involve remote customers by sending them draft documents or prototype software, the best results and feedback came from live walkthroughs of software, or even of documents for discussion.
  • Travel. There's nothing like face to face conversation, even if it's only once a quarter or twice a year. Plan for it, budget it, and do it. It's sometimes the difference between a distributed team, and a wide-area disaster.

If nothing else, Agile techniques are about adapting to change, even for the process itself. Distributed teams need a few more tools in the toolbox to work with Agile processes, but the same philosophies of rapid feedback, people over process, and close communication can still be practiced.

I'd love to hear about other experiences with distributed Agile teams, drop me a line (dave at extremeplanner dot com) or leave a comment.

For more on agile tools and techniques:

Get your copy of the new book! Agile Thinking: Leading Successful Software Project and Teams


Post a Comment

<< Home