FREE ELECTRONIC LIBRARY - Dissertations, online materials

Pages:     | 1 | 2 || 4 | 5 |

«OpenScrum: Scrum methodology to improve shared understanding in an open-source community Saptarshi Purkayastha Department of Computer and Information ...»

-- [ Page 3 ] --

Also since most developers were themselves the maintainers of the modules, they would rarely get useful responses to resolve an issue. As one developer quoted, “My module was considered to be black magic that just worked. No one else looked at it and if anything broke, I would be the only person to know where to quickly find it. Instead of showing someone else how to fix it, I’d go and fix it myself”. While most developers were comfortable doing this, if a developer went to vacation or was helping out an implementation, tickets belonging to that developer’s module would be ignored. Bugs remained unfixed and changes took longer to release. Bus-factor in such cases was 1 for many modules and more than 83% of the modules did not receive updates, even though feature requests were made by implementers.

OpenMRS also maintains 2 previous versions, after a new version of core is released. The process of releasing maintenance versions of previous releases is done through the use of what is commonly referred to as backporting of a fix. New features are rarely added to maintenance releases, but sometimes highly voted and relevant features are indeed backported. But in general, maintenance releases only contain bug fixes. While this is useful for implementations to use only the stable functionality, the process of backporting is a time consuming process and there is some lack of clarity in what is allowed to be backported (bug fixes), but sometimes new releases of external libraries, data model changes have also been included in maintenance releases. In Table 2, you can see the release cycles for major version releases. Maintenance releases have not been included for the core, but the bundled modules have their maintenance release distributed and those have been included in the table.

Only tickets on which work started and finished between the release period have been counted and long pending or worked on tickets have been ignored. A detailed analysis between of maintenance releases of core and modules is done later in the paper, when we compare the change in performance after adopting Scrum methodology in section 4.3 below.

–  –  –

While it takes months before large OpenMRS implementations move to a new release, maintenance releases allow implementations to fix bugs and get important performance benefits. As one implementation-support developer quoted, “The 1.8.0 release was a paradigm shift in how we were fixing issues to deal with implementations. There were 2 quick maintenance releases made because of performance improvements. Supporting large implementations is about running the right modules, with the right core”. In similar light, a core developer mentioned, “Implementations differ from each other because of the modules that they use. So, when implementation-support developers commit code, it is to the modules that they use in production. They care less about the core, unless something is breaking a module”.

While the realization that core was getting less relevant for the implementations, it is also understood by the developers that modules needed to be developed at a separate pace from the core. OpenMRS started “Sprinting” using the scrum methodology between the 1.7.1 and 1.8.0 release. The scrum methodology as adopted by OpenMRS community is described in the next section.

4.2. Adopting a tailored Scrum methodology Scrum is a popular agile software development methodology that focuses on project management in situations where it is difficult to plan ahead; where feedback loops constitute the core element [48]. The core aspect of scrum is the “time-boxed” effort called sprint to complete a set of tasks known as sprint backlog, which have been selected from a larger product backlog [49]. Instead of discussing general aspects of Scrum methodology, which is well understood and can be read elsewhere, we focus on the use of scrum in OpenMRS. From here on, this is referred to as OpenScrum.

OpenMRS sprints are designed in a way that all participating developers – core, organizationbacked as well as community developers work together in sprints of 1 or 2 weeks depending on the module or task at hand. The sprint duration is generally suggested by one developer (who knows the module) or project leader based on their guess of the complexity at hand and from roadmap requirements from implementer meetings. Sprints are also sometimes proposed by developers from the community, implementers or core developers. A sprint schedule is advertised 2 weeks in advance through the developer mailing list and planning starts by nominating or volunteering a Sprint leader. The Sprint leader should be a developer, with adequate knowledge about the module. This developer decides the sprint backlog, by creating new tickets or allocating existing tickets from the product backlog for the sprint.

This process is somewhat different from the general role played by Stakeholders and Product Owners in textbook Scrum method. The OpenMRS sprints have the community as the Product Owner and the community as a whole decides what tickets to prioritize by voting on tickets. Although, this has been contentious within the implementer community because core developers have higher chances to influence voting. Also implementations which do not have developer resources are under-represented in such voting schemes. The list of developers who are participating in the Sprint is continuously updated in the sprint schedule. The Sprint leader has to monitor the list of participants so that the tasks that need to be completed in the sprint do not exceed the amount of time that would be required to complete the product backlog. These estimates are fairly complex to make since time estimate of independent developers cannot be accurately made by the Sprint leader. Sometimes, although independent developers self-nominate to participate in Sprints, they do not actively engage and do not spend adequate time during the Sprints.

