OpenMRS Implementation of Agile

Development
1

Team,

I researched some sources on Agile methodology. Below is a structure and Agile team structure that I wanted to share with by each of you.

If you approve of the structure, terminology, and team roles described below, my suggestion will be to implement, test, and formalize this agile methodology in a pilot project. If successful, we can then document these terms, processes, planning phases, and roles on OpenMRS site wiki, and refer to it for subsequent projects. In my head, I am thinking about an “OpenMRS Implementation of Agile” that considers volunteering global resources, time zone and cultural differences.

As you review this structure and roles, please consider the following questions:

  1. Will this make sense for OpenMRS projects going forward?
  2. Do the resources that we have in place now match the roles below? Will we need to recruit different types of talent to occupy these roles (ie, scrum master, product owner)?
  3. Does this feel like “too much” process? Will the developers welcome this level of process and structure? Or do we run the risk of alienating precious and limited development resources that have become accustomed to working in less structured environments?

Project Structure and Terminology

Ideas are captured as user stories and structured as multiple DEFINE >> CODE >> TEST process iterations (aka, “sprints”) spanning 2 weeks with periods of REVIEW and ADJUST in between each iteration.

  • Point: Defines how much a team can commit. A point usually refers to 8 hours. Each story is estimated in points.
  • Capacity: Defines how much an individual can commit. Capacity is estimated in hours.
  • Release planning: A rough estimate is given to a user story using relative scale as points
  • Iteration planning: The story is broken down into tasks.
  • Requirements: Defined as a user story with acceptance criteria and tasks to implement the story
  • Daily Stand-Up: A daily status meeting among all team members and it is held roughly for 15 minutes
  • Release: A major milestone that represents an internal or external delivery of working, tested version of the product/system.

Planning

  • Release Planning: Create a plan to deliver an increment to the product. It is done after every 2 to 3 months

  • Iteration Planning: Purpose is for the team to complete the set of top-ranked product backlog items. This commitment is time boxed based on the length of iteration and team velocity.

  • Product Backlog: A list of items to be done. Items are ranked with feature descriptions. In an ideal scenario, items should be broken down into user stories.

Roles

Team roles are categorized into Team and Technical interfaces. These include the following:

Team Interface

Scrum Master (1) Product Owner (1)

Technical Interface

Developer (3-4) Tester (1)

3 Likes
2

Hi @tomhealy,

thanks for sharing!

Can you please elaborate on

  • what you would like to achieve
  • and why you choose scrum

thank you!

3

@tomhealy I appreciate that you’re starting to look at this!

Rather than necessarily starting from a scrum structure, I would suggest that we first figure out what people are typically available in a typical month, and in what context they are available. I would even go back to the agile manifesto and the agile principles and figure out which of them are relevant/applicable to a volunteer-driven open-source project. From this starting point we can then think about structures that would work. (Also, we should be agile in how we define this, i.e. our MVP is a structure that we can trial once, and evolve based on what we learn.)

A few points:

  • volunteers don’t necessarily do any OpenMRS work every day
  • they often can’t/won’t join a daily standup
  • it’s hard to figure out points/capacity
  • historically it has been easy for us to find end-consumers who want a feature built, but harder to get to detailed requirements.
  • I guess this is mostly because the dev side can’t commit to actually building something on a reliable timeframe, so no business-side person wants to commit the time to write detailed requirements
  • also, we’ve rarely had a BA available to interface with the end-consumer on the business side. One project that worked very well was when we added Allergies to the reference application; one reason it worked smoothly is that we had a BA donated to us at the time. I don’t think we’ve ever tried using a volunteer BA in the correct way though.

(I have a lot more thoughts, but they’re pretty scattered, but I’d be happy to chat by voice sometime as you’re analyzing this situation.)

4

Ivo,

It is nice to make your acquaintance. Thank you for responding to the thread.

As a new contributor to OpenMRS, I was told that the community could benefit from some process and project management standardization. Since the OpenMRS developers are volunteers, the time that they contribute is especially precious and valuable. Similar things can be said about the recruitment and retention of OpenMRS developers.

So, there is an interest in providing some repeatable software development management processes in support of encouraging and maintaining good experiences for the OpenMRS developers. I am also told that the OpenMRS initiative has reached a point where there is a need to “harden” the architecture and documentation.

Regarding Agile and Scrum: I would rather say that I am advocating these methodologies as a reasonable starting point, with the acknowledgement that feedback from OpenMRS developers and others in the community may take us to some variant of Agile, or another methodology that is best suited to the community. Agile and scrum are familiar to most developers, and are industry tested.

Tom

5

Darius,

Great feedback! Thank you for responding.

To your points, I do get the sense that we will need to tailor PM and software development methodologies to meet the characteristics of the OpenMRS development community.

Your point about the relationship between developers and business requirements caught my attention. In commercial production environments, there is a often such a premium on scarce development resources that they are only allocated if/when business requirements are well understood and documented. The reverse can be implied, in that developers are not terribly interested in coding anything unless the requirements have been hardened. That leads me to wonder if OpenMRS would get better development utilization if we could improve our competency and commitment in documenting requirements.

I appreciate the offer to connect via voice. I will look for a day and time to do so.

Tom

1 Like
6

