«OpenScrum: Scrum methodology to improve shared understanding in an open-source community Saptarshi Purkayastha Department of Computer and Information ...»
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 . 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 . 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  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”.