Collocation in Distributed Development

No, collocation in distributed development is not an oxymoron -- and I have decades of experience behind my statement. SDForum and SAP hosted a panel for SAP's global managing directors of their distributed development groups. (Distributed development is how enterprise software (and much other software) gets built.) The decades of experience were provided by Richard Baird (IBM), Cherie Gardiner (Microsoft), Suzanne Kirkpatrick (Microsoft), George Mathew (SAP), Clas Neumann (SAP), and Jeff Pettibone (NetApp) who each talked about the variety of global sites that form the centers of excellence in their production processes. I had the honor of moderating the discussion, which focused on these three questions:
  1. What technique/tool/strategy have you tried, and then abandoned/adjusted? What was the critical issue?
  2. What have you learned from other companies about the process of distributed development?
  3. What are you hoping to do in the future?
Strikingly, no technology tools were mentioned. I know the supporting development and collaboration tools are important to the distributed development model -- but tools were not at the heart of these executives' comments. The focus was instead on organization practices and the motivation and development of the people in their organizations. When is it worth is to collocate?
  • When something is going wrong. One example focused on a situation where two teams were tasked with different parts of project. Instead of focusing on their assigned bit, they become competitive and each designed a prototype of the full model -- not an efficient approach (though there could have been innovation benefits if the best of both models were integrated -- but certainly not efficient). Solution? Collocating sections of each team with the other. This approach echos one an earlier field study on distributed teams and performance (Babba et al., 2004 pdf).
  • When the organizational practice begs for it. Scrum meetings at critical junctures. Certainly many scrum meetings take place in a distributed form, but the energy expected is hard to achieve when portions of the team are up in the middle of the night to participate.
  • When you want to learn. One of the execs described how much value his organization had gained from spending time collocated at other organizations. One thought was that this is more likely to go well if you are talking about non-HQ groups (fewer boundaries and concerns to overcome). Idea is that spending a day a week, or a month a year, with another organization will open your eyes to different approaches.
Intentional decision making was another key point in this discussion: Being intentional and explicit about where different tasks are placed; intentional in terms of talent skill set, the career development opportunities provided to the employees, and the life-cycle of the project. Even without technology examples, this was TOP Management. I expect this panel and audience had a clear vision and control over over their supporting technology options -- the interesting discussion for them was for the organizational and people components.

Subscribe to Quick Insights You Can Use