Thanks @tomhealy for doing a “spike” on Agile methodologies and sharing what you’ve learned.

Historically, the OpenMRS community has been using a handful of Agile methods on & off over the years. At one point, we tried coordinating all development into a series of development sprints and @cpower (community PM at the time) had come up with a Sprint Template. Over the years, the pendulum has swung between coordinating back-to-back sprints 3 months at a time (and losing interest of implementations whose priorities had changed by the end of the 3 months) to a fully reactive “Vote on What We Do” approach (page has since broken, but listed issues by JIRA vote count, and ended up being too biased & reactive). We continue to have daily scrums in our IRC channel. From what I recall, the Agile tools we’ve used most are:

  • Daily scrum (in IRC)
  • Sprints (as you’ve described)
  • Spikes (a single dev taking a day or two to do a deep dive into a problem to answer a specific question)

It’s good to have your fresh ideas (without this historic baggage) examining what we are doing today in the community and coming up with suggestions on how we could do better.

Like @darius, I would suggest, now you’ve learned more about Agile, to investigate current development practices and see how we can help developers be more productive & better guide development activities toward community priorities. Some things happening today (currently):

  • We try to direct all new devs to Get Started as a Developer - Documentation - OpenMRS Wiki and *have defined Dev Stages as a badge-based method of identifying developer skill level – led by @dkayiwa (Community Development Lead) – to motivate developers.
  • We label JIRA issues as community-priority and display these first for consideration of volunteers (our “process” for identifying community priorities is not well defined).
  • We have weekly PM calls where a handful of community members (none of whom are PMs) try to inject some project management by reviewing weekly progress (looking at OpenMRS PM - OpenMRS Issues), anticipate blockers/problems, and coordinate efforts where we can.
  • For many years now, we have tried to ensure we always have a /dev/5 leading the Community Development Swim Lane (an attempt at directing volunteer developers toward a kanban to tackle community priorities while helping them onboard). To my knowledge, this has largely been driven by devs seconded by Regenstrief and hasn’t reached its original vision, but has been incredibly helpful in aiding incoming developers and responding more quickly to implementer issues that crop up).
  • We encourage developers sprinting to make sprint announcements on Talk (you can see the Andela team is doing Cohort Builder sprints).

Can we leverage Agile methodologies both to make a better & more productive experience for volunteer developers while directing those efforts toward community priorities? Would this be doubling down on our Community Development Swim Lane with more agile approach? Or something else?

Can we make reasonable progress on Agile development before addressing the BA issue @darius mentioned (having actionable tickets/sprints aligned with community priorities)?

Can we help developers adopt agile methods without creating bureaucracy? In other words, make it convenient for devs to use tools (SDK/JIRA/Talk/automated release processes) that promote Agile best practices via our culture so they end up adopting Agile methods without thinking about it or feeling like they have to jump through hoops.

I don’t expect you to be able to answer these, but I’d welcome any help with coming up with answers, improving experience & productivity for community developers, and, in turn, saving more lives. Welcome to the community! We’re all in this together! :slight_smile:

Cheers,

-Burke :burke:

p.s. ThoughtWorks has been a longtime supporter of OpenMRS, happens to be where folks like @darius & @jteich work, created Bahmni (a distribution of OpenMRS), and is a leader in the world of Agile Development (home of Martin Fowler, a thought leader in the field)… so we have and can continue to learn a lot from out ThoughtWorks colleagues regarding Agile.

2 Likes
7

I have been working with the OpenMRS community for 20 months so far and what I see is that the principles of agile, collaboration, delivering working software, interactions with individuals (discussions) and responding to change are well embodied in the current working style.

I would call the OpenMRS approach pragmatic agile, implemented with a remote team of core developers supporting and co-ordinating needs both technical and non-technical needs of a community that has its own need/drivers. The community is spread all over the world with various needs and resources, all the way from a single user with data collection needs to facilities running a complete patient and hospital management system in the cloud.

The tools in play - JIRA (issue tracking), Wiki (documentation), Talk/IRC/Telegram (collaboration) and GitHub (code hosting), Bamboo and Travis (Continuous Integration).

My previous experience with practices from the private and government sectors with regard to finite business requirements, are that it works as the scope of works are limited to the needs of the organization. However this breaks down in the case of open source projects like OpenMRS with limited core resources, varied implementor human resources capabilities, varied regulatory and usage requirements, funding cycles are spread across the are focusing on saving lives in an ever changing environment, without the necessary

Over the last 4 months with my role as Reference Application Lead, I have experimented with pushing for implementation user value as a way of driving feature prioritization within the community which I believe is a catalyst for adoption and usage of OpenMRS tools. This has been successful in my opinion with the release of 2.6, which has a number of new features that focus on implementation needs, as well as setting the foundation for the next reference application release due in October 2017.

8

Personally I think the biggest thing that slows us down is the lack of well documented, ready-for-work tasks that new devs can pick up. And I think this is the main reason that we send lots more people to our Getting Started pages than actually have end up engaging.

So, per TH’s comment, I feel like we are in the reverse position, where we have more (potential) dev effort available, and our bottleneck is BAs documenting requirements.

(Stephen, RefApp 2.6 is a good example of this, where you actually writing requirements led to us putting more new features in this release than in our previous few releases combined.)

-Darius (by phone)

1 Like