From 3M Health Information Systems
Using agile methods in research
This month, I have invited a senior member of my Research team, Ryan Butterfield, to author a blog with me. Ryan is a statistician who has been with the team for over a year after working as a statistician in various academic, public health and private sector settings. Ryan fills the Scrum Master role on a couple of our project teams and has been instrumental in helping our team adapt agile methods for research projects.
There is no denying the advantages of an agile process flow to an R&D environment. However, these processes lack the one thing that is necessary for research to be accomplished and that is time. The process of turning ideas into tangible and informative products is an imaginative one, requiring an input of information, foundational knowledge to connect the dots and time to allow these connections to be made. The research process is naturally an iterative one and can consist of many false starts and incomplete finishes. 3M Health Information Systems (HIS) Division has made a significant investment in the Scrum framework for the development of new products. As part of HIS, the R&D team supporting Populations and Payment Solutions and Clinical and Economic Research is tasked with imagining, creating, prototyping and refining new and innovative approaches and methodologies. Going through the steps of research can be time consuming, yet the team is faced with a mandate to fit this work within the Scrum framework. This discussion is the response to that dilemma.
Scrum is a strategic development method which takes a holistic approach to development of new software, products or processes. First defined by Takeuchi and Nonaka (1986), and continued on through the work of Schwaber and Sutherland , it was not until around the turn of the latest century that the scrum methodologies were formalized by Schwaber and Beedle (2001). 3M HIS has directly trained with Jeff Sutherland who is the CEO and Principal Consultant at Scrum, Inc. and uses these techniques as a formal software product development and project management tool, including the assignment of designated Scrum teams and roles such as Product Owner and Scrum Master, allocated meeting rooms, backlogs, scrum boards and the calculation and tracking of Scrum metrics such as velocity and burndown. The approach presented here builds partially upon the work of Hicks and Foster (2010) who first recognized the utility of using a Scrum approach specifically for academic styles of research, i.e. the SCORE method. SCORE or “SCrum fOr REsearch” is an adjusted Scrum method where the frequency of meetings and documentation process is customized to fit the needs of the research teams.
The SCORE approach is adapted from the original scrum method and creates an environment more suitable for research. While academic in nature, this research process does have enough similarities to a traditional scrum to be considered a slight offset of a full scrum approach. A few highlights from Hicks and Foster: Instead of daily meetings, 2-3 meetings per week; instead of “scrum meetings” they are termed “status meetings” and are similarly 15-30 minutes. “On-demand” meetings are follow up working meetings that will consist of an hour or more time frame to allow for issues to be completely resolved or tasks completed. In our HIS research team, we adopted a once-a-week “meetup” where the project team, Scrum Master and Product Owner meet to update where we are and where we are going. This is then combined with the “on-demand” aspects previously discussed.
Project Structure using SCRUM as a guideline:
A second dimension of this approach includes suggestions for optimizing daily schedules and integration of this process. Efficient projects are only as good as the efficiency of the team AND the efficiency of the team members. Based on research in optimal work strategies, both scientific and popular (e.g. Tim Ferriss 4-Hour Work Week, Pomodora Technique, etc.), the following list is compiled as suggestions for improving individual efficiency. Together with strategies for identifying priorities, scheduling, breaks, meetings, etc., these are all part of this approach. It is a misconception to think that everyone knows how to work in an efficiently effective way. A common philosophy is the Pareto Principle, which states that 20 percent of your effort will produce 80 percent of the results. It is an important piece of this principle to identify those tasks that will comprise your 20 percent effort and result in 80 percent of your work.
Day-to-Day Work Structure (suggestions for working optimally without burnout):
These suggestions are ways that research projects may be designed and implemented using tools not only at the team level but at the individual one as well. The two layers of efficiency at the individual and team levels should be well thought out and strategized to reach optimal performance. Just as personnel are trained on underlying principles of honesty, ethics, etc., so should they be trained on optimizing performance.
An example of a research project where this approach was implemented was in the methodological and technical programming development of a tool for use in developing virtual physician networks. An existing tool was in need of an update in methodology, and the programming driving the tool was in some disarray. The aforementioned research process was developed and put into place as part of the underlying development of preparing for this project. Following the pattern described above, the classic Scrum process has been modified from that employed in software development to fit the needs of our research team. Some changes were determined by the virtual nature of the team. For example, sitting vs. standing meeting attributes and the use of a physical scrum board with post-it notes are not applicable for our virtual project teams. We use virtual project boards maintained in spreadsheets. The reduction in the number of meetings was a big advantage to moving towards efficiency. The team started out with two full meetings per week but found this to be too much for the entire project team to attend. There was a transition to 1 full meeting at 30 minutes where the Product Owner is updated. The rest of the meetings are “on-demand” and are between the team members and the Scrum Master and serve as trouble shooting or results reviewing meetings only. Team efficiency was improved using these methods by allowing for the project to be broken down into attainable steps, the team members received acknowledgement for their accomplishments and stress was reduced as the timelines and project expectations were not only obtainable, but also flexible. If a team member felt that they would not reach the weekly deadline, then there was a compromise between the Scrum Master and team member. This allowed for the project to keep moving and avoid any potential burnout on the part of individual team members. The individual efficiency practices were discussed by the team and used as guidelines. Each member used some form of the guidelines and was free to identify their own best practices.
With approximately six months experience in applying modified agile methods to health services research projects, we have found that, overall, these approaches allow for more work to be accomplished while maintaining a balance between research flexibility and project management rigor. Our modifications have permitted change in direction as lines of inquiry dictate, while preventing team members from becoming overwhelmed. It also allows project leadership to stay on task and keep our projects moving along reasonable timelines toward iterative product deliverables.
Paul LaBrec is research director for Populations and Payment Solutions with 3M Health Information Systems.
Ryan Butterfield, DrPH, is a statistician with 3M Health Information Systems.
References on project optimization: