As many companies can attest to, it matters less and less where software developers are physically located. Working in a distributed manner with somebody halfway around the world is almost the same as if they were in the next building as communication is disrupted in either case. But there are some key differences to building an internationally distributed software team, and working with them for the long term, versus building another team in the building next door.
U.S. companies are accustomed to expanding internal teams by figuring out how much work is required for a project or how much is in the pipeline for a particular system, and how many programmers will be needed to complete that work; they then immediately hire the full allotment of programmers (assuming budget allows). There may be an onboarding process for new team members which may involve having new team members complete a training course, or work with a mentor, etc., but the main emphasis is on technical skills. These types of companies come to Softjourn eager to “start up a remote team,” believing that everything is going to be wonderful once they have 10-25 top level programmers on board. When you work with a remote team, however, assigning a full team of developers from the very beginning is often impractical and can cause inefficiencies that plague a development team for its entire lifecycle; especially if this is a company’s first foray in to working with a remote software development team.
At Softjourn, our process for helping our clients build software development teams is different but simple: prepare, construct, produce then expand. This means that we build a team on a solid foundation before expansion. If your company truly wants their remote team to be a part of your company, to work directly with another team of software developers who work at your company headquarters, or in other locations around the world, etc., more time and more of a process is needed to bring remote developers in to your company culture. Helping them understand your product and your clients takes effort, getting both sides (your existing software developers, QA Test engineers, product managers, escalation engineers, etc.) comfortable and trusting each other takes time, and this is much easier when you start with a small and focused team. Start with a small team, get the process right, and then expand. In addition to allowing for a more efficient initial training process, this lets the team itself select the right people for the team, to train new members as they are added going forward, and gauge their productivity. As well, your current in-house developers have to get used to working with a remote team. Processes have to be in place for communicating effectively with a remote team, to introduce and get them and everyone comfortable with communicating and working directly, to set realistic expectations for the team, etc.
Every aspect of our system is designed to work for our clients. The key advantages to this process are:
– Every single developer working on your project fully understands the objective of your application, why the users work in a certain way with the application, etc., and is able to communicate the objective to the other members of the team.
– Your in-house team feels comfortable working with your remote team, both to contact them directly, and with the level of productivity of the remote team.
– The team gains momentum as they move forward, completing work faster and faster, as they become more and more familiar with your system. They also are able to provide input to the design of features, and require less and less of your input in order to be able to understand how your company expects features and changes to be designed and implemented.
Once you get to this point with a remote team, you can start adding people. The remote team will be able to identify the right people to add to the team, those that will fit in with the team culture you want. One of the worst things you can do is to start to develop remote teams in multiple directions at the same time (for example, for multiple products, at one time), without having the process at least working for one team. You can expect that there will be just as many adjustments inside your company, with regards to working with the remote team, as there is for the development of the remote team itself.
Distance means that there will be differences when working on joint development, and those differences could cause significant delays in the development lifecycle of a software development team. Taking the time to prepare, construct and produce, before you expand, may seem like you’re slowing things down, but you’re actually solving problems before they even exist – and that improves your ongoing software development from every perspective. For more information on Softjourn’s Prepare, Construct, Produce, Expand methodology, click here.