I’ve come across a good new blog, Coding Horror, written by Jeff Atwood, one of the founders of one of my favorite coding sites, Stack Overflow. In reading through some of the older posts, I came across one that is close to my heart which is on working remotely, or what we at Microsoft called “distributed development” (since we didn’t like the assumption that one side is “remote” and the other “central”). During my last few years at Microsoft I worked on a team that had members in different geographies, and also did a bunch of work on collecting best practices for Microsoft development teams new to the practice.
At Microsoft, I used to say, “Redmond is Rome” – in other words, the heart and soul of the company is still centralized in Redmond, Washington. Since Microsoft is obviously a global company, it has always had locations all around the world – but most of the offices are sales, marketing and consulting, not core product development. That’s starting to change, though, with the rise of large development centers in Hyderabad, India; Beijing and Shanghai, China; Haifa, Israel; Dublin, Ireland; and here in the United States in Silicon Valley, Boston and North Carolina; there also is a center in Vancouver, British Columbia. Due to acquisitions, there are also a number of smaller sites doing product development all around the world, including in Portugal, France, Singapore, Germany, Norway, and Switzerland.
All of this places the Redmond-based teams in the midst of the distributed development challenge – how do you effectively manage software projects when you can’t gather all the people in a room for a quick meeting? Software, far more than other engineering disciplines, has long relied on informal communication methods (like hallway encounters) to solve problems, generate new ideas and communicate quick status.
Jeff’s post offers a number of good solutions, as does my former colleague, Eric Brechner. While I was part of Engineering Excellence at Microsoft (a team focused on improving the internal engineering tools, processes and people) I collected best practices and case studies on an internal site we called “http://distdev”. In this way, we helped teams new to distributed development learn the tips and tricks from their colleagues, as well as avoid common mistakes (e.g. we always schedule meetings at times convenient for the Redmond participants, and don’t bother adding a dial-in number or Live Meeting ID to allow people not in Redmond to attend. Sometimes just moving a 4 PM meeting to 10 AM makes a huge difference for the remote participants – while not really inconveniencing the Redmond participants at all. Another trick I’ve seen used where the time zone differences are particularly challenging is alternating who is inconvenienced – so during daylight-savings time in the U.S. we arrange meetings at times that are convenient for U.S. participants and inconvenient for our colleagues in India; during standard time in the U.S., Redmond participants would be inconvenienced as meetings would be held during normal working hours in Hyderabad. This also has the advantage of getting both sides (not just one) to experience the pain.
Ultimately, though, the goal isn’t pain but gain. Jeff’s and Eric’s posts referenced above have a number of good suggestions on how to achieve that. These come down to just a few basic rules: