Virtually Priceless Thoughts

Better Projects recently posted a generic description for scrum that is not IT project specific.

I have, on occasion, thought about how one can apply agile software develop methods to research projects and other non-IT projects. I have been thinking about how our groups and projects could benefit from some of the agile methods. This seemed like a good enough trigger for me to write about scrum and research.

Craig Brown (on Better Projects) lists the elements of scrum as follows:

1. Start with a goal. Break down the goal into incremental steps.
2. Discuss the steps with the team who needs to deliver the solution.
3. Set standard time boxes. Do your best to deliver something practical and useful each time boxed iteration.
4. The team needs to take instruction from the customer at the beginning of each iteration and report on what got ‘done’ at the end of each iteration.
5. The team must set aside a portion of time at the beginning of each iteration to plan their work.
6. The team needs to set aside a regular and brief portion of each day to communicate progress and problems to one another.
7. The team needs to commit to continuous improvement and should set aside a portion of time each iteration to reflect on what went well, not well and where they can improve.
8. The planning, review and reflection sessions, and the daily team update all need to be set at regular times to help the team achieve a sense of rhythm.

Let’s go through the eight elements, applying a research lens. I will be thinking about some of the evaluation of health information systems, rather than

1. Goal: Check. Research projects should have a clear question in the beginning. There’s a need to define a method, which really could be broken down into incremental steps.
2. Determine who is responsible for which work products: Check.
3. Research projects can be time boxed. The question of delivery is interesting and it depends on the methods. Some research protocols, such as randomized control trials do not lend themselves to using agile methods. They are more “waterfall” in their approach, if you will. You won’t know results until you have a large enough number of research subjects (although the set up activities can easily be time boxed). Other methods are more suited to thinking about them with agile methods.
4. Instruction from the customer: for some studies the “customer” is not explicit. Is it the granting agency? Is it the end user? The more engaged we as researchers are with our customer, the more likely the knowledge gained is knowledge applied. So we can benefit from defining a customer who is engaged.
5. Planning Time: Yes, this can be easily done. I would add, especially when working with students, that this is key and ties into #6 & #7.
6. Daily Progress Report: Typically, research projects are run more autonomously. One of the challenges we have of adapting scrum and the importance of daily team meetings is simply the timelines for some studies. There are often long pauses (ethics review) where things are on pause until approval is received. Does this require redesigning the research team structure (e.g. have an ethics rep on the team) or does it mean that scrum activities are bound to periods of higher activity? I am not sure.
7. Continuous Improvement: For all of us this is important. For students who are on such a trajectory of learning and growth, even more so. Regular reflection helps improve skills faster than just doing blindly. Here we can learn to better plan, assess our capacity for work, and highlight “hard parts” of projects. This helps the current project as well as future projects. I am a big supporter of reflection, so this is easy.
8. Regular times led to productive rhythms.

In truth, many of the action oriented approaches are similar. Soft Systems Methodology also recommends iterations and reflections.

I think it is time to start more formally bringing in some of these ideas into the research plans that I am building now.

Related posts:

1. My Learning Objectives 2010 Thank you everyone for your feedback to my previous post...
2. Clinical Architect and Software Lifecycles and Design Methodologies NOTE: This post is a follow up from the overall...

Related posts brought to you by Yet Another Related Posts Plugin.