How to Manage Distributed Teams Using Scrum

How to Manage Distributed Teams Using Scrum
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.

    • 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.

    • 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.

    • 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

    • 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.

    • 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.

    • 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.

    • 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!

Related articles
What works well and what you should be aware of while working with TensorFlow. READ MORE
Learning methods go through tremendous changes. Right after the e-learning and video tutorials boom, another technology emerged that promises to revolutionize the way we share information. Find out why there is such hype around augmented reality and how it can transform your business in terms of training and knowledge retention. READ MORE
Retrospective meetings are a great occasion for generating insights and ideas to improve workflow efficiency. Sometimes such improvements start travelling from one project to another and become best practices eventually. We want to share our top 7 tried and tested retrospective findings - hope they come in handy for you as well. READ MORE
For tech professionals, staying up-to-date is more than a natural curiosity, it’s a must. How to be wired up without spending too much time on it, and what blogs to follow - further in the blog post. READ MORE
Smooth collaboration and effective project management are crucial for software development. No wonder there are so many approaches and tools designed especially for software project management. And whereas there is no single cure-all tool, you might find our experience in using the following tools helpful! READ MORE
Inspired with the idea to improve the reliability of computer object detection and eliminate the necessity to handle it manually, we initiated a proof-of-concept project on automating microbiological analysis with the help of deep learning for one of our clients. After few rounds of the meticulous testing, we are happy to share the outcomes. READ MORE
The role of a CTO involves constant challenges. And a product release doesn't mean a retirement for a CTO, but a new mode of working and new issues to be prepared for. Check out these top 5 challenges that every CEO of a growing company might face and our tips for handling them. READ MORE
When there are so many examples of tremendous success done by pioneers of certain technologies, the fear of missing out becomes quite reasonable. Don’t miss out two biggest trends of 2018 (from our perspective) and learn how your business can respond to them by reading this blog post. READ MORE
A university-industry partnership is a win-win deal that gives a competitive advantage for both parties. Read more about our experience of collaborating with a university and how we benefited from it - in this blog post. READ MORE
The transition to Scrum is an exciting learning experience for everyone involved. However, it might be overshadowed with human skepticism and doubts. Read more to learn what challenged to expect during the Scrum adoption and how to avoid them. READ MORE
Changing the way how people used to work might be quite a pain. And doing it by introducing Scrum is not an exception. If you’re considering to adopt Scrum or started the transition process already, this blog post is for you. READ MORE
When development becomes painful and time-consuming the debate over “what to do now?” starts. Fueled by developers’ claims “the code is a mess”, “we can’t work with the legacy code”, “let’s rewrite it” from one side, and the business trying to solve the issue less dramatically - from the other, the discussion seems to be never-ending. This blog post will guide you through potential pitfalls while deciding whether to improve the existing code (by refactoring, running unit tests etc.) or rewrite it from scratch. READ MORE