Kalman Toth, NextGenID and Raleigh Ledet, Apple, Inc.
Software engineering teams are increasingly working at a distance from each other, and are often globally dispersed. Operating in distributed teams significantly increases the complexity of already complex software engineering tasks. This paper on distributed software teams is an experience report summarizing the conduct and outcomes of a practicum project completed under the auspices of the Oregon Master of Software Engineering (OMSE) Program at Portland State University during the winter and spring of 2010. The students in this program are software professionals with considerable hands-on experience developing software products and services, often working in distributed teams. They are well aware of the challenges of working in such distributed teams – that productivity is seldom as high for distributed teams as for collocated ones. Their industry experience, combined with the software engineering processes they learned, provided a unique opportunity for these mature students to learn more about how software teams collaborate effectively when they are geographically dispersed. By way of thoughtful and systematic experimentation they were able to progressively evolve a practical framework for defining and evaluating a kernel of distributed software processes.
The overall goal of this practicum project was to provide advice and guidance to distributed software teams, and to offer suggestions for further work in this field. The primary objective was to specify and evaluate selected software engineering processes adapted to support collaborative software teams. A secondary goal was to evaluate the processes using open source software or free-ware tools. The project focus was explicitly aimed at processes over tools – the software tools being the means rather than the ends for learning about such team collaboration. Although this experience report focuses on how the project was conducted, it also summarizes the principle results.
The practicum team consisted of eight students split into two sub-teams with slightly different distribution characteristics, as well as distinct, but related, responsibilities. Similar team-of-teams structures, of varying sizes, are not uncommonly found in practice. This thereby offered a unique opportunity to realistically emulate day-to-day activities, such as project management meetings, specification document reviews and code inspections, while performing the various stages of the software engineering lifecycle.
The project started with a clean slate, without limitations as to which processes would be explored and defined or which tools would be used. The project team was tasked to develop a project specification and development plan to meet the practicum objectives and to utilize tools to shape and evaluate the fruit of their work.
The emergent and evolutionary nature of the project informed the targeted results. More specifically, the students experimented with different collaboration processes and tools during the specification and planning phase of their work, which fed the implementation phase. This focused their attention on some of the distributed team collaboration building blocks – both base processes and representative foundation tools. Some of these were rejected, while others were kept and incorporated into their emergent processes. In other words, the students “ate their own dog food” in an evolutionary fashion as they progressively evolved towards their final work products.