Working in a distributed way is becoming more common. This can be a particular challenge for scrum teams. Here are some ideas of how to run distributed scrum teams, assuming that they are co-located, rather than having members of the same scrum team split across locations (a very different challenge!).
Have a Project Kick Off
Have a project kick off with everyone in the one location. Run through everything pertinent to the project and get everyone to present something, including information on themselves.
A good project kickoff can make all the difference, because people will tend to work more smoothly together once they can put a name with a face. Rather than just an exchange of information, use the kickoff as a way to bring the teams together socially and have a bit of fun.
- Book a group lunch
- Invite the group to the pub
- Have introductions - ask everyone to give an interesting fact about themselves
Don't underestimate the extra time needed
Extra time will be needed for:
- Ongoing careful comms to plan and to prevent misunderstandings
- Questions and queries (which will take longer to ask and answer)
- Video conferencing.
Use chat/IRC or messaging
Tools like IRC or Skype can be used to create team "rooms" to act as a virtual home for a distributed team. Each team member can use whatever chat client suits them and they can also use it from home. Encourage everyone to be logged into chat or messaging all day. If you use multiple channels for your project, ensure that everyone feels welcome to join into any of them and that logs are freely available.
Have a daily Scrum of Scrums between the leads on each project.If you hold this in chat/IRC:
- Use a separate channel from the main project's channel
- Remind others that "chickens" are welcome and what the log location is
- Make sure that it starts on time
- Encourage the attendees to have the text ready beforehand to cut and paste so that others aren't hanging around whilst people type
- To keep things moving it's a good idea for everyone to state when they have finished and/or choose the next person to give an update.
Get good at Video Conferencing
If you have access to a corporate video conference system, make use of it to hold end of sprint demos and ad hoc chats between the distributed teams. If not, you can use Skype, though the quality isn't as good for demos. Google hangouts is preferable to Skype for scrum of scrums, because it can handle multiple attendees (more than 2 participants).
Agree Travel Budgets
If you can get to and from the other locations in a day, try to budget for at least:
- Initial project kick off trip to one location, including overnight stays if needed
- One person's trip from each team to each other location per sprint (more if you can afford it)
- Trips at the start of the project whilst teams ramp up
- Trips for new joiners to get to know the other teams
- End of project celebration
Clear reports, clear and useful pre-sprint planning and up-to-date-ness of issue trackers will help.
Agree the comms that you will have between teams, everything from ad-hoc queries, through in-team reports and updates to stakeholder reports.
Document everything - no, seriously, write it down!
Make use of a team wiki and ticket tracking system to ensure that the remote teams have a single area to share information. It's better to over-document than under-document, even if you're an Agile team (being Agile doesn't mean having no documentation!). One of the most frequent frustrations that a remote team has is that they miss out on the "hallway" conversations that happen in the other office. So, whenever the team discusses something, make sure that someone writes it down in the wiki.
Examples of useful things to document:
- A checklist of activities that occur during the sprint, so that both teams are always in sync
- A record of dependencies on other teams so that everyone knows the gaps in responsibility for tasks
- Listings of communications methods so that the teams know their options for getting questions answered
- Working agreements clearly stated for the teams, which help to align the practices of geographically separated groups
- Areas on the wiki, such as a scratchpad where remote teams can record their thoughts, concerns and questions -- then have them answered
If two or more teams in remote locations are working on the same project, try and merge working practices as much as possible so that there's a common language and frame of reference between the two groups.
- Use a single ticket tracking instance for the teams
- Follow the same sprint cadence:
- Use the same sprint numbering for both teams
- Hold sprint demos over video conference
- Share both teams' sprint goals and priorities at the start of each sprint
- Hold sprint retrospectives and planning sessions at the same time
- Use the project as an opportunity to learn from the other team and improve the way both teams work