Figure 2: A high-level view of the OpenMRS Scrum

During the planning phase, the design calls play a vital role to translate requirements into working tasks as tickets and to make a guess about what tasks can be completed. OpenMRS involves community members along with a Business Analyst role to complete this process.

Implementers are ideally useful for this process, but lack of participation from them, has made the role of Business Analyst to be more important. Community developers signup for the sprint during this period and FTEs from OpenMRS are allocated to the project before or during the design calls. The output of the design call is the creation of a RapidBoard, which lists out all the activities that need to be completed in the sprint along with their priorities.

Figure 3, shows an example RapidBoard, which is representation of the Sprint backlog.

Figure 3: The OpenMRS Scrum RapidBoard

The RapidBoard is essentially an information radiator [14] like a pinup board that is updated automatically and shows the status of a sprint. The OpenMRS sprint starts with a kickoff meeting, which is generally at the IRC. The goals of the sprint, what steps to follow, how to commit code, how to review code, how to merge, what unit tests to write etc. is discussed in this meeting. The prioritized tickets are described in the meeting and community developers introduce themselves to each other during this kickoff meeting. The appropriate wiki pages are highlighted in the meeting; so that new developers can become well versed with some design decisions as well as coding standards to be followed for the sprint.

The OpenMRS sprints also do not have a clear role for a ScrumMaster. A project coordinator has recently played the role of the ScrumMaster, yet it is unclear how this role has been used to enforce rules. In textbook Scrum, the ScrumMaster is intended to protect the team from distracting influences, ensure that the rules of sprint are followed and help in gathering resources for sprints. When moving to Scrum methodology, OpenMRS did not have the role of a ScrumMaster. Since July 2012, a ScrumMaster role has been defined, yet activities of the role are vague in OpenMRS. There has been training through OpenMRS University conference calls to explain to the community, the different processes that are followed in OpenMRS scrum. These university calls have had limited participation and there is lack of clarity in the conceptual terms that are part of the followed methodology. In one of the group discussions of community developers highlighted this, “We would like to have implementers to be ScrumMaster”. Another developer disagreed, “May be Scrum leader needs to be a developer, but Product Owner should be a single individual instead of the community, so that this person can tell us that the module is ready to be released”. This shows some conceptual lack of understanding among the developers regarding the scrum methodology in practice and textbook definitions of roles in Scrum.

The OpenMRS implementers mailing list (n=8316) receives about half the amount of traffic compared to the developers list (n=18318). More than 65% of the responses even on the implementers mailing list is from developers. At least from the people who interact openly, we can infer that the OpenMRS community is largely developer driven. This highlights the problem of getting an active role for Stakeholders as well as Product Owner. For instance, when there was an announcement made to organize roadmap meetings which would enable community members to prioritize issues, to create a product backlog that will be used in sprints, after 4 months of attempts to meet, there was no active participation in these calls.

Thus, the role of Stakeholders in most sprints has been largely absent. The Product Owner is also different for each sprint, depending on the module being developed in the sprint.

As the sprints continue, there is a daily standup meeting in the IRC, where developers mention what they’ve been working on and highlight if they have any blockers. Blockers are attempted to be resolved by advice from the core developers soon after the standup meeting.

The RapidBoard keeps changing but does not include any time for preparing for release.

Merging pull requests, documenting changes, prepare documentation for release are supposed to be done by the Scrum leader, but the OpenMRS scrum model does not have separate time allotted for these kinds of work. The Scrum leader announces at the end of a sprint the results

in terms of tickets completed, burndown chart etc. Figure 4 is an example:

Figure 4: Burndown chart Figure 5: Planning board from Epic to tickets

4.3. Findings and Analysis of the OpenMRS Methodology While it is evident and somewhat expected that any change in development methodology will result in initial slowdown, we do see that some degree of inefficiency in the way OpenMRS moved to the new methodology. Let us look at the OpenMRS methodology in terms of the Taxonomy of Agility described earlier. It is a combined interpretation of Flexibility and Leanness. Table 3, summarizes the findings after analyzing the parameters.

Table 3: Agility parameters for OpenMRS Agility Interpretation Leanness Interpretation Creation of change  Good increase Perceived economy  Unclear (NA) Proaction before change  Little increase Perceived quality  Good Increase Reaction to change  Moderate increase Perceived simplicity  Slight decrease Learning from change  Good increase

