«OpenScrum: Scrum methodology to improve shared understanding in an open-source community Saptarshi Purkayastha Department of Computer and Information ...»
This adheres to OpenMRS’s vision of using the “Story of Floss” – “Whenever possible, start with the floss (sic: dental floss). See the solution through end-to-end, since this is often the best way to understand the problem and informs the next pass at the solution. In the end, it is rare that we fully understand the problem until the third iteration of the solution. Be agile, open to corrections, and iterate on your solutions. But, most importantly, take action”. From these we might infer that due to sprints and spike-style development, experimentation and chances for innovation have increased. For example, 9 sprints in this period have happened on experimental features that aren’t considered to be traditional EMR platform features.
These sprints do not directly benefit the large OpenMRS community. Also, decision to run such sprints have not been debated in the OpenMRS community. The leadership of the OpenMRS due to political or with motivations to increase OpenMRS adoption have allocated such sprints. On the other hand, one could also argue that experimental spikes results in lower quality, but better chances of innovation. Quality might be improved in subsequent iterations, if an innovative solution has been found. Thus, we could summarize that we see only moderate to low levels of proaction in advance of change and moderate increase in reaction to change due to adopting this methodology.
Learning from change There have been 6 sprints on the RESTWS module and each time there was decreasing activity in the number of issues resolved as well as CLOC. This might point to stabilization of code, while moving from experimental spike to quality improvement sprints on which all the devs work together. The number of reported bugs against RESTWS has decreased with each release of the module. Another vital aspect has been that all developers now work on same part of the system and learn similar lessons. As mentioned earlier, developers now learn more and look at varied pieces of code that they would earlier not work on. This includes writing code, as well as reviewing code submitted by other developers. This allows the developers to learn much more and adapt to the different coding styles of developers.
Perceived economy, quality and simplicity As part of this research, we’ve not analyzed factors that look at the economy or cost of the development process. During the interviews the managers did not have any kind of costestimates before or after the change in the development methodology. Thus no direct or indirect observations could be made on the economic parameter.
The perceived quality of the code has been accepted to be better by the developers as well as the community in general. In 2010, a practice of continuous integration was adopted, which ran unit tests as soon as any code was committed. Along with this, a practice that 2 core developers will need to review code before any ticket gets closed. Although this ensured quality, it was often only the 2 lead developers who would review code. Other developers including community developers would hardly comment or do formal code reviews. With the change to OpenScrum, more community developers are reviewing code and commenting on each other’s code. This is because the developers are watching each other’s changes more closely. As one core developer highlights, “Now missing javadoc comments like @since for newly introduced methods is suddenly more obvious to reviewers. Also writing unit tests is a necessity because it’s the reviewer’s first comment”.
OpenScrum hasn’t necessarily made things simple. Earlier, each developer would fix their own modules, work on parts that they were comfortable with. New modules would be based on requirements from an implementation that would have their developers working on it. The OpenScrum development processes - checks and balances have made things more complex.
The GSE method was simple, in the sense that people could work independently, with less effort in co-ordination. The down-side was that with more and more people writing their own modules and with growth of the community without any governance processes, it was becoming harder to ensure quality. So, it is probably worth discussing that for open-source projects although co-ordination is a difficult task, it is worth pursuing, to ensure better quality.
Challenges with Time-boxing and Community Participation One of the main goals of sprints is that the team focuses on finishing planned set of features in a time-boxed manner. Short cycles emphasize that quick progress needs to be made, even though things can be improved over the next iterations. Another focus of Scrum is that the sprint backlog is completed in a manner that a product is ready to be delivered.
Figure 8: Issues Resolved Vs Planned
From Figure 8, we can see that there has been a constant challenge with the OpenMRS sprints to be able to meet the expected goal in time. Software estimation is generally accepted to be challenging , but in open-source communities this estimation becomes nearly impossible because one can never correctly estimate the commitment and time spent by community contributors. The trendline for Sprint backlog Vs Completed on Time shows a constant difference that doesn’t seem to have improved over time. Since, not being able to meet the estimated goal with every recurring sprint, the product remains not ready for release most of the time after every sprint. The OpenMRS community in general acknowledges this problem, yet does not have a solution to deal with it.
A clear change since moving to OpenScrum has been increase in community activity. There is much more activity in the IRC, probably due to the daily standup meetings in which the developers communicate about their activities and blockers. There is also a marked increase in the number of comments that are made on tickets. These comments are made by developers as well as implementers. This shows that people are more actively monitoring and helping each other during the sprints compared to earlier. This is a healthy sign of increased communication in the community and the timing seems to point to the fact that change in the development methodology has resulted in this increased communication in the community.
Figure 9: Community activity in IRC and ticket comments
A small note on community participation and priority was highlighted in all the interviews with the developers. While it is clear that sprinting on the most needed aspects is important for the community, it is somewhat difficult to build consensus on what is most needed. For example, requirements for those implementations often get prioritized, that have allocated developer resources. As one core developer put it, “As we have limited developer resources, supporting implementations of our fellow developers is vital. But sometimes, the loudest voices in the implementer community only get prioritized”. While the goal of communities should also be to listen to the shrillest voice and provide adequate assistance to them, the interviews highlighted the fact that since moving to OpenScrum, it has become harder to organize sprints that are edge-case requirements. Feature requests that could benefit the community at large or request for new modules, might not get enough votes compared to bug fixes, since large implementations have strength in numbers.
OpenMRS had a software development process that was used for nearly 6 years before switching to OpenScrum. While it is a continuously improving methodology, some core concepts have evolved in the last 1.5yrs. The paper refers to this tailored Scrum as OpenScrum. Pentaho, the open-source Business analytics suite has attempted a methodology by the same name, but it is not in practice. OpenScrum in essence is ideologically the same basis as the original idea behind Scrum, as coming from Rugby (scrummage). A quick restart of the game (sprint) happens after an infraction. During this restart, a front-row of highly skilled forwards, pushes with itself a team with a common goal. The OpenMRS team is led by such high-skilled core developers and push together with the community developers on a common set of activities during a sprint. Below are some of the differences between Scrum and OpenScrum as observed in practice within the OpenMRS community.
6. CONCLUSION AND FUTURE RESEARCHWe conclude by putting forth OpenScrum, a tweaked agile methodology that has empirical basis by which it has helped improve bus-factor in the OpenMRS community. This can be useful to a number of open-source projects that would like to retain developer knowledge and focus on knowledge sharing. To answer the specific research questions – agile methods like OpenScrum have improved community participation and developers know much more about each other’s code-base. This in turn answers the second research question of sustainability.
More developers continue to know and contribute to more modules. The contributions have widened and bus-factor for a number of modules have increased. We also conclude that Agility might not be an appropriate measure for open-source projects. Instead increasing busfactor through knowledge sharing, increasing community participation and increasing communication are more important measures in open-source projects.
It will be interesting to use OpenScrum in domain-light (non-vertical sector) open-source projects and see the effect of adopting this methodology in those communities. It will also be useful to view code quality improvements by the use of OpenScrum in open-source projects.
OpenScrum is also suited for completely community-oriented projects and might be problematic to use for projects that work in less open fashion or projects that have dual licensing workflows, where organizations need to differentiate proprietary dev team and open-source dev team.
REFERENCES  Ågerfalk PJ, Fitzgerald B, and Slaughter S. Flexible and distributed information systems
development: State of the art and research challenges. Information systems research 20.3 (2009):
317-328. DOI: 10.1287/isre.1090.0244  Jalali S, Wohlin C. Global software engineering and agile practices: a systematic review. Journal of Software: Evolution and Process. 2012 Oct 1;24(6):643–59. DOI: 10.1002/smr.561  Warsta J, Abrahamsson P. Is open source software development essentially an agile method.
Proceedings of the 3rd Workshop on Open Source Software Engineering. 2003.
 Koch S. Agile principles and open source software development: A theoretical and empirical discussion. Extreme Programming and Agile Processes in Software Engineering. Springer Berlin Heidelberg, 2004. 85-93. DOI: 10.1007/978-3-540-24853-8_10  Beck K, Beedle M, Bennekum AV, Cockburn A, Cunningham W, Fowler M, Grenning M, et al.
