What can I do to ensure that my outsourced software development team is working?
By Víctor Martínez
Whether it’s to India, Eastern Europe or Latin America, outsourcing software development has proven the right solution for many companies during the last couple of decades.
But even if you outsource your work to a company just two miles away from you, sometimes you can’t help but wonder, “Are they really working productively and efficiently even when I’m not there to watch?” Such concerns are common, particularly if your job is at risk if something goes wrong. But fear not; for here’s what you can do to mitigate the risks that companies face when they outsource software development work.
It’s a basic principle: the better you get to know a person, the more effective your interactions with them will become. This applies for the individuals working in your office building as well as for remote teams. Real life, face-to-face time among the people that will be collaborating is highly recommended, preferably at the beginning of a new work relationship, but if this is not possible try to accomplish it as soon as your budget and agenda allow.
Doing this periodically is not a bad idea either. Plan to visit your team or have team members visit you at least every couple of months. This may sound like an additional cost to your project, but after you see your gains in improved communication, productivity and trust, you will find this practice to be a very good investment.
Many studies have shown that people from different backgrounds bring their own perspectives to the situations they face, which tends to ultimately produce more solid, creative and well thought solutions. If you are from California for example, it is not hard to spot cultural differences with people from Texas, New York, or the mid-west, and vice versa. If your team members are in a different country you may notice even more pronounced differences every now and then.
Spend time understanding your collaborators’ culture. It’s well worth the effort and it will allow you to motivate them more effectively and communicate better with them. Even if you don’t get it right the first time, they will appreciate the gesture. And once you reach certain level of empathy, the improved team results will come naturally.
In the current Agile world many teams have completely disregarded metrics because they remind them of software development’s ancient history when, in many cases, more metrics than necessary were tracked because it was considered a good thing and looked cool in the dashboards. But as long as the value is clear, metrics are perfectly compatible with the Agile way of doing things – particularly with teams in different geographies. They help us to get past superfluous impressions and provide hard numbers to measure performance and how things are really going.
If you don’t have a tasks management software that does this automatically for you, just pick a couple of metrics that make sense for the project. Ask the team to capture them diligently, analyze the data after some iterations and evaluate if they are giving you the necessary information to keep your mind at ease. Don’t forget to share with the team the intention of each metric, the obtained results, how you interpret those, and the subsequent adjustments that may be required. Also, try to stay away from metrics like “lines of code written per day”. It is better to focus on the agreed deliverables rather than the specific activities that will produce them.
When we talk about putting together a software development team, we tend to focus on technical skills, profiles, number of people, etc. This is absolutely relevant, however, it is equally important (and some will say it is even more essential) to have well-defined processes and methods to accomplish the goals in other words, the “how”.
It doesn’t matter if it is Scrum, Kanban, Waterfall or a hybrid. The important part is:
- The methodology is well defined and clear for everybody.
- It makes sense for the type of project your team will be working on.
- Everyone knows their role and how to play it.
- There is a way to evaluate and adjust it (i.e. Retrospective sessions after every iteration).
This applies for local and remote teams. Spending enough time on this subject, at the beginning of the project and throughout the development cycles, will give you that feeling of certainty that you have a clear path toward achieving the expected results.
Nowadays we have a whole spectrum of choices when we think about software to maintain communication. E-mail clients are definitively helpful for formal, lengthy or non-urgent matters. And IM apps are a great way to exchange quick messages. They both should definitively be part of our arsenal to stay in touch with our remote teams. However, it is very important that we transcend the written word and also include voice and video tools to communicate.
We need to remember that 55% of communication is body language, 38% is the tone of voice, and 7% is the actual words spoken. So to maintain good communication it is highly recommended to have at least daily stand ups using voice and video. This will also produce the illusion of being in the same room, which will contribute to the integration of the team.
A key element in any type of work (and non-work) relationship is trust. This little word so hard to earn and so easy to break. It has a lot to do with the performance of a team. When somebody doesn’t trust their team, sometimes they start micromanaging or put it under strict surveillance. I have personally seen cases where remote teams are asked to install video cameras pointing at them and their screens during the time they are in the office. And there are some software applications that are used to measure the time they take to complete every single task, even going to the bathroom.
This approach doesn’t work. It might create the temporary illusion that you are in control of things, but the truth is that no good developer will tolerate something like this for too long. The most likely results in the long term are a high level of attrition, an unmotivated team and very low productivity. Software development is a creative process in many ways, and as such, a good outcome is seldom obtained when the work environment is overly restrictive. Sometimes a leap of faith is required to start building that team trust.
Trust is also a basic ingredient for other characteristics of mature, high-performance teams. Once you feel comfortable with the level of trust in your team, start giving them more room to operate on their own. With the help of clear general guidelines, autonomy has proven to be an excellent motivator. Open up, and share with your team what you are trying to accomplish, including restrictions, frustrations, concerns and hopes. You will be surprised to see the degree of ownership that can be developed once they understand better what they have in their hands. In other words, the more they know, the more they care.
And finally, be part of the team! Don’t see yourself as an isolated entity that communicates with the team just to tell them what to do and to see if they did it right. A common characteristic I have observed in the most productive remote teams is that they feel very well integrated, even when somebody is physically in different location. Celebrate successes, and work through the issues together (yes, there will be issues). Be there to answer their questions and share your experience without holding back. Those are the types of things that will give you the best results.