Tips for Improving Your Geographically Distributed Agile Team

At the Better Software/Agile Development conference a couple of weeks ago, I gave a talk entitled At Least Five Tips for Improving Your Geographically Distributed Agile Team. (That link goes to the slideshare.)

If you look at Scott Ambler's 2011 survey, you can see that his data matches my consulting experience. About half of all agile teams have at least one person not co-located. This is by management design.

We can say, “don't do this,” but that's not helpful to the distributed and dispersed teams. I would rather be helpful.

For example, in my talk, not the slideshare, I actually said, “Don't do standups. Do handoffs.” If you are more than about 4 or 5 hours apart in timezones, standups make little sense. You are better off limiting WIP (with a kanban board) than using straight Scrum. Yes, use iterations if you like. You might like the focus of the timebox. But, consider using handoffs, not standups. Change your questions to statements—if that works for you. Change your deliverables to fit your needs.

One tip that created a ton of discussion was the one about keeping people together over time. Some managers are trying to be “efficient” about using team members, optimizing at the lowest possible level. They move people off and on teams, willy-nilly. (Groan.) I explained that agile is about finishing features, so their best bet was to optimize at the project level, or the project portfolio level. It didn't matter if people weren't fully utilized. People were best utilized when they asked, “How can I help move this feature across the board?” In a geographically distributed team, that is sometimes a difficult question to answer, especially if the testers are east of the developers.

I had stories, and we had audience participation, which is why the slides are sparse. I hope you enjoy the slideshare. If you have questions, please ask away in the comments. I will answer.

8 Replies to “Tips for Improving Your Geographically Distributed Agile Team”

    1. Yves, I agree with you. I especially like the fact that your picture of your board has stickies.

      When I teach new-to-agile distributed teams, I suggest they start with cards or stickies, because otherwise the tools manipulate their process and culture. That’s the wrong way. The team needs to create its own culture and process, not the tool.

  1. Pingback: Working with remote team members | DevOps Blog | NewVoiceMedia
    1. Vitaliy, the demo has tasks, not user stories. Based on that, I would not recommend your app.

      I am a fan of user stories, not tasks. Especially for distributed teams. The team has to know why they are doing this work, and who the value is for.

      1. Johanna, in the end it does not mater what to estimate – a task or a story, this is just a card, that represents an item that needs to be estimated. It doesn’t mater what you estimate – your effort, complexity or the height of a building, right? 🙂

        Thanks for your reply

  2. mm for distributed teams, what works best of for me, is work that is totally independent from each other. in that could be tasks or stories.
    yet just as Johanna, I never estimates tasks. that is too much overhead.
    Actually I’m more and more in favor of counting the tasks we do as an estimation. and making sure we add all the possible tasks.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.