Irwin Kwan

Awareness in the Wild: Why Communication Breakdowns Occur

Global software teams face challenges when collaborating over long distances, such as communicating changes in the project. During a four-month case study at IBM Ottawa Software Lab we observed the collaboration patterns of a multi-site development project team. In this period, we inspected project documentation, interviewed team leaders, attended project meetings, and spoke with developers to identify problems originated by the lack of awareness of changes related to the implementation of work items. Our observations show (1) that organizational culture has an effect on how developers are made aware; (2) that communication-based social networks revolving around particular work items are dynamic throughout development, and therefore awareness needs to be maintained in infrastructures of work; and (3) that information overload and communication breakdowns contributed to the generation of a broken integration build. We discuss these breakdowns in communication and implications for the design of collaboration tools that could mitigate these problems.

Collaboration Patterns and the Impact of Distance on Awareness in Requirements-Centred Social Networks

Because of intense collaborative needs, requirements engineering is a challenge in global software development. How do distributed teams manage the development of requirements in environments that require significant cross-site collaboration and coordination? In this paper, we report research that used social network analysis to explore collaboration and awareness among team members during requirements management in an industrial distributed software team. Using the lens of a requirements-centred social network to group team members who work on a particular requirement, we collected data to characterize requirements-centric collaborations in a project, and to examine aspects of awareness of requirements changes within these networks. Our findings indicate organic patterns of collaboration involving considerable cross-site interaction, in which communication of changes was the most predominant reason for interaction. Although we did not find evidence that distance affects developers awareness of remote team members who work on the same requirements, distance affected how accessible the remote colleagues were. We discuss implications for knowledge sharing and coordination of work on a requirement in distributed teams, and propose directions for the design of collaboration tools that support awareness in distributed requirements management.

Does Socio-Technical Congruence Have an Effect on Software Build Success? A Study of Coordination in a Software Project

Socio-technical congruence is an approach that measures coordination by examining the alignment between the technical dependencies and the social coordination in the project. We conduct a case study of coordination in the IBM Rational Team Concert project, which consists of 151 developers over seven geographically distributed sites, and expect that high congruence leads to a high probability of successful builds. We examine this relationship by applying two congruence measurements: an unweighted congruence measure from previous literature, and a weighted measure that overcomes limitations of the existing measure. We discover that there is a relationship between socio-technical congruence and build success probability, but only for certain build types, and observe that in some situations, higher congruence actually leads to lower build success rates. We also observe that a large proportion of zero-congruence builds are successful, and that socio-technical gaps in successful builds are larger than gaps in failed builds. Analysis of the social and technical aspects in IBM Rational Team Concert allows us to discuss the effects of congruence on build success. Our findings provide implications with respect to the limits of applicability of socio-technical congruence and suggest further improvements of socio-technical congruence to study coordination.

Requirements-Driven Collaboration: Leveraging the Invisible Relationships between Requirements and People

In this chapter we introduce requirements-driven collaboration, which is the collaboration of a cross-functional team of business analysts, designers, developers and testers during the development and management of requirements. We describe an approach that (1) constructs a requirement-centric social network which represents the membership and relationships among members working on a requirement and its associated downstream artifacts and (2) outlines a number of social network analysis techniques to study collaboration aspects such as communication, awareness , and the alignment of technical dependencies driven by development of requirements and social interactions. To demonstrate our approach, we discuss a case study that examines requirements-driven collaboration within an industrial, globally-distributed software team. Finally, we discuss implications regarding the use of our requirements-driven collaboration approach for research and practice.

Visualizing a Requirements-centred Social Network to Maintain Awareness Within Development Teams

