Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

Our scrum teams are split geographically (not ideal I know!) due to specific knowledge only being available in certain countries. So one team of say 7 members, has the business person in one city, 2 devs in another, 2 other devs in another and 2 qa's in another.

Any suggestions for how to manage this type of graphically dispersed team? Any best practices?

How do you do standups? via skype video? do we ensure that people travel every 6 weeks (the half time of trust apparently)? how do we do the task board? Virtually or via video? would kanban work better in this setup?

share|improve this question

closed as too broad by gnat, MichaelT, Bart van Ingen Schenau, GlenH7, Yusubov Jul 31 '13 at 18:43

There are either too many possible answers, or good answers would be too long for this format. Please add details to narrow the answer set or to isolate an issue that can be answered in a few paragraphs.If this question can be reworded to fit the rules in the help center, please edit the question.

2  
possible duplicate of Advice/guidelines for managing a distributed development team –  Péter Török Aug 24 '11 at 17:56
2  
This is highly dependent on the geographic distribution. Saying that members are in different cities is not enough. More important is difference in time zones. –  Ladislav Mrnka Aug 24 '11 at 19:51
    
Agree with @Ladislav Mrnka. Pretty easy to work same/similar time zone. Toronto/NY for example. Much harder to work Toronto/Singapore. –  sdg Aug 26 '11 at 13:18
    
You've tagged with Scrum, but this doesnt seem to relate to your question. What do you do with Scrum? –  Dave Hillier Jul 31 '13 at 10:38
add comment

4 Answers

Our team had a similar situation, we had 2 developers that worked remotely, in different states.

For planning, we had an all day remote meeting with everyone in the team that could be together work together in the same room, then we would share desktops with the remote folks.

Our scrum wall was through Excel. We would break PBI's down together and then add them to the excel sheet. This process was pretty tedious and sometimes it would cause people to drift off. The hardest part was getting everyone's participation.

Our stand ups are getting everyone that can get together in a meeting room with a speaker phone, then sharing an excel based burn down sheet and everyone giving their update. This would also be put on a scrum wall in that meeting room for the larger group that was together. For the devs on the phone, we would place their tasks on the wall, but just have someone move them when they give updates.

There are virtual task boards that are available for purchase, so I encourage you to look at that. We had contractors from Avanade that had created one and licensed us to use it, we tried it but ultimately gave it up.

I hope this helps.

share|improve this answer
add comment

Try to have as much working time overlap as possible between the different sites. Delivery needs rapid communication.

Use GoogleDocs/Spreadsheet to share the offer template during release and sprint planning, allowing various teammembers to edit concurrently.

Desktop share using skype and use its video conference or Google+ hangouts. Use IRC or similar to allow for frequent comms from the entire team. Theme chatrooms for bugs, builds, impediments to help teammembers find the right place to help and get help.

Have a shared IssueTracker for tracking the sprints and releases - Jira.

Have online burndowns and information repositories that are kept up to date, preferably visible by big screens in each site.

Everyone goes home ensuring builds are green and progress is reported. Each site would benefit from a scrummaster who will communicate frequently the outcome of standups and who can assist removing impediments from the remote team.

See Craig Larman's lessons described here.

share|improve this answer
add comment

Some useful heuristics.

We came up with a few rules that help us to make decisions about how we'll tailor (or how we will NOT tailor) our environment to make it work with distributed teams.

I've been on teams with distributed members, and I also spent two years as a remote developer. I found that pair programming through tools like webex helped a lot, but these rules were extra-helpful in making remote membership work.

share|improve this answer
    
Please don't just answer with a link; at least paraphrase the essence. –  blubb Aug 28 '11 at 15:40
    
I edited it. Is it better now? –  tottinge Sep 9 '11 at 3:57
add comment

Our team has a similar setup. We have an entire team of analysts working in one time zone, the core developers of whom two in one zone and one in another zone. Stand up is via skype. We use pivotal to manage the projects and assembla to keep track of everyday activities. Company policy is push to git every day and each of us has to go through the commits.

share|improve this answer
add comment

Not the answer you're looking for? Browse other questions tagged or ask your own question.