Manifesto for agile software development. (2001).
 Highsmith J, Cockburn A. Agile software development: The business of innovation. Computer 34.9 (2001): 120-127. DOI: 10.1109/2.947100  Williams L, Cockburn A. Agile software development: it’s about feedback and change, IEEE Computer 36 (6) (2003) 39–43. DOI: 10.1109/MC.2003.1204373  Boehm B. "Get ready for agile methods, with care." Computer 35.1 (2002): 64-69. DOI:
10.1109/2.976920  Nerur S, Mahapatra R, Mangalaraj G. Challenges of migrating to agile methodologies.
Communications of the ACM 48.5 (2005): 72-78. DOI: 10.1145/1060710.1060712  Nawrocki J, Wojciechowski A. Experimental evaluation of pair programming. European Software Control and Metrics (Escom) (2001): 99-101.
 Cao L, Mohan K, Xu P, Ramesh B. A framework for adapting agile development methodologies.
European Journal of Information Systems 18, no. 4 (2009): 332-343. DOI:10.1057/ejis.2009.26  Mangalaraj G, Mahapatra R, and Nerur S. Acceptance of software process innovations - the case of extreme programming. European Journal of Information Systems 18.4 (2009): 344-354.
DOI:10.1057/ejis.2009.23  Moe NB, Dingsøyr T, Dybå T. A teamwork model for understanding an agile team: A case study
of a Scrum project. Information and Software Technology 52.5 (2010): 480-491. DOI:
10.1016/j.infsof.2009.11.004  Cockburn A. Agile software development: the cooperative game. Addison-Wesley Professional, 2006.
 Lakhani K, Wolf R. Why Hackers Do What They Do: Understanding Motivation and Effort in Free/Open Source Software Projects (September 2003). MIT Sloan Working Paper No. 4425-03.