When the requirements in a software system change, we should notify every contributor who participates in the analysis, design, implementation, and testing of the requirement to reduce rework. However, the network of contributors working on a requirement is constantly changing, making it not only difficult to seek expertise from other team members, but also difficult to send requirements-change information to team members. To promote communication and improve awareness among contributors working on the same requirement, in this position paper we suggest using a visual representation called a requirements-centred-social-network diagram. Using the social-network diagram, a contributor can learn about another contributor¿s communication patterns around the development of a requirement, or send requirements-change-awareness notifications to every member of a team working on the same requirement. This social network can automatically expand to include contributors who work on a requirement but may not have been included in a project plan. The requirements-centred social network therefore captures not only the relationships among an initial team, but also emergent relationships among peripheral contributors. We believe that, by providing visual feedback of communication patterns within a contributor¿s expanding social network and promoting communication among team members, we can improve awareness of the work done by other contributors and maintain awareness of requirements change.

The hidden experts in software-engineering communication (NIER track)

Sharing knowledge in a timely fashion is important in distributed software development. However, because experts are difficult to locate, developers tend to broadcast information to find the right people, which leads to overload and to communication breakdowns. We study the context in which experts are included in an email discussion so that team members can identify experts sooner. In this paper, we conduct a case study examining why people emerge in discussions by examining email within a distributed team. We find that people emerge in the following four situations: when a crisis occurs, when they respond to explicit requests, when they are forwarded in announcements, and when discussants follow up on a previous event such as a meeting. We observe that emergent people respond not only to situations where developers are seeking expertise, but also to execute routine tasks. Our findings have implications for expertise seeking and knowledge management processes.

Extending socio-technical congruence with awareness relationships

Coordination in software engineering is necessary for software teams. To study coordination, researchers need a a way to conceptualize and measure it|one such measure is socio-technical congruence. Within a team setting, awareness of others tasks and abilities enables coordination, but the conceptualizations for socio-technical congruence do not include awareness. In this paper, our goal is to include awareness in socio-technical congruence. To do this, we conduct an empirical investigation of a teams awareness behaviour. We examine how developers transmit awareness information in a global software-engineering environment in a project called Ship using direct observations, interviews, and a questionnaire. We found that team members were satisfied with using simple awareness mechanisms such as email and meetings. We also identified that experienced team members served as brokers and filled coordination gaps, and that team members used multiple types of media simultaneously. Based on this work, we propose an aggregated sociotechnical congruence measurement that can be used to specify multiple relationships, such as awareness relationships, as interactions that satisfy technical dependencies.

Investigating Collaboration Driven by Requirements in Cross-Functional Software Teams

challenge in software development, and requirements engineering inherits this challenge. By taking a requirements perspective on collaboration we can better understand how cross-functional teams coordinate work throughout the project life-cycle. In this paper we report on a case study of a global IT company that investigated requirements-driven collaboration in a cross-functional team. We studied collaboration by examining the congruence between the technical dimension of work and social relationships team members establish. We calculated the mismatch between the social and technical dimensions. Based on the results, we critically analyzed the applicability of congruence to the study of cross-functional software teams as well as the limitations of current socio-technical congruence measures, which have been applied to only study developer teams. Based on this work, methods to investigate congruence between the social and technical dimensions of work have to be extended to incorporate information about pre-defined structures in the organization. Keywords-collaboration; coordination; requirements; crossfunctional software team; socio-technical congruence.

Chat to succeed

Effective coordination within a project is one key factor to successful software projects. While research shows that communication structures can predict the outcome of an integration build, we would like to take a step further making recommendations about who should collaborate together. By leveraging information about artifact dependencies and communication among team members, we can recommend which gaps between dependencies and communication should be resolved to ensure a successful project.

Viewing Project Collaborators WhoWork on Interrelated Requirements

Project collaborators in a software development project need to stay aware not only of changes to requirements and other artifacts, but also of each others current work. The set of team members working on a requirement is dynamic, and team members who were not assigned to the requirement in the plan may be involved. If this requirement changes, those team members who are dependent on that requirement must be notified quickly before they do outdated work. However, project plans often do not provide an easy method of listing all of the emergent team members who should be notified of changes to a requirement. We propose a requirements-dependency diagram that displays interdependent requirements and team members who are assigned to these interdependent requirements. The visualization highlights prominent collaborators, lists each collaborator and each requirement only once, marks emergent collaborators, and is simple and clutter-free. By viewing this diagram, collaborators will know who to contact to notify others of changes to requirements, and can contact experts working on interrelated requirements.