A project-management tool from the tech industry could benefit your lab

Scientist fans of ‘agile’ and ‘Scrum’ claim that they can help labs to prioritize tasks and cut meeting times — but some research groups are more sceptical.
David Adam is a science journalist based in London.

Search for this author in:

A stand-up meeting at the University of Oregon

A stand-up meeting at the University of Oregon in Eugene.Credit: Lisa May

“Turns out there was a project meeting every week I didn’t need!” “I turn work around in two or three days instead of in two weeks.” “There’s ten more hours in my week I have free for work that I was spending in meetings.”

These comments aren’t part of an advertising campaign. They are responses published in an academic paper on LabScrum, a project-management tool made by scientists and graduate students at the University of Oregon in Eugene — where its use is spreading through academic departments (L. May and T. Runyon. Preprint at; 2019).

Scrum, the tool on which LabScrum is based, is used to organize the time and activities of a group of workers. It’s probably best thought of as a guiding concept or framework that helps team members to be more efficient and productive. It aims to do this by breaking down long-term objectives into a series of structured, short-term goals, offering regular feedback and cutting down on the number of large meetings that drain time and energy.

Scrum first emerged in the software-development industry in the 1980s. Some science labs have adopted the tool, with mixed results. It is based on 12 ‘agile’ principles of software development, which include prioritizing individuals and interactions over processes and tools, and responding to change instead of blindly following preset plans.

Supporters of agile techniques say that they are more flexible and responsive than the conventional ways of organizing workflows, which they call ‘waterfall’ methods. Waterfall work proceeds in a more linear fashion: the group doesn’t move to the next stage until all previous tasks have been completed and preset goals are achieved.

Productivity boost

Scientists and students using Scrum in research groups across biology, psychology and human physiology at the University of Oregon report higher levels of productivity and lower levels of stress, says Lisa May, assistant director of operations for the Center for Translational Neuroscience at the university. She has worked to introduce the tool there, and co-authored the LabScrum study published earlier this year.

Among the specific problems that LabScrum helps scientists to address, May says, are prioritizing competing projects, and balancing teaching, research and clinical work. The introduction of Scrum, she adds, has helped to stop colleagues from approaching overburdened faculty members with demands that slow decision-making, and has improved collaboration and knowledge-sharing between lab members.

One of the most obvious advantages of using Scrum, says May, is that it can help principal investigators to scrap some time-consuming weekly meetings. Following Scrum thinking, if there’s something serious to address, then those meetings are too short for a proper discussion. And if there’s nothing serious, then they’re too long. Scrum instead introduces short but regular (say, thrice-weekly) all-hands lab meetings for team members to update their colleagues on progress and to highlight any problems.

Scrum organizes long-term planned work into small chunks called sprints, which researchers can usually complete in two weeks. (There are many other terms too — see ‘Ten terms to make your lab agile’.) Sprint goals, such as producing a draft of a paper, analysing some data or sending a specific e-mail, are set collaboratively for individual lab members at a group meeting on the first day of the fortnightly cycle. And several objectives can be set for a team member during one sprint period. Members report their progress on each task during regular meetings throughout the week. At the end of the sprint cycle, in a dedicated 90-minute meeting, the entire group reviews and discusses a preselected group of tasks that each member has completed, and they go over how well the process is working (see ‘LabScrum explained’).

Ten terms to make your lab agile

Scrum-master. Often the head of a lab, they steer the process and coordinate the meetings.

Product owner. Faculty members own large, lab-wide projects. Trainees own their individual projects.

Backlog. A long-term to-do list that can be prioritized and divided into sprints.

Acceptance criteria. A checklist of what needs to be done to complete a task.

Sprint. A sufficient frame of time to get work done so that the team is ready to regroup, get feedback and plan next steps.

Stand up. A short check-in meeting where each person reports on the status of their work.

Review. At the end of a sprint, the chance for team members to present work and get feedback.

Retrospective. A meeting where the team reflects, discusses and suggests improvements to the ongoing Scrum process.

Release planning. Plans on a medium time scale, longer than two weeks but less than an academic year.

Minimum viable product. The point at which the result of a sprint is ready for group review.

Krista DeStasio, a psychology PhD student at Oregon whose lab uses LabScrum, says that the sprint approach has helped her to become more aware of how long completing a particular task takes. Focusing on two-week chunks makes her project seem more tractable, she adds. DeStasio feels more comfortable asking for help because the frequency of contact between group members under Scrum principles encourages less-formal approaches from students to each other and their supervisors.

DeStasio is now in the third year of her PhD programme, but she worked without Scrum in her first year. She had often felt as if she couldn’t bother her PhD supervisor, University of Oregon psychologist Elliot Berkman, with questions.

Berkman agrees that frequent contact works well. “You don’t want to be continually interrupted, but we’re all convinced it’s much more efficient to be able to have those quick and easy questions in real time rather than letting them accumulate,” he says.