DOI: 10.2139/ssrn.443040  Fitzgerald B. The transformation of open source software. MIS Quarterly. 2006;587–98.
 Crowston K, Wei K, Howison J, Wiggins A. Free/Libre Open-source Software Development:
What We Know and What We Do Not Know. ACM Comput Surv. 2008 Mar;44(2):7:1–7:35. DOI:
10.1145/2089125.2089127  Krishnamurthy S, Ou S, Tripathi AK. Acceptance of monetary rewards in open source software development. Research Policy. 2014 May;43(4):632–44. DOI: 10.1016/j.respol.2013.10.007  Mockus A, Fielding RT, Herbsleb JD. Two case studies of open source software development:
Apache and Mozilla. ACM Transactions on Software Engineering and Methodology (TOSEM) 11.3 (2002): 309-346. DOI: 10.1145/567793.567795  Scacchi W. Free/open source software development. Proceedings of the the 6th joint meeting of the European software engineering conference and the ACM SIGSOFT symposium on The foundations of software engineering. ACM, 2007. DOI: 10.1145/1295014.1295019  Stephany F, Mens T, Gîrba T. Maispion: A tool for analysing and visualising open source software developer communities. Proceedings of the International Workshop on Smalltalk Technologies. ACM, 2009. DOI: 10.1145/1735935.173594  Conboy K. Agility from first principles: Reconstructing the concept of agility in information
systems development. Information Systems Research 20.3 (2009): 329-354. DOI:
10.1287/isre.1090.0236  Jones C. Software assessments, benchmarks, and best practices. Addison-Wesley Longman Publishing Co., Inc., 2000.
 Endres A, Rombach D. Empirical Software and Systems Engineering: Observations, Laws, and Theories. Addison-Wesley, 2003.
 Mockus A. Succession: Measuring transfer of code and developer productivity. Software
Engineering, 2009. ICSE 2009. IEEE 31st International Conference on. IEEE, 2009. DOI: