Dear future distributed developer,
We have been in distributed development for quite some time now. It is great! We have met a lot of exciting people from different countries and cultures. We are exchanging knowledge with them, but also going out to have fun at social events. A colleague of mine has written a very interesting blog post about it, please read Fade In (Part 3).
Of course, not everything is a cakewalk. You have to work hard for a success story. First of all, you need a good start. Everything begins with the setup, either being a collocated or a distributed one. Coding conventions, collaboration tools, virtual machines … a lot of different solutions, you have to find the right one. We have compiled all those ideas in one place Fade In (Part 1).
Those technical things are important, but not enough. What might be even more important is how you are going to learn all the business logic. And business logic can be quite complex! Who and how is going to transfer all the necessary information to you? And in what language are you going to communicate? All these things we have experienced and we have shared our knowledge: Fade In (Part 2).
If you think that your job is done after you have met the team and prepared well, you got it wrong. The most important part comes after this. You have to keep up the good communication. You have to think about the quality of your meetings: microphones, TV, camera … but also the format of the meetings has to be well defined in order to reduce overhead. If you want to learn more about this topic, I know another good article: Collaboration (Part 1).
The difference in everyday’s work does not stop at the infrastructure, taken into account that you have to change the tools you usually use. Daily meetings, retro sessions, reviews, pair programming or just simple ad-hoc meetings – they all need a good tool that will ease the pain. Good tools result in faster and better meetings, which results in more productive work. I suggest you get well informed here: Collaboration (Part 2) before you dive into distributed development.
If you are planning to do Scrum, a lot of things stay the same. Someone has to moderate the retro sessions, you have to stand up during dailies (and split stories into tasks during planning). But you also have to consider if those meetings can be moderated distributed or if you do have to go collocated. Who will share the knowledge during estimations and how to present that nice product of yours to customers? These are interesting topics as well. There are a few blog posts that will help you with all this. In one of them you will even find information on quality assurance and how testers can find their place in such a project. If you are interested: Delivery (Part 1), Delivery (Part 2), Delivery (Part 3).
If, by any chance, you’d rather manage distributed projects, then you will have different questions in your mind: how to bid on a distributed project or how to help out your distributed team? You will find this blog post very useful Managing Distributed Development.
If you don’t believe our judgement or if you are just keen to see this topic from another perspective, you should check out what our collocated team members think about distributed development: Q@A Session (Part 1), Q&A Session (Part 2).
Maybe distributed development has some downsides, but those can easily be overcome with a positive approach and a little help from a wonderful blog series. We found out that distributed development is an extraordinary experience which we may recommend to everybody – at least to try out!
With best regards from yours,