Patrick Wagstrom

Identification of coordination requirements: implications for the Design of collaboration and awareness tools

Task dependencies drive the need to coordinate work activities. We describe a technique for using automatically generated archi-val data to compute coordination requirements, i.e., who must coordinate with whom to get the work done. Analysis of data from a large software development project revealed that coordina-tion requirements were highly volatile, and frequently extended beyond team boundaries. Congruence between coordination re-quirements and coordination activities shortened development time. Developers, particularly the most productive ones, changed their use of electronic communication media over time, achieving higher congruence. We discuss practical implications of our technique for the design of collaborative and awareness tools.

Tesseract: Interactive visual exploration of socio-technical relationships in software development

Software developers have long known that project success requires a robust understanding of both technical and social linkages. However, research has largely considered these independently. Research on networks of technical artifacts focuses on techniques like code analysis or mining project archives. Social network analysis has been used to capture information about relations among people. Yet, each type of information is often far more useful when combined, as when the “goodness” of social networks is judged by the patterns of dependencies in the technical artifacts. To bring such information together, we have developed Tesseract, an interactive exploratory environment that utilizes cross-linked displays to visualize the myriad relationships between artifacts, developers, bugs, and communications. We evaluated Tesseract by (1) demonstrating its feasibility with GNOME project data (2) assessing its usability via informal user evaluations, and (3) verifying its suitability for the open source community via semi-structured interviews.

Dependency forecasting in the distributed agile organization

55 oordination, or the management of dependencies among tasks, can be accomplished in a number of ways in software development projects. Coordination mechanisms include such things as a defined software process, a well-documented software architecture, and detailed project planning. Agile methods tend to eschew these formal coordination mechanisms in favor of frequent, intensive, informal communication among team members and with the customer. Research has consistently shown, however, that communication across sites in geographically distributed projects is severely attenuated compared to communication in co-located projects. This strongly suggests that in order for agile methods to be effective in distributed projects, great care must be taken to ensure that the necessary communication takes place. Agile methods encourage very short planning horizons, and the

Supporting enterprise stakeholders in software projects

Today, large enterprises create a significant body of commercially available software. As a result, the key stakeholders include not only those typically responsible for software development, but also stakeholders not typically involved in software engineering discussions. Current software development approaches ignore or poorly manage these enterprise level concerns. This hampers the ability to create connections among the stakeholders responsible for enterprise wide issues, the development team, and the artifacts with which they are concerned. In this paper we identify a set of propositions for coordination in enterprise software engineering environments and describe a preliminary framework to support such interactions.

The problem of private information in large software organizations

Coordination of project stakeholders is critical to timely and consistent software delivery. In this short paper we present the problem of private information as a guiding framework or lens through which to interpret coordination dynamics within software organizations. We provide evidence of this problem in the form of specific challenges, collected via interviews from a diverse set of extended (i.e., non-development) stakeholders in a globally distributed software development organization.

Does latitude hurt while longitude kills? geographical and temporal separation in a large scale software development project

Distributed software development allows firms to leverage cost advantages and place work near centers of competency. This distribution comes at a cost -- distributed teams face challenges from differing cultures, skill levels, and a lack of shared working hours. In this paper we examine whether and how geographic and temporal separation in a large scale distributed software development influences developer interactions. We mine the work item trackers for a large commercial software project with a globally distributed development team. We examine both the time to respond and the propensity of individuals to respond and find that when taken together, geographic distance has little effect, while temporal separation has a significant negative impact on the time to respond. However, both have little impact on the social network of individuals in the organization. These results suggest that while temporally distributed teams do communicate, it is at a slower rate, and firms may wish to locate partner teams in similar time zones for maximal performance.

A network of Rails a graph dataset of Ruby on Rails and associated projects

Software projects, whether open source, proprietary, or a combination thereof, rarely exist in isolation. Rather, most projects build on a network of people and ideas from dozens, hundreds, or even thousands of other projects. Using the GitHub APIs it is possible to extract these relationships for millions of users and projects. In this paper we present a dataset of a large network of open source projects centered around Ruby on Rails. This dataset provides insight into the relationships between Ruby on Rails and an ecosystem involving 1116 projects. To facilitate understanding of this data in the context of relationships between projects, users, and their activities, it is provided as a graph database suitable for assessing network properties of the community and individuals within those communities and can be found at https://github.com/pridkett/gitminer-data-rails.

Coordination in innovative design and engineering: observations from a lunar robotics project

Coordinating activities across groups in systems engineering or product development projects is critical to project success, but substantially more difficult when the work is innovative and dynamic. It is not clear how technology should best support cross-group collaboration on these types of projects. Recent work on coordination in dynamic settings has identified cross-boundary knowledge exchange as a critical mechanism for aligning activities. In order to inform the design of collaboration technology for creative work settings, we examined the nature of cross-group knowledge exchange in an innovative engineering research project developing a lunar rover robot as part of the Google Lunar X-Prize competition. Our study extends the understanding of communication and coordination in creative design work, and contributes to theory on coordination. We introduce four types of cross-team knowledge exchange mechanisms we observed on this project and discuss challenges associated with each. We consider implications for the design of collaboration technology to support cross-team knowledge exchange in dynamic, creative work environments.

A dive into online community properties

As digital communities grow in size their feature sets also grow with them. Different users have different experiences with the same tools and communities. Enterprises and other organizations seeking to leverage these communities need a straightforward way to analyze and compare a variety of salient attributes of these communities. We describe a taxonomy and tool for crowd-sourcing user based evaluations of enterprise relevant attributes of digital communities and present the results of a small scale study on its usefulness and stability across multiple raters.

Engineering software engineering teams

This paper presents novel ideas for understanding how software engineering teams communicate and coordinate. We utilize these ideas to understand how these teams should be constructed and what individuals and managers can do to ensure that teams perform at high levels. Our view is based on numerous observations and interactions with enterprise software engineering teams and influenced by economic models of information sharing. We propose that neither a fully top-down nor bottom-up approach is entirely suitable for teams; rather teams must be cognizant of this issue and work to embrace both models of information flow. This, in turn, can be facilitated by the role of intercessor who seeks to properly guide, direct, and curate both top-down and bottom-up information flows.