What practices make distributed work teams effective?
I am interested in what practices make some distributed work teams more effective than others, and in how teams develop these practices. Understanding these questions is important because of the increased use of distributed teams for a wide range of knowledge work, of which software development is a prime example.
Open source software development teams are an interesting setting for studying these questions for several reasons: there are a lot of them, some of them have been quite successful at developing large and complex software systems, they operate primarily or exclusively via electronic communications and in many cases, nearly complete records of the interactions and the products are publicly accessible. To answer our research questions, we plan to compare the practices of more and less successful OSS development teams over time from several theoretical perspectives.
First, because of the documented importance of coordination for software development (Curtis, Krasner, & Iscoe, 1988; Kraut & Streeter, 1995), we will study practices used by teams to coordinate work. By coordination practices, we mean practices for managing dependencies among software modules, tasks and actors (Malone & Crowston, 1994). A specific example would be practices for assigning a unit of work to a developer capable of performing the work. In a commercial project, such an assignment would typically be done by a project manager. In an OSS project, a range of coordination mechanisms seem to be used, but exactly what these practices are has not been studied in detail.
Second, following on work by Crowston and Kammerer (1998), we will examine the development of “collective mind” (Weick & Roberts, 1993) in the teams. By collective mind, we mean the commonly held understandings of team members about their work, the team and the environment. We postulate that practices of successful teams will contribute to developing a collective mind and that a developed collective mind will enable a range of more effective practices.
Finally, in addition to documenting the practices of successful teams, we will study how these practices develop as teams form and as they evolve over time. For this question, we view teams as examples of communities of practice (Brown & Duguid, 1991; Wenger, 1998). An important question then is how new members are socialized into teams.
As an initial focus for our work, we are interested in the nature of the bug fixing process, which has been mentioned as a particular strength of the open source process. For example, we will being our study by answering questions such as: What is the process for handling bug report (i.e., what is the sequence of activities, who actually perform them, and how are dependencies managed)? How do projects handle symptom reports? How are bug fixes from diverse sources integrated and tested?
Brown, J. S., & Duguid, P. (1991). Organizational Learning and Communities-of-Practice: Toward a Unified View of Working, Learning, and Innovation. Organization Science, 2(1), 40-57.
Crowston, K., & Kammerer, E. (1998). Coordination and collective mind in software requirements development. IBM Systems Journal, 37(2), 227–245.
Curtis, B., Krasner, H., & Iscoe, N. (1988). A field study of the software design process for large systems. Communications of the ACM, 31(11), 1268–1287.
Kraut, R. E., & Streeter, L. A. (1995). Coordination in software development. Communications of the ACM, 38(3), 69–81.
Malone, T. W., & Crowston, K. (1994). The interdisciplinary study of coordination. Computing Surveys, 26(1), 87–119.
Weick, K., & Roberts, K. (1993). Collective mind in organizations: Heedful interrelating on flight decks. Administrative Science Quarterly, 357–381.
Wenger, E. (1998). Communities of Practice: Learning, Meaning, and Identity. New York: Cambridge University Press.