“If you were here I could explain it much more easily by simply drawing it on a paper.” – is what our colleague said at the beginning of a rather complex project. We knew that we should try to transfer as much domain knowledge as possible while we were still together in the same room. Once we were in separate countries again, some things will become just a little more complicated.
Starting a project in a distributed environment can be a daunting task. A lot of small things could go wrong: infrastructure problems, cultural mismatches and communication obstacles… Nevertheless we always had success, which is exactly what this blog is all about: encouraging you by our experiences.
This blog post will consist of three parts, and in the first one we will talk about environment setup.
Setting up environment
Setting up the development environment in collocated teams is a very straightforward task. Usually, that job is done in the first sprint of the project and includes setting up team resources such as a tool for backlog management, source control repositories, continuous integration and delivery, a project wiki. Also, each team member sets up their own workstation, which can be sped up by setting up a virtual machine image once that each team member can reuse. This can come with minor performance penalties, but given the benefits it is a small price to pay.
In a project that has been under development for a long period of time, setup can be a tricky thing, especially if the code base is very old. In situations like these, going for an on-site fade-in might be the best solution.
As you might imagine, in this type of situations, the working environment, team processes and team culture evolve with the project itself. Team work has to be on the high level from the get-go in order for the on-boarding to succeed. Depending on all these circumstances you have to choose how to setup the environment. As stated, the simplest thing to do is to go with a collocated project kick-off, but you should be clear on advantages and disadvantages of this approach.
Advantages of going collocated when doing setup are numerous: You build up teamwork and trust when interacting with the colleagues, along with the environment setup some of the domain knowledge is shared, and the part of the team can start settling in more easily because roles can be quickly established and strengths and virtues of team members float to the surface. Environment setup is naturally much faster, a lot of the knowledge is transferred and team members are on boarded by quickly receiving many daily know-how sessions.
There are also some disadvantages when going collocated in the first phase: First of all, during the setup phase itself you easily get used to just shouting out for help, while in the distributed setup, you don’t have that possibility since you lose personal contact with your colleagues. Distributed development tools also get neglected when team members are collocated, and this might be one of the most important aspects of the setup.
After a successful collocated on-boarding there comes a period of distributed setup, aligning with the tools and modifying team processes so that they fit new team composition.
It is recommended to test various collaboration tools during the initial phases of distributed development in order to find the ones which will work best for the team – there is no “silver bullet”. For every type of collaboration (direct and group meetings, pair-programming, code review, video conference etc.) there are multitude of available tools – both open-source and commercial ones. Tool selection and acquisition process sometimes lasts up to a few months.
Things that usually influence choices the most are network speeds (e.g. upload speed is not sufficient for many of the tools you want to use), troubles with VPN connection and lack of human interaction between team members. Sometimes you actually cannot influence the VPN and network that much (e.g. it’s sometimes required by the customer to use their infrastructure and then the team doesn’t really have much choice), so the solution is to find adequate tools that aren’t influenced by these circumstances.
We had such an experience when we had to use customers’ infrastructure with centralized TFVC (Team Foundation Version Control). To be able to merge the changes it was required to be connected to their VPN network, and the VPN connection was not always reliable, so this really made our daily work much more difficult. The only solution in these situations is to use temporary repositories or mocks in case of services, and integrate when obstacles are removed. Creating fallback strategies early is crucial, because that prevents having any work blocked.
Team members should also agree at the start of the project on coding convention and formatting that is going to be used. This may seem as a trivial and unnecessary thing in the beginning, but it saves you from headaches later when the code base has grown. Hopefully, nowadays IDEs have built-in or 3rd party support for configuring these things, so one team member creates this configuration, which other team members can import into their IDEs.
Since the project evolves, it is very important to revisit the things you setup in the beginning: some of them might not be needed anymore or newer, better, tools could be used instead of existing ones. If you use Scrum, the perfect time for this revisit is Sprint Retrospective.
Next part of this blog series will address sharing domain knowledge during fade-in to the distributed setup.