Sustainable Software Development Through Overlapping Pair Rotation Todd Sedano Paul Ralph Cécile Péraire
Total Page：16
File Type：pdf, Size：1020Kb
Carnegie Mellon University From the SelectedWorks of Cécile Péraire September, 2016 Sustainable Software Development through Overlapping Pair Rotation Todd Sedano Paul Ralph Cécile Péraire Available at: https://works.bepress.com/cecile_peraire/35/ Sustainable Software Development through Overlapping Pair Rotation Todd Sedano Paul Ralph Cécile Péraire Pivotal University of Auckland Carnegie Mellon Unveristy 3495 Deer Creak Road Auckland Silicon Valley Campus Palo Alto, CA New Zealand Moffett Field, CA 94035, USA [email protected] [email protected] [email protected] ABSTRACT Keywords Context: Conventional wisdom says that team disruptions Extreme Programming, Grounded Theory, Code ownership, (like team churn) should be avoided. However, we have ob- Sustainable software development served software development projects that succeed despite high disruption. 1. INTRODUCTION Objective: The purpose of this paper is to understand Imagine being a software development manager when one how to develop software effectively, even in the face of team of your top engineers, Dakota, gives notice and is moving on disruption. to a new job opportunity. You are simultaneously excited Method: We followed Constructivist Grounded Theory. because the new position provides a great career opportu- We conducted participant-observation of several projects at nity for someone you respect, yet distressed that her depar- Pivotal (a software development company), and interviewed ture may exacerbate your own project. How will the team 21 software engineers, interaction designers, and product overcome this disruption? Your investment in this engineer managers. The researchers iteratively sampled and analyzed and her entire accumulated knowledge about the project is the collected data until achieving theoretical saturation. evaporating. Dakota developed some of the systems' tricki- Results: This paper introduces a descriptive theory of Sus- est, most important components. How long will it take the tainable Software Development. The theory encompasses other programmers to assimilate Dakota's code? How will principles, policies, and practices aiming at removing knowl- this affect their productivity and future development? edge silos and improving code quality (including discover- Conventional wisdom says that team churn is detrimen- ability and readability), hence leading to development sus- tal to project success and that extensive documentation is tainability. needed to mitigate this effect. Unfortunately, documenta- Limitations: While the results are highly relevant to the tion quickly becomes out-of-date and unreliable [17], under- observed projects at Pivotal, the outcomes may not be trans- mining this approach. During a Grounded Theory study, we ferable to other software development organizations with dif- observed projects succeed despite high disruption and little ferent software development cultures. documentation. This raised the following research question: Conclusion: The theory refines and extends our under- \How do the observed teams develop software effectively standing of Extreme Programming by adding new princi- while overcoming team disruption?" ples, policies, and practices (including Overlapping Pair Ro- Exploring this question resulted in a descriptive theory of tation) and aligning them with the business goal of sustain- \Sustainable Software Development." The theory explains ability. how a collection of synergistic principles, policies, and prac- tices help develop software effectively while overcoming team disruption. This is done by engendering a positive atti- tude towards team disruption, encouraging knowledge shar- ing and continuity, as well as prioritizing high code quality. CCS Concepts Here, team disruption refers to substantial ongoing changes •Software and its engineering ! Collaboration in in team composition, including team members joining or software development; Software development tech- leaving, as well as temporary vacations or leave of absence. niques; In Section 2, we present related work on Extreme Pro- gramming and team disruption. In Section 3, we review how we employed Constructivist Grounded Theory to de- Permission to make digital or hard copies of all or part of this work for personal or rive a descriptive theory supported by empirical data. We classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation also present the research context, introducing both the com- on the first page. Copyrights for components of this work owned by others than the pany and one of the five projects under study. In Section author(s) must be honored. Abstracting with credit is permitted. To copy otherwise, or 4, we describe the theory and how its principles, policies, republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. Request permissions from [email protected]. and practices work together to achieve software development ESEM ’16, September 08 - 09, 2016, Ciudad Real, Spain sustainability. In Section 5, we evaluate the theory using es- tablished criteria for evaluating a Grounded Theory. In the c 2016 Copyright held by the owner/author(s). Publication rights licensed to ACM. ISBN 978-1-4503-3691-8/16/06. $15.00 last sections, we examine threats to research validity, con- DOI: http://dx.doi.org/10.1145/2915970.2916002 sider future research, and conclude the research. 2. RELATED WORK tions, and resulting theory depend on the researcher's view" In Extreme Programming [4], Kent Beck describes a set of [26]. The two primary data sources were field notes collected interdependent practices that manage feature development during continuous participant observations of a seven-month (much like Scrum [24]), as well as technical practices that project and interviews with Pivotal software engineers, in- facilitate a collaborative team environment. Extreme Pro- teraction designers, and product managers. Interviews were gramming comprises 13 primary practices and 11 corollary recorded, transcribed, coded, and analyzed using constant practices. comparison. In addition, the first author was involved in One Extreme Programming practice, collective ownership, four other projects as participant-observer. simply means that \anyone on the team can improve any Grounded Theory immerses the researcher within the con- part of the system at any time." Beck contrasts collective text of the research subject from the point of view of the ownership with \no ownership" and \individual ownership." participants. As the research progresses, Grounded Theory With collective ownership, every developer takes responsi- allows the researcher to\incrementally direct the data collec- bility for the whole of the system. When developers see tion and theoretical ideas." The theory provides a starting opportunities to improve the code, they go ahead and im- place for inquiry, not a specific goal known at the begin- prove it if it makes their life easier [3]. Later, \collective ning of the research. As we interact with the data, the data ownership" was renamed to \shared code" [4]. influence how we progress and alter the research direction. One Extreme Programming practice contributing to col- When starting a Grounded Theory research study, the core lective code ownership is pair programming. Pair program- question is, \What is happening here?" [11]. Our initial core ming is where production code is created by two developers question was \What is happening at Pivotal when it comes working together at a single computer [4]. Extreme Pro- to software development?" gramming does not prescribe how pairs are formed or for how long a pair works together. Williams presents a pair 3.2 Participants rotation strategy for maintaining specialization, by \choos- The first author interviewed 21 interaction designers, prod- ing the right partner for the right situation" [30]. People are uct managers, and software engineers who had experience assigned modules of the code to own based upon expertise with Pivotal's software development process. They were and find partners from neighboring modules. While knowl- distributed across four different Pivotal offices. Interaction edge is shared with pairing, one person owns every story designers identify user needs predominately through user in- that touches their part of the system, building individual terviews; create and validate user experience with mockups; code ownership. In one case study, the project started with determine the visual design of a product; and support engi- a pair rotation strategy based on skillsets but evolved into neering during implementation. Product managers are re- a daily rotation determined randomly [28]. Some teams use sponsible for identifying and prioritizing features, convert- a pair programing matrix [1] (also called a pairing ladder ing features into stories, prioritizing stories in a backlog, and [9]) to track who has paired with whom for the purpose of communicating the stories to the engineers. Software engi- pairing people who have not paired recently. neers implement the solution. Participants were not paid for Truck Number is \The size of the smallest set of people their time. in a project such that, if all of them got hit by a truck, the project would be in trouble." [19]. Truck Number, or 3.3 Data Collection Bus Count, reminds management about the effects of dis- We relied on\intensive interviews," which are\open-ended ruptive events for a team.