Best Practices When Managing a Distributed Team

Internet gives an ability to hire the best software developers from all around the world. A smart project owner can even gather a custom team made up of engineers located in different countries. This type of a custom team is also known as a distributed team or a virtual team. Having a distributed team is a great opportunity which, however, can turn out a great catastrophe if the project owner does not know how to manage such a team.

Working with a distributed team is different from hiring an established software development company. A distributed team requires management done by the project owner personally. Here are several practices that one should apply to get the best results assuming that he has highly qualified professionals in the virtual team already.

Best practices when managing a distributed team

1. Participate in the communication as much as possible. Communication is key in all projects, but it plays a special role when the software developers are separated geographically. Someone should bring them together and make them a team. Someone means you, who else? Communicate with the team on a daily basis - engineers left by themselves tend to focus on their assignments and keep away from the other participants.

2. Define the collaboration approach. Unlike software companies, virtual teams do not have an established approach. So, go on and establish one - tell the engineers who is responsible for what. Do not let them work on separate modules of the code - it will make them less involved in communication. Quite the opposite, help them define the rules of sharing the same resources, sending merge requests to each other and act as a community with the same values.

3. Choose a responsible person (a team lead). It should be expected that the virtual team will have disputes. In case they start arguing about the business side, you can choose the right direction youself. But if they start talking about the technical stuff, you may want to have a person to rely on. Choose an engineer who is the most experienced (or the most conscious or whom you trust the most) and give him the final word.

4. Help the team agree on standards and make those standards visible to all participants. Not only should the team have the same values (which is certainly important) but they should also have a set of coding standards available to everyone. All engineers should agree on these standards, follow them and even help new participants learn the common manner. By the standards I mean the way automated tests are written, the routes are arranged, etc. Even the indentation rules matter.

5. Set up a continuous integration environment. I have already mentioned automated tests and there is no doubt that a distributed team cannot live without them. When the knowledge is shared among multiple project participants, the only way to aggregate it in one place is to follow automated testing and monitor the state of the project. The project should always have a "green build" - the state when all tests and use cases pass. A continuous integration system will help you see when the build gets "red" for any reason.

6. Run the planning game. The next question is how to run the development. Obviously, there should be a plan. If you hired a software company, they would have one. But in case you manage a distributed team, you should have your own roadmap. Make it visible to everyone using an online planning tool. If you (hopefully) stick to the agile approach, the planning tool should look similar to the classic story board. Arrange meetings on Mondays and ask your engineers to reestimate the user stories scheduled for the coming week together. Then assign the user stories to the developers and encourage them to be proactive during the entire week.

7. Make decisions! There can be many situations when a decision is required. Some technical issues can be solved by the team lead. For example, he can decide whether to accept or decline a disputable merge request. But everything related to the business or the roadmap - features and how they should be built, what functionality is of higher priority, etc. - is up to you. There are times when your developers may procrastinate for a long time. They will desperately need you to make a decision, so be around and be decisive!

If you follow these rules, you will get the maximum value out of your distributed team. Alternatively, you can hire a professional software development company with an established approach that has seasoned engineers sitting near each other. These developers know how to arrange collaboration, run the planning game, and which questions should be elevated to the project owner.

Get in Touch