Figure 6: Tickets resolved in each release

Creation of change Creation of change in a software artifact can be seen from a few different angles. Releases are one way to look at it. We looked earlier that the number of days to release had increased, but that’s only the core releases. There was a concerted transition to focus from core to releasing modules quickly. In Figure 6, we see that although there is a clear increase in the tickets resolved over the releases, the number of participating contributors have also increased. Thus, the average contributions (normalized to 40 contributors) in terms of resolving tickets have not really drastically increased. Though it is interesting to observe that after shifting to OpenScrum, there has been stability in the avg contributions from the community. Another interesting fact is that although the focus has indeed shifted to modules, the bundled modules are not the ones that have shown dramatically higher signs of extra work. They seem to be getting the same amount of work done as earlier.

As mentioned in the research design, contributor productivity is another factor of study.

Figure 7 shows the CLOC for the top 5 code contributors every month. These are not the same developers, but the top contributors in terms of CLOC to the project for each month.

We see that soon after adopting the Scrum methodology the CLOC of the developers went down, but over time the top 5 developers have been committing equal amount of code to the project. This shows that individual developer productivity has become less disparate since adopting OpenScrum.

Figure 7: CLOC for top 5 developers Proaction in advance of change & reaction to change Lean organizations are often considered to be proactive to change and visionary leaders have the wisdom the see the incoming change in market conditions (Takeuchi & Nonaka, 2011).

Out of the total of 48 sprints between Mar 2011 and Jan 2013, there have been 25 sprints that have been on Core (n=19) and Bundled modules (n=6). Others have been on experimental features (referred to as spikes i.e. sprint by 1-2 FTEs) or popular community modules. Yet, as one lead developer commented, “We wait till something is upon us and then we start experimenting in spikes”. Another developer added, “We’ve needed 2 or 3 spikes before anything experimental has been converted to usable modules. Look at RESTWS or OCC”.

Pages:     | 1 | 2 || 4 | 5 |

Similar works:

«Elina Penttilä Predictive Factors in Endonasal Endoscopic Lacrimal Surgery Publications of the University of Eastern Finland Dissertations in Health Sciences ELINA PENTTILÄ Predictive Factors in Endonasal Endoscopic Lacrimal Surgery To be presented by permission of the Faculty of Health Sciences, University of Eastern Finland for public examination in the Medistudia 3, University of Eastern Finland, Kuopio, on Friday, February 14th 2014, at 12 noon Publications of the University of Eastern...»

«Asymmetry in action: Sequential resources in the negotiation of a prescription request* JEFFREY D. ROBINSON Abstract This article deals with one form of interactional asymmetry in doctor± patient consultations, that of initiative: Doctors primarily initiate actions and solicit responses, whereas patients primarily respond to doctors' initiatives. This article argues that the variable of initiative actually contains two dimensions: speaker initiative and utterance constraint. It then reviews...»

«Diabetes Friendly Recipes From Your Evergreen Community Dear friends, This cookbook is the work of your Evergreen Diabetes Patient Family Advisory Council, made possible by a grant from the Evergreen Healthcare Foundation. We are committed to enhancing the lives of people living with diabetes and the people who support them. You are our concern, our focus, and our mission. To assist you in managing your diabetes, or that of a loved one, we offer this collection of recipes, contributed by...»

«Graduate Centre for Medieval Studies The Reading Medievalist: A Postgraduate Journal The Graduate Centre for Medieval Studies, University of Reading Selected Proceedings from ‘The Maladies, Miracles and Medicine of the Middle Ages’, March 2014 Legacy, J. ‘Reading the Body: A Textual Analysis of ‘The Interpolated Middle English Version of the Anatomy of Guy de Chauliac’ Selected Proceedings from ‘The Maladies, Miracles and Medicine of the Middle Ages’, March 2014. The Reading...»

«ANTIOXIDANT AND ANTIMYCOBACTERIAL ACTIVITIES OF BASIL (Ocimum gratissimum) EXTRACTS OBTAINED BY SFE Patrícia F. Leal1, Daisy N. Sato2, F. Célio M. Chaves3, Lin C. Ming3, Marcia O. M. Marques4, M. Angela A. Meireles1* LASEFI – DEA / FEA (College of Food Eng) – UNICAMP, Cx. Postal 6121, 13083-970 Campinas, São Paulo, Brazil; 2Instituto Adolfo Lutz – Laboratório de Ribeirão Preto, Rua Minas, 877, Campos Elísios, 14085-410, Ribeirão Preto, São Paulo, Brazil; 3Plant Production...»

