Agile Project Planning

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

Wednesday, May 23, 2007

Agile Variations for Distributed Software Teams

So you've read the latest article or book on Agile methods, and go forth eagerly to implement them in your organization.

One little problem: your team is distributed, but all of the books you've read mention something about "co-location". That's another word for "together", meaning everyone on the project is in the same place: customers, developers, product owners, testers, documenters, and even those guys who make boxes to put software in if you like that sort of thing.

What's an aspiring Agilist to do when the team isn't together?

First off, let's define "not together". There are three main types of distributed teams, each with its own unique challenges:

1. Type A: All developers are together, all customers are remote
2. Type B: Multiple development teams in different locations (but each team is together)
3. Type C: "Virtual" team where nearly everyone works remotely (e.g. from home, in various offices, etc.)

OK, now that we understand the different types, let's look at the challenges each one has, and how we can tackle them.

Type A projects (all developers together, remote customer) generally have to be aware of getting out of touch with the customer. Out of sight can mean out of mind. This is especially true on an outsourced project, where the customer might only be interested in talking once a month or so.

The biggest risk for Type A projects is that the team starts making major decisions without input from the customer, which can lead to software that is not aligned with the customer's needs. Going back to basic Agile principles, we decide that freqeuent communication is the best way to deal with this. A daily meeting to quickly disucss progress, obstacles, and goals for the day might be just the ticket.

But having a daily call might not be enough. How do we handle those little decisions that need to be made all day long? If you're building a blogging system and the customer asks for a way to schedule new posts for the future, did they want them to autopublish or just have a reminder sent? A remote team might build in support for both, just in case. An Agile team needs to ask the question, and only build what is needed for now, not waste the customer's money on a guess. So alternative communications channels become important. Instant messaging clients, email, and message boards can be good informal channels for extra communication throughout the day if phone calls aren't feasible.

On to Type B projects (multiple dev teams in different locations). Here, the main issue is that each team may be highly functionial, but may have trouble communicating well with the other development teams. An example would be an in house IT team working with an outsource vendor. Again, frequent communication is important, as with Type A projects, but there is usually something very simple that can dramatically improve working relationships. Ready for it?

Type B teams should all meet in person at the beginning of the project. As in physical proximity, having a beer or soda together, chatting about hobbies, technology, or which breed of cat is superior.

Why is a face to face so important? Without it, human nature drives us to an "us versus them" mentality, also known as "those guys in Nebraska screwed up again" (I have no direct knowledge of any Nebraskan development disasters, this is just an example.)

Type B teams should also consider rotating a member of each team to spend time with another team on a monthly basis. Cross-pollination doesn't just work for bees, it can improve human endeavors as well.

On to Type C teams - the new "virtual workforce" we've been hearing about. Unlike the first two types, these folks never see anybody. This turns out to be strangely beneficial. Because everyone is on the same level, these individuals are either lonely and isolated, or pretty happy with their arrangement. We can influence the outcome towards the latter by setting up frequent communication and having an initial in-person meeting as with the first two types. Virtual teams can suffer from poor quality of communication though, and may need to supplement with group collaboration tools like shared whiteboards to supplement daily calls, emails, IM, etc.

For Agile afficionados enamored with pair programming (developers working on a task together), it's possible to setup virtual desktop and keyboard sharing (using VNC or similar software) along with an Internet phone line (e.g. Skype) to do this. Some folks acutally prefer the physical separation so that the after-effects of Joe's garlic pizza binge from the night before aren't quite so...awakening.

Having a "virtual water cooler" like a chat room can also help provide informal channels for team cohesion and bonding that can make a big difference in the final outcome of a project.

Overall, distributed teams aren't an ideal way to work, but given their reality, we can apply Agile principles to work effectively. Perhaps not as effectively as with a co-located team, but isn't the goal to do the best we can with what we've got?

How's your distributed team bridging the gap?

Labels: , ,

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

3 Comments:

  • With Type A projects, how can you deal with the customer being in a time zone where there is essentially zero overlap in business hours?

    By Blogger Andrew, at 3:57 PM  

  • Hi Andrew,

    That's a tough problem, and there's no easy answer. A few ideas though:

    - Embed a member of the dev team onsite with the customer, especially early on in the project. This can really help with communication, and the dev can get a deep understanding while onsite. You could also rotate who is onsite once a month or so. If finances are a problem, then maybe just a monthly or quarterly trip for a few days. Alternatively, the customer could do the same - send a representative to your dev site who has the authority to make key decisions.

    - For day to day communication in a non-overlapping timezone, you could try a discussion forum that questions get posted to, and customers can all see and respond to when they have a chance. This can help reduce redundant questions, and allow input or corrections from multiple people.

    - Finally, you might try a weekly meeting on the edge of each timezone: maybe the dev team stays a little late or comes in a little early (or even calls in from home) to have a teleconference with customers to discuss important issues or decisions.

    One last point: having a clear vision for a project can help empower the development team to make good default decisions on small issues when the customer isn't available. For example, knowing that it's critical that the product be as easy to use as possible might steer you away from cluttering the interface, adding too many choices and options, etc. Try to get a clear vision from the customer, and make sure everyone on the team gets it.

    By Blogger David Churchville, at 4:30 PM  

  • Hi David,

    Thanks for the feedback! I'm on the customer end of such a relationship, and your ideas have triggered some thoughts. In essence, we really need to redefine our relationship with the supplier, and to open up the communications bandwidth.

    By Blogger Andrew, at 10:06 PM  

Post a Comment

Links to this post:

Create a Link

<< Home