Summary: (Continued from yesterday) The Harvard Business Review article's authors describe three principles that guided the teams in their study. Given the success of those teams, one should consider these rules carefully: Rule 1: Exploit diversity. The team all tried to have a diverse membership rather than a homogeneous single-company team. This diversity provided a broader set of experience and backgrounds and a higher quality final result. As part of managing this diversity and the geographically distributed nature of the teams, the teams used conference calls rather than in-person meetings: * Using a conference call required a level of attention to detail "paid to soliciting and discussing everyone's opinions [which] makes for a far more detailed conversation than the sort teams have when they meet in person, where they can be led astray by excessive politeness." * And, to avoid some of the cliquishness that happens when there are multiple participants from the same company/group involved in the team, most leaders "[ensured] that everyone communicated in the same way, [by asking] those working at the same location to call in from their own desks, rather than from a conference room." Rule 2: Exploit Technology. There's a lot of great technology available now for distributed heterogeneous teams. The Eclipse Foundation offers some of it and we should probably offer more, but in the meantime, a few points from the article: * "Many in our study found e-mail a poor way for teams as a whole to collaborate." because "Trying to do the main work of the team through one-to-one exchanges between members can cause those not included to feel left out, diminishing trust in the group and leading ultimately to dysfunction." * The teams used a virtual work space (wiki?) for work in progress and status. They used conference calls only to discuss disagreements. These "[Virtual] work space was where the group was reminded of its decisions, rationales, and commitments." One of the best examples given in the article was one where the * One feature of the virtual workspaces that we (Eclipse projects) should adopt as a standard practice is the "people page". Some projects already have them (e.g., Webtools and EMF) but: o We should make these standard and automatic for all projects, and o The Harvard Business Review article described a very nice such page where people's pictures were laid out in a circle. This had the advantage that "during teleconferences, [team] members adopted the practice of identifying themselves by their position on the clock: "This is Kate at ten o'clock" ". * Another technology that the teams used was live meeting notes: "In the beginning, I took minutes on a pad of paper and sent them out later, but no one ever comment on anything. So I switched to taking minutes during the meeting so that everyone could see them on their screens. People would comment and correct things as we went along, which meant the minutes that I posted in the team room immediately after the meeting were accurate reflections of what we'd decided." Rule 3: Hold the Team Together As the authors state: "The hazards that commonly threaten to splinter face-to-face teams - mistrust, cliques, uninformed managers, and the allure of other interesting but unrelated work - can be even more pronounced on a virtual team." So it takes a solid leader to create a very effective distributed, heterogeneous team. I believe the Architecture Council should work towards writing a "How To" Guide for Eclipse project leaders outlining the successful, and unsuccessful, practices around Eclipse technical and project leadership. In conclusion, the authors state: that "when small groups adopt the kinds of practices our teams have demonstrated, they can work faster, smarter, more creatively, and more flexibly than dispersed individuals or the enterprise as a whole." And of course that's the goal of having an Eclipse project: to tap the greater power of the larger Eclipse community in creating a better extensible framework than one could build by oneself. posted by Bjorn Freeman-Benson at 1:54 AM

Summary: Scott Lewis pointed me to the Harvard Business Review article "Can Absence Make A Team Stronger?" by Ann Majchrzak et al. and while reading it, I was struck by the number of lesson that Eclipse open source projects can learn from this study. 1. Eclipse projects have typically been implemented by a small co-located team (not all projects, but most of them). This research shows that that arrangement isn't required to be productive. In fact, "far-flung teams can be remarkably productive, even outperforming groups whose members work side-by-side" * It's that last phrase that really caught my eye. 2. Eclipse projects are a good fit with the kinds of projects these authors studied. " "When a project requires diversity of competencies and perspectives and work can be done by means of electronic documents and tools, it's better to opt for a far-flung team than for one that works face-to-face. Such teams not only have a wider variety of communication channels at their command but also are free of many of the psychological and practical obstacles to full and effective participation that hobble their traditional counterparts." * Eclipse projects are almost entirely done with electronic documents (e.g., wikis, mailing lists, newsgroups) and tools (e.g., Eclipse itself, CVS/SVN). * So what are these obstacles? 3. "For instance, several team members mentioned that they contributed much more during virtual meetings than they would have during virtual meetings than they would have in face-to-face settings. They said they felt compelled to articulate their views more persuasively than if they had depended on visual cues." * and 4. "Decisions in complex projects have to be made continually. Postponing them until everyone assembles slows everything down - way, way down. If such a meeting was in the offing, everyone expects it to be where the real work will take place and avoids doing anything of value until the meeting occurs." and thus teams should: "Blur the distinction between time spent at meetings and time spent away from them through the use of always open, on-line team rooms." * In other words, Eclipse open source projects should make more use of the online tools (or ask for better online tools). Projects should strive to have fewer in-hallway meetings and more on-the-web meetings; fewer on-whiteboard discussions and more on-wiki discussions; etc., and that doing these things will result in greater productivity rather than less. More about the article's authors' three principles for distributed teams (team composition; use of technology; team interaction) next time. posted by Bjorn Freeman-Benson at 4:33 PM