«Picture adapted from https://lh5.googleusercontent.com/a-4f4RpVP258BsJVSTowyCMQlsXqP1Yxf7qr1vVwm0dlgNpcloBesxIS zcsb3KU1Hd-N72JFiyn2erdg0np7VBand-Aids Don’t Fix Bullet Holes: Benzodiazepine use in Posttraumatic LXU1YdelxsB0hmL9XkLBdhqL1yos2vDiHyn-7SpGAQw Stress Disorder Patients. Brendon Hogan, PharmD PGY-1 Pharmacy Resident Division of Pharmacotherapy, The University of Texas at Austin College of Pharmacy Central Texas Veterans Health Care System, Temple, Texas Pharmacotherapy Rounds October...»

«Department of Health and Human Services OFFICE OF INSPECTOR GENERAL REVIEW OF OUTPATIENT SURGERIES BILLED BY HAZEL HAWKINS MEMORIAL HOSPITAL Inquiries about this report may be addressed to the Office of Public Affairs at Public.Affairs@oig.hhs.gov. Lori A. Ahlstrand Regional Inspector General for Audit Services August 2014 A-09-13-02053 Office of Inspector General https://oig.hhs.gov The mission of the Office of Inspector General (OIG), as mandated by Public Law 95-452, as amended, is to...»

«SUPREME COURT OF MISSOURI en banc AMY DIFATTA-WHEATON, ) ) Appellant, ) ) v. ) No. SC89239 ) DOLPHIN CAPITAL CORPORATION, ) ) Defendant, ) ) DIVISION OF EMPLOYMENT SECURITY, ) ) Respondent. ) PETITION FOR REVIEW OF A DECISION OF THE LABOR AND INDUSTRIAL RELATIONS COMMISSION When Amy Difatta-Wheaton (Claimant) 1 was diagnosed with ovarian cancer, she was required to miss work to receive the emergency medical treatment she needed to save her life. This disease was certainly not her fault, nor a...»

«Vision Care Program (VCP) All Employees Effective: January 1, 2016 Program Summary Important This Program Summary applies to all employees, effective January 1, 2015. For more information on other benefit programs under the Sandia Health Benefits Plan for Employees, see the Sandia Health Benefits Plan for Employees Summary Plan Description. The Vision Care Program is maintained at the discretion of Sandia and is not intended to create a contract of employment and does not change the at will...»

«Eye on the Border From the Files of a Pediatric Ophthalmologist Violeta Radenovich, M.D., M.P.H. (corresponding author) Children’s Eye Center of El Paso Albert M. Balesh, M.D. Children’s Eye Center of El Paso Address reprint requests to: Violeta Radenovich, M.D., M.P.H. Children’s Eye Center of El Paso 1250 E. Cliff Drive, Suite 4-D El Paso, Texas 79902 Phone: (915) 577-9339 Fax: (915) 541-1237 www.childrenseyecenter.com The authors have no commercial or proprietary interest in ifa...»

«WHO/V&B/01.30 WHO/BCT/01.02 ORIGINAL: ENGLISH DISTR.: GENERAL Tool for the assessment of injection safety DEPARTMENT OF VACCINES AND BIOLOGICALS World Health Organization Geneva The Departments of Vaccines and Biologicals and Blood Safety and Clinical Technology thank the US Agency for International Development (USAID), the Canadian International Development Agency (CIDA) and other donors, whose financial support has made the production of this document possible. This document is also part of a...»

«Chapter 74: Malignant Neoplasms of the Oropharynx Stanley E. Thawley, Michael O'Leary Proper evaluation and treatment of tumors of the oropharynx require knowledge of the anatomy, staging, etiology, histopathology, and clinical behavior of the cancer; of the various options for treatment; and of the proper management of immediate and long-term complications. Generally a team, including an otolaryngologist, radiation therapist, medical oncologist, prosthodontist, speech therapist, and nursing...»

<<  HOME   |    CONTACTS
2016 www.dissertation.xlibx.info - Dissertations, online materials

Materials of this site are available for review, all rights belong to their respective owners.
If you do not agree with the fact that your material is placed on this site, please, email us, we will within 1-2 business days delete him.