Computer scientists Michael Hicks and Jeffrey Foster introduced Scrum ideas to their research group at the University of Maryland, College Park, in 2008, and produced an internal report on their progress two years later. Feedback from a group of 13 students about the tool was universally favourable, according to the paper. One student quoted in it said that the increased frequency of lab meetings under the Scrum schedule reduced the number of spurious points that some attendees thought they needed to make in less regular meetings, adding: “If something came up and you don’t have anything to report for today, it’s not a big deal. You’ll have something for tomorrow or the next day.”

Source: Lisa May

More than a decade later, Hicks says that he is still using Scrum, with a few tweaks. He continues to have thrice-weekly status meetings with team members, and collaborates and meets weekly with remote colleagues, but he doesn’t use the other components, including sprints. “We have never managed to integrate that aspect of Scrum into the research process in any formal way,” he says. “In fact, we are more lax now than before, as our group has got smaller. I have two postdocs and two students. As such, it’s not so hard to just keep track of what people are doing, directly.”

Foster, who has since moved to Tufts University in Medford, Massachusetts, hasn’t yet taken Scrum with him. “But that’s because I’m working a good deal with people remotely, and with just a couple of students local to Tufts,” he says. “So at the moment it’s easiest to schedule individual meetings. I expect that will change after a couple of years as I rebuild my group.”


Scrum doesn’t work for everyone. Titus Barik, a software engineer at Microsoft in Redmond, Washington, had a bad experience with the system when he was a PhD student at North Carolina State University in Raleigh. “It worked out horribly for us,” he says, adding that the focus on short-term sprint goals led to people picking easy tasks that they could quickly accomplish rather than pursuing the long-term efforts necessary for successful research. Given that most research fails, he adds, the system’s requirement for constant updates resulted in him feeling “substantially increased anxiety”.

After Barik raised his concerns with his then-supervisor, Emerson Murphy Hill, the two tried to incorporate some other Scrum principles, for example using the workplace messaging platform Slack instead of meeting in person. This reduced anxiety, he says, but didn’t eliminate all the problems. “It requires an approach where failure to accomplish Scrum tasks is seen as an opportunity for growth,” he says.

Hill, who is now a full-time researcher with Google, says that he hasn’t heard others describe problems with Scrum as Barik has. “The easiest way to respond to objections to Scrum is to allow people to pass or say ‘No update’,” he adds.

Jason Hicken, a mechanical and nuclear engineer at the Rensselaer Polytechnic Institute in Troy, New York, has used Scrum since 2015 and identifies another potential downside to the approach: it can be difficult for supervisors to identify students who are struggling. “Their status update can make it sound like they are making progress when they are really spinning their wheels,” Hicken says. “Such students should request a one-on-one meeting sooner than they often do. Therefore, the adviser has to be proactive and encourage students to have one-on-one meetings when they are having trouble.”

Hicks agrees that principal investigators who use Scrum need to closely track their students. “Some really do need a regular meeting in addition to the Scrum meetings,” he says. “They don’t say much during the Scrum meeting, so you need to interact with them to get more detail and push them along. Or they seem to know what they are doing so well that if you didn’t set up a regular meeting you might never see them.”

May notes that software development and academic science have different end goals, so she has focused her adaptation of Scrum on the process of research rather than on measuring outcomes and productivity. Although a range of users, from lab heads to graduate students, say that using Scrum has made them more efficient, the university has not yet found a reliable way to measure those efficiency levels. A possible metric, May says, comes from examination of how manuscripts are prepared and submitted. Anecdotal reports from researchers suggest that papers are being written and sent off to journals more quickly than before because deadlines are communicated better under the regular feedback of the sprint system. Priority-setting also encourages lab members to agree on draft sections rather than get stuck in endless cycles of revision. Another possible test of the benefits of the Scrum approach, May says, is to see whether lab members can increase the number of papers under review on which they are the first author.

One of the most striking benefits of using Scrum at the University of Oregon, DeStasio says, is how it has changed lab culture for the better. Previously, it was rare for members of the group to interact, partly because they worked across different rooms and offices. The regular all-hands meetings, although they are short, encourage and foster more interaction.

May says it’s clear that many graduate students suffer when they do not work in a shared space, and that the collaborative nature of Scrum has helped to bring people together. Some of these obstacles break down along discipline lines, she adds. For example, May and her team realized that most biology principal investigators were frequently around the lab, but the offices of senior scientists in psychology were often on a different floor from the workspaces of the rest of their teams.

Berkman says that Scrum has changed that separation: he now has a standing desk in the same room as his graduate students, which features coffee-shop-style couches. “It just doesn’t make sense for us to be in separate spaces,” he says. The conventional style of training and mentorship is based on a centuries-old tradition of apprenticeship, he adds, and is not suited to modern science. Still, his embrace of at least one ‘radical’ Scrum principle sets him apart from his colleagues. “This system is being implemented in lots of labs across the university,” he says, “and I’m the only faculty member I know who has moved his office into the lab.”

Nature 573, 151-153 (2019)

doi: 10.1038/d41586-019-02620-6

Nature Briefing

An essential round-up of science news, opinion and analysis, delivered to your inbox every weekday.