«OpenScrum: Scrum methodology to improve shared understanding in an open-source community Saptarshi Purkayastha Department of Computer and Information ...»
OpenScrum: Scrum methodology to improve shared
understanding in an open-source community
Department of Computer and Information Science,
Norwegian University of Science and Technology,
Abstract: While we continue to see rise in the adoption of agile methods for software
development, there has been a call to study the appropriateness of agile methods in opensource and other emerging contexts. This paper examines Scrum methodology adopted by a large, globally distributed team which builds an open-source electronic medical records platform called OpenMRS. The research uses a mixed method approach, by doing quantitative analysis of source-code, issue tracker as well as community activity (IRC logs, Mailing lists, wiki) in pre and post Scrum adoption, covering a period of 4 years. Later we conducted semi-structured interviews with core developers and followed it up with group discussions to discuss the analysis of the quantitative data and get their views on our findings.
Since the project is "domain heavy", contributors (developers and implementers) need to have certain health informatics understanding before making significant contributions. This puts knowledge-sharing and "bus factor" as critical points of management for the community.
The paper presents ideas about a tailored Scrum methodology that might better suited for open-source communities to improve knowledge-sharing and community participation, instead of just agility
- Quantitative analysis of pre and post Scrum methodology adopted by the OpenMRS project over a period of 4 years.
- Interviews with core developers and focused group discussions with core and community developers to discuss the quantitative analysis and their views on findings of that data.
- Results indicate less agile, but improved shared understanding of design and code-base.
- More active participation in the community and developers feel more community focused.
- A modified scrum methodology is recommended that might be more suited to “domainheavy” and community-driven open-source projects Keywords: Agile software development; Scrum; Bus factor; Open-source software; Software Engineering; OpenScrum; OpenMRS;
This is the author's manuscript of the article:
Purkayastha (2014) - OpenScrum: Scrum methodology to improve shared understanding in an open-source community.
1. INTRODUCTION Appropriateness of agile methods for emerging contexts (open-source software (OSS), software as a service etc.), ranked first among the top 10 research agenda in the ISR special issue on Flexible and Distributed IS development . Yet, we have seen limited research on agile methods within open-source communities. A recent review by Jalali and Wohlin  highlights that Global Software Engineering (GSE) projects with Agile methods are extremely rare. This might be primarily attributed to lack of clear mention that an opensource community is following a certain agile methodology. Some researchers have asked if open-source software development is essentially an agile method . But. Koch  mentions similarities, but also points out differences between agile software development (ASD) and OSS development. Thus, until the software development method being used by a community can be evidently clarified to follow one of the fairly well understood agile methods, they cannot be claimed to be the same.
Early work on ASD focused on defining agile methods   , adoption of agile methods  , efficiency of agile methods  and then more recently focus on empirical studies about post-adoption issues of agile methods   and team management . While improved software quality is an observed output, the above researchers highlight “agility” as the most important criteria for adoption of ASD methods. “Agility” in such cases has been used to describe the ability to rapidly and flexibly create and respond to change in the business and technical domains. “Agility” is achieved by having minimal formal processes.
Often used concepts to describe “Agility” include nimbleness, quickness, dexterity, suppleness or alertness. These ideas suggest a methodology that promotes maneuverability and speed of response .
On the other hand, OSS communities are generally seen as a collaboration of individuals or organizations that participate in software development without contractual bindings, but rather enjoyment-based intrinsic motivation . Some researchers have suggested change in practices (like OSS 2.0)  , where OSS development is moving towards commercial participation. There is also more recent suggestion that OSS is still largely a combination of commercial ventures and volunteer contributions . Sustainability is often an issue in open-source communities where volunteer contributors “come-and-go” or choose their own tasks  . Sustainability of OSS is often described by using the term “truck factor” or “bus factor” i.e. the total number of key developers that would, if incapacitated (e.g., by getting hit by a bus), lead to a major disruption of the project . Another challenge that we see in open-source communities is to gather contributors in projects that are for a vertical domain (health-care, finance, human-resources, etc.) . In many cases, by strategic planning, paid developers will be assigned to work on open source products in vertical domains . If the revenue model for such planning falls short, the developers are moved to other projects.
In this paper, we look at OpenMRS (Open Medical Records System), an open-source electronic medical records platform, which has adopted a tweaked ASD methodology. Since, the project is in a vertical domain of health, it is hard to find skilled volunteers who continue for long periods. Maintaining high bus factor is important for the project’s sustainability.
The paper attempts to answer the following research questions:
RQ1. How does adoption of agile methods in OSS change community participation?
RQ2. Can agile methods increase sustainability in OSS communities?
Beyond the above research questions, through the case, we hope that the paper responds to the calls for research of agile methods in OSS development. The case also highlights the challenges and opportunities of switching to Scrum methodology. The case is an avenue for reflection on open-source communities towards metrics of community participation. This will help them understand how their community is at present and what can be done to improve community participation.
The paper is organized as follows. In the next section we look at some of the concepts from software engineering research and agile methodology that have framed the formative and reflexive parts in the research design. In section 3, we describe the mixed method research used for this paper. In section 4, we analyze the tailored use of Scrum sprints in the OpenMRS community and detail out some effects on the project due to use of Scrum. In the discussion section of the paper, we highlight that Agile Methods can be used for knowledge management in open-source projects, instead of focusing on only the agility aspects. Here, we also suggest a tailored Scrum method, we refer to as OpenScrum that might be suited to open-source communities. The last section of the paper concludes by suggesting evolution of agile methods in open-source communities.
2. CONCEPTUAL FRAMEWORK
More than a decade ago the Agile Manifesto clarified about the values of agile software development and put forth principles that can be adopted to meet those values. While much of the practices around agile software development have been promoted by practitioners and consultants, there has been a growing need to conceptualize “Agility” . Here, Conboy suggests that Agility comes from two concepts of Flexibility and Leanness. Although used interchangeably, there are conceptual differences between Flexibility and Agility and also between Leanness and Agility. Thus, to be considered agile, the methodology should contribute to creation of change, proaction in advance of change, reaction to change or learning from change. It should also contribute and not detract from perceived economy, perceived quality and perceived simplicity. These allow producing software which is continually ready, with minimum time and cost required to be put into use (ibid.).
While Agility in such terms is an overall measure of the organizational performance to deliver a software product, one should also consider how individual developer productivity is affected by the practice of agile development. While developer productivity has been a hotly debated topic, the 1993 IEEE standard for software productivity metrics defined it as “the ratio of output to the input effort that produced it”. Jones  identified 250 factors affecting developer productivity, while more simplistic summary still lists 15 factors . So instead of co-relating multiple factors that affect productivity, it is common to measure output such as in Changes in Lines of Code (CLOC) or Non-Commentary Source Lines (NCSL) .
Another measure of developer productivity through interactive participation has been suggested – mainly through the use of code reviews, comments on other people’s code, number of forks, network analysis of contributors .
We’ve seen case studies which suggest that communication, co-ordination and control problems in GSE have reduced due to use of agile methods such as Scrum and eXtreme Programming . This and similar research    suggests that distributed teams indeed benefit from using agile methods. From all of these cases, we see that there is some level of tweaking done to agile methodology to be relevant to the organization. Tailoring of methods has been observed to play an important role in benefits like reduction of code defects density, delivery ahead of schedule and accurate planning for future projects .
While this need for tweaking has been well documented, very little has been written about tweaking agile development to open-source projects. OSS projects might simply be GSE projects in the public domain. Yet, as highlighted in the introduction, sustainability of OSS projects that are managed through community contributions or those that involve multiple stakeholders with different interests, highlight the need for a different kind of tweaking. In all of the above research on GSE, and most research on agile methods , we see that management control for changing software development practices could be done by a limited number of stakeholders and all these stakeholders were either organizationally or contractually bound. Even in earlier mentioned GSE literature review , “Agile-Open” projects were largely centrally governed. In antithesis to these contexts, consider the Linux project, which in 2011 had 7800 developers for 800 different organizations and 75% of these developers are paid by companies to work on the Linux kernel. Is moving to an agile methodology possible for such a project? What kind of tweaking of agile method will be needed for such a community is an unknown proposition. May be using Linux as a poster-boy for open-source projects is not a useful exercise. But even in small open-source projects which have multiple stakeholders, working with the organizational challenges of adopting agile methods is highly relevant. Figure 1, shows the research design, where we attempt to study agility, as factors of change as described earlier by Conboy and attempt to discuss developer productivity in terms of community participation. The resulting tailored OpenScrum is an output of the research along with measures for community participation.
Figure 1: Use of Concepts in Research Design
The previously introduced concept of “bus-factor” can be understood as a function of knowledge distribution. The more widely distributed knowledge in a community; higher is the “bus-factor”. One needs to look at bus-factor also through decision making capacity. If a project has one person making all decisions, the bus-factor is 1 and if this person gets hit by a bus, the project is in jeopardy. Getting hit by a bus, should not be taken literally. It refers to any event that can lead to the unavailability of an individual to the organization. Thus, the processes of KM to increase bus-factor in a software development organization would result in spreading information and decision-making capacity . Infact, at this point in the paper, it is important to mention that the term “Scrum” was coined by Takeuchi & Nonaka , which is the agile development method used in the paper’s case. Important concepts from their research highlighted, “multi-learning” and organizational transfer of learning. Multilearning highlights the fact that learning by doing manifests itself along two dimensions – multiple levels (individual, group and corporate) and multiple functions. Knowledge is also transmitted in the organization by converting project activities to standard practice .
Thus, OSS project can be understood to follow an agile methodology when individuals as well as the community as a whole, implements agile principles and processes.
3. RESEARCH METHODOLOGY The research followed a case study methodology  to understand the effects of agile methods in its natural context. Case study method is also useful to study post-facto effects, where theory and research are in their formative stages . The research employs a mixed method approach  with initially taking an interpretive approach with quantitative methods and later interpretive approach with qualitative methods . Data collection was done from the issue tracking system (JIRA). Individual work units are henceforth referred to as tickets. We analyzed emails from mailing lists (developer [n=18318]; implementer [n=8316], announcement) and source-code; covering the period from Jan 2009 to Jan 2013.