How we Structure Work Learning from BaseCamp

Community Leadership
,
1

I came across this excellent resource shared by BaseCamp on how work is structured, https://m.signalvnoise.com/how-we-set-up-our-work-cbce3d3d9cae#.4m7ouefj8.

Apart from just sharing it, I figured that it may provide a way to leverage the community to support the evolution of OpenMRS in addition to supporting project management.

  1. The Next Cycle - is a sprint planning tool, https://public.3.basecamp.com/p/yCe87HJ5EX1Nx48N3R6fhfHX, which can be used quarterly to provide thinking and planning for big ticket items as well as smaller sets of changes. This goes a step above JIRA tickets, since a number of JIRA tickets can be bundled into a feature or a platform change

  2. Pitch (I personally like this one), https://public.3.basecamp.com/p/22KB2DCxpEQLZow8Vc2iJhEq, the description for a feature that is to be done in the next cycle which gets a node to be done.

This is in light of providing some clarity into what is being worked on from cycle to cycle, supporting the project management planning and usage which is being discussed, but starting from a simple, practical and pragmatic process that can be evolved over time.

1 Like
2

Thanks @ssmusoke for sharing! :slight_smile: Basing on what you have learn’t from these links, do you have recommendations regarding how we could improve our existing processes, or way of working?

1 Like
3

@dkayiwa I think the Next Cycle planning is a first step, to build what are the important objectives for the next quarter - 2 big deliverables, and maybe 4-5 smaller ones. My suggestion would be that the platform and reference application each get a big deliverable which has been requested for long. I am happy to work with anyone to deliver this over the next week or so

4

@ssmusoke would this be a good start for the first step? https://wiki.openmrs.org/display/docs/Technical+Road+Map

5

@dkayiwa The road map provides a good start, now the question is which of those to include in a 3 month timeline and who will be responsible in getting it done

6

@ssmusoke does it have to be three months only? :slight_smile:

7

@dkayiwa That is the whole point, within 3 months something has to be shipped, so this provides a laser focus on what is priority and how it fits in with the larger goal for both the core developers, leadership and community at large.

8

Currently, the plan is ship the reference application every 6 months. We can attempt to see what could be done in 3 months. If it is not reasonable enough for a release, we either go back to 6months or look for strategies to make that happen.

1 Like
9

@dkayiwa I think my recommendation is complimentary to the current process and not replacing it, just adding cycles of predictability and feedback loops. Here is what I envisage:

  1. Reference App (still ships every 6 months) and Platform releases are done annually
  2. However every quarter features of value are added (in a predictable and planned manner) using both dedicated and community resources - which actually later improves the reliability of the releases in #1 above.

All I am looking to add is a “business” side to things, to improve communication and provide more opportunities for participation

10

@ssmusoke do you think you can join one of the comming project management calls on Mondays to share out these excellent ideas? The time is 8pm - 9pm Ugandan time. :slight_smile:

11

@dkayiwa This coming Monday is bad, how about a session at the OpenMRS conference in the next 2 weeks?

12

It does not have to be this Monday. It can be any other. Though your proposal of a session at the conference looks exciting! :smile:

13

+1 to discussing this in Uganda.

This dovetails with ongoing conversations between @burke, @terry, @jan, and I about how to transform the way we are doing project management.

-Darius (by phone)