How to Manage your Distributed Software Development Team

May 29, 2014

Lots of software development companies do not like outsourcing, while others hate the very idea of having a development office offshore. Truth to be told, they have fair reasons to claim that you can’t achieve much with outsourcing that has its pros and cons. Managing a development office remotely isn’t an easy task. Major difficulties include lack of communication, time zone differences, peculiarities of national mentalities, motivation of employees etc. There are lots of difficulties, but there are obvious advantages - considerable cost savings, increased productivity and decreased product development cycle. Using the right tools, services and processes, managing a nearshore team is a breeze.

No specs - no features

One of the most common mistakes project and product managers tend to make is insufficient documentation of features, requirement and processes. Online discussions are OK, but it is very important to have all processes and communications properly documented in the internal company wiki.

Confluence from Atlassian seems to be the most obvious choice to maintain internal documentation.

Confluence offers a pretty standard set of features typical of ordinary text editors. Yet, the power of confluence is a collaborative mode. It is possible to create spaces like Processes, Communications, Product Specifications. If you want to have a new product feature or improvement, make sure it has detailed specs. The more details, the better. Developers are creative people, and they can come up with some interesting features and solutions without specs. However, if you want to get exactly what you need, write up specs in a corporate Wiki, comment on specifications, invite other users to join discussions.

Atlassian Confluence is incredibly popular among software companies, including those based in the US and having development offices in the Eastern Europe. It offers a series of tools to create tables, diagrams, charts and other graphic objects.

No issues - no work

Every software development process is doomed to deal with bugs. It is inevitable. Bugs are to be located, documented and fixed. Atlassian Jira is among the most popular bug trackers with a convenient interface, project and issue grouping options, comments to issues, and an understood logic of issue life cycle. It does not matter what you want to to - fix a  bug, assign a task or improve something - register a Jira issue and your initiatives will never be lost. Skype communications can only clarify issues. However, the rule of the thumb is - if there is no issue, the bug never existed.

Jira offers a great toolbox for developers and PMs.

An issue life cycle is easy to understand - issue is created, assigned to a team lead, team lead assigns a developer to deal with it, comments are published to discuss tech aspects, once the bug is fixed the issue is validated by the PM and then closed. In such a chain, it is hardly possible to lose some important info or the entire issue itself. Moreover, developers can log in to issues and estimate time they need to fix bugs. This helps in planning for PM and of course, budgeting.

Jira has lots of helpful extensions and additional services like GreenHopper or Kanban (part of Greenhopper) which are manifestation of Agile approach in software development, i.e. step by step iterations.

Visualization of the development process simplifies adequate sprint planning.

With Kanban managers and developers can drag issues from and to several categories that are perfectly and clearly visualized: to do, in development, done, to review, to validate and what not. So, you have 100 issues for a current sprint and it is difficult to get one whole picture of what’s done and what is to be completed. Kanban offers such a picture.

Jira pricing is quite flexible and can meet requirements of both small development companies and huge dev teams.

Retrospective

Looking forward is the only way for a software company to succeed. Yet, looking backwards might help analyze own mistakes and imperfections. When a sprint has ended (a sprint is a period of time for which a certain amount of tasks is planned), ask team leaders to think of what has been achieved and what failed. Ask them why. This is not about finding the ones to blame. This is about bettering internal processes. Often, PMs change specs on the go, which makes it difficult for developers to follow up. Sometimes, goals of the sprint are not achieved because dev leaders have inadequately evaluated timing, or planned features turned out to be bigger than expected. You are sure to get some interesting information after such retrospective meetings. Another way to share this info is to use the abovementioned Confluence.

Mentality

With that being said, even the best designed processes can fail because of difference in mentalities. Eastern Europe differs from the US, Europe or Asia. Russia and Ukraine have given the world tons of talented programmers. Yet, sometimes, the US managers cannot understand Ukrainian or Russian devs, who, despite their talent, might ignore certain requirements. So, what should be taken into account?

  • Meetings. Ukrainian guys often do not like to talk much. They’d rather use this time to code. It does not mean that meetings through Skype are impossible. What this means is that Ukrainians are not as fond of discussions and reviews as Americans.
  • Language barrier. Ukrainian developers usually have adequate English language skills (from intermediate to upper intermediate). However, it is often difficult for them to understand a native American spoken language. So, using a simple language and a slow tempo is probably a good decision. 
  • Motivation. Labor market and employee rights are a bit different in Ukraine as compared to the US, Asia or Europe.  Many developers are former freelancers and they can turn to freelancing the moment they think they are not valued in your company. So, showing your good will and a positive attitude towards employees is a must. It is not just some bonuses or a regular pay increase. Sometimes, just a friendly chat in Skype works better. Although you never see these people, bear in mind they are real people, just like those you see in your office every day.

Summary

Most important things to focus on when managing an offshore development office are:

  • use of the right tools, software and services (see examples above)
  • having a dedicated person to be always online to solve problems and answer questions developers and PMs might have
  • setting up adequate processes and communications channels
  • always keeping in mind that remote employees are just like people in your local office
  • differences in mentality might make a difference
  • on time payments, bonuses and regular pay increase for best performing employees

Contact us

Leave this empty:

Call us

Netherlands    +31 (0) 75 302 0011

Israel               +972 23 760 374

UK                   +44 20 8080 6557

Germany         +49 30 255 555 726

USA:               +1 678-783-7681​

    +1 646-769-9099

    +1 646-500-8698

Privacy policy