Bringing together people to work on the same project from different locations is becoming a common practice. And no wonder. It’s cost-effective, it gives access to a wider pool of experts, and it’s doable as never before thanks to all the telecommunication tools available nowadays.
But let’s not forget that distance and lack of physical connection take its toll and may bring impediments to the workflow. So if you don’t want to jeopardize on-time and quality delivery, you need to manage a distributed team differently than a colocated one.
After 7 years of experience in setting up distributed teams using Scrum, we cut our teeth on the possible pitfalls and collected several rules to make things work:
Ensure integrity
Everything starts from the mindset. When team members feel and act like one team, they share responsibility for the project outcomes and cannot let each other down. They start caring about the project and get more involved, instead of blindly performing assigned tasks.
How?
- Value an entire team, not separate members or certain subgroups.
- Don’t let “us versus them” culture appear, practice the “we” approach.
- Try to meet in person – at least once in a while.
(Just last week we spent 12 h driving back and forth to the branch office on the other side of the country. Yes, we just wanted to catch up with our colleagues there. No, we don’t do that often due to the distance. But these meetings are worth the trouble.) - Give the team some autonomy to ensure self-organization.
Run proper onboarding
It’s better to clear up the rules of cooperation at the beginning, rather than fight over arising misunderstandings on-the-go. Gathering everyone involved in the project for onboarding (online or f2f if possible) will certainly pay off in the long term.
How?
- Go through everyone’s expectations and preferences.
(What do they need for successful cooperation? What tools do they prefer? How does the ideal process look like for them?…etc.) - Discuss and agree on the rules of collaboration, write them down.
- Check if rules are clear for everybody.
- All stakeholders should agree on these rules.
(And remember that silence is not a commitment.)
Set up fixed timing for daily, planning, demo, retrospective meetings
The Scrum process is called to bring flexibility to the collaboration between the development team and the client. But by no means it should lead to slackness and chaos in communication. Scrum rituals must be followed strictly with no deviations.
How?
- Pick timeslots convenient for all team members.
(This is possible even when team members work from the different time locations. But make sure that they are normally available in the office at this time, and will not have to get on the call from the grocery shop, kindergarten, gym or wherever they are when out of the office.) - Make it clear that once agreed on the time slot cannot be changed no matter what.
(An innocent postponement of daily for the next day, because somebody couldn’t make it, usually has avalanche effect and may postpone the delivery.) - Underline the importance of business representatives’ presence at the meetings.
(The team’s morale depends on that. If a Product Owner doesn’t show up at the meeting for the 3rd time in a row, the rest of team members will most probably participate reluctantly.) - If a distributed team consists of more than 2 persons, appoint a Scrum Master (at least part-time) to facilitate meetings and cooperation overall.
- Video calls should be preferred over chat and voice calls.
(Video makes it more personal.) - Remove all technical impediments that can harm the workflow beforehand.
(Think of the second internet line in case the first one doesn’t work, make sure there is a technical support available in case of some problems and a quiet room to conduct a meeting).
Use tools for virtual collaboration
A board and sticker notes are nice, but when working remotely you need something that is virtually accessible. Here are some of the tools that we use or at least tested:
- Task tracking and project management tools: uTrack, GitLab, Jira, Trello
- Planning poker online tool: PlanITPoker
- Virtual meeting and communication tools: Skype, Slack, Mattermost, Appear.in, Google Hangouts
- Tools for sharing knowledge and documents: Google Docs, Confluence
How?
- Remember that it’s not enough just to have these tools. Make sure that your team members really use them.
(Everyone should keep the tasks up-to-date in the system – not in the chat and for sure not in the head. Remember: if it’s not in the system – it doesn’t exist.) - Seems like it’s hard to follow all the tools? Go for an integrated set of tools rather than separate ones then.
(F.e. GitLab provides the whole set of tools: repository, ticketing system, tools to store and share documents, time tracking etc.) - Automate the repetitive actions (such as updating the ticket status) by using integrations with other services.
Maintain healthy time zone overlap
Distributed teams working in time zones where there’s no workday overlap are unsustainable in a long term. Try to build a team within close time zones to have at least a few hours a day of real-time overlap.
How?
- Distributed teams of more than 9-10 people located in substantially different time zones can be divided into smaller sub-teams based on the geographical closeness.
- Make sure that distributed teams in different time zones are self-sufficient.
- Minimize dependencies between the teams or team members working from different time zones, not to let the time difference block the progress.
Be ready for new urgent requests
For distributed teams, it’s especially important to think beforehand how the emergency requests should be handled in the middle of the Sprint. Everybody should be familiar with the process.
How?
- Include “a safety buffer” to every Sprint – some time that the team can spend on unplanned tasks within a Sprint.
- All unexpected requests should be sent via the Product Owner, who defines the priority of such requests in the product backlog.
- If there is an unexpected task that cannot be performed within the safety buffer, the product owner may decide to stop the current Sprint and plan the new one including this task or leave it till the next Sprint.
Check what is not working, fix, iterate
Use retrospective meetings not only to analyze the flows of the produced code, but also to figure out what could be improved in the process of collaboration.
How?
- Check whether the processes and the chosen tools for communication work for all team members.
- Make sure everyone gets needed support and answers from others on time and there is nothing that blocks their work.
Geography doesn’t matter anymore. Especially in the world of IT. Tomorrows teams will be working from home, sunny beaches and god knows from where else. And businesses should be ready to deal with it.
We find Scrum principles of keeping teams small, self-organized and transparent, essential when building a distributed team. But also keep in mind, that there is nothing better for team integrity than having a glass of beer with your fellows at the same table. At least once in a while.
Hope you find our observations useful!
