Software Development with a Distributed Team
Sending part of work to offshore companies has become natural to many areas of business. Outsourcing software development to countries that have well educated people with decent engineering skills is part of life many project owners are used to.
The idea to find the right engineers turned out to be so good that many project owners even started gathering their own teams and hiring people in different countries. This is how the concept of a distributed team became a common practice. A distributed team or a virtual team is a term describing a group of people working on the same routine but separated by geographical location.
Online marketplaces for freelancers made this practice even more commonly used. Most of them gave preference to individuals rather than to companies with established approaches, so it was easier for project owners to find sole freelancers and invite them to their development groups.
Some of these hand-made development camps succeeded and launched very cool projects. Many more did not.
How to deal with a distributed team
Now, what a project owner should know about working with a distributed team to make it productive? Here is a narrow set of questions a project owner may want to know answers to.
Is the distributed team model functional?
I found many postings in the Internet that were very sceptical about distributed development teams. At the same time, there were some publications that appreciated the model. The real answer is that a distributed team can work out, but it requires much experience that is usually foreign to the project owner.
What is key in building a productive distributed team?
People and the approach. One of the publications that appreciated the distributed team model mentioned that the project owner should 'hire the right people'. But do you know what it means, to hire "the right people"? Hiring the right people is a universal problem which is never completely solved by any company, organization or country. If you know how to do it, go on and do it. But if you are not confident in your HR skills, you have more chances to succeed if you hire a complete development camp that has all people sitting at the same office.
Okay, what about the approach?
Software development companies usually have an approach. The approach may differ from company to company, but the trick is that every software development company has its own experience in the way they commit updates, show results, communicate with the project owner, etc. Distributed teams should also follow some rules, but they do not have them by default. So, they should agree on some kind of an approach before they start doing the distributed software development.
Don't all developers follow the same trends and approaches?
Usually they don't. Even if they pretend to be "agile", there are many versions of the agile approach available. Compared to software companies, individual freelancers usually feel fine about following whatever approach, but they expect that the project owner would personally define the rules and force all collaborators to follow them.
Will I spend less time on communication?
Often, software developers are not very communicative. Software companies motivate their engineers to communicate, share experience, help each other and so on. But when engineers are by themselves, they tend to focus on their tasks and leave communication to those who need it. So, most likely you will need to inspire communication in the project.
Can they at least talk about the technical stuff without my presence?
They can if they are on the same page and everything goes smoothly. But what would you do if they started conflicting with each other or transferring responsibility from one to another? They would expect you to be the judge resolving the dispute. Therefore, you should be really into the issue to know how to solve it.
To sum it up
A usual agile approach says that the best way to arrange collaboration is to make the business responsible for business and let the development be responsible for development. These roles should not overlap, people say.
When it comes to a distributed team, this principle is not met. In this case, the project owner (the business) is responsible for business… and for something else. In particular, they should be responsible for project management, defining collaboration rules and resolving conflicts.
To manage all this stuff, the project owner should be very aware of everything that happens in all their development camps. It means, he or she will be spending more time than they would spend if they hired a single development camp.
If you have any other questions about managing a distributed team, just click on the 'Contact' menu and leave a message there. I will be happy to answer your question personally.