CAREER COLUMN

How agile project management can work for your research

Laura Pirro outlines an approach that could increase output and improve motivation.
Laura Pirro is a PhD student in chemical engineering at the Laboratory for Chemical Technology at Ghent University, Belgium.

Search for this author in:

llustration showing aspects of planning a rocket launch – from ideas to mechanics to scheduling.

Credit: Tudmeak/Getty

If you’ve ever written a research proposal, the chances are that you will have planned the work as a list of sequential activities, often visualized in a Gantt chart.

The idea behind this ‘waterfall’ project-management approach is to break down one big task into a series of smaller, more achievable ones, with each stage of a project usually starting only when the previous one is completed.

But as many scientists know, a research project often changes from the original proposal, and it is generally messier than following a series of sequential tasks. This presents a problem: the waterfall methodology is often not flexible enough to be applied to academic research.

By contrast, the philosophy underpinning agile project management prioritizes flexibility. In the 18 years since it was first proposed, agile has radically transformed the software-development sector and it is now used in many other areas, ranging from manufacturing to criminal investigations in the US Federal Bureau of Investigation.

In an agile project-management plan, an early, partial result, which can be improved on at a later stage, matters more than a perfect result reached only at the end of the project.

For example, a painter commissioned to produce a portrait who follows a waterfall approach might split the job into sections: planning, detailed execution (background first, foreground after, for instance) and finishing touches. At the end, the painter unveils the artwork. The customer doesn’t like it, and the painter has to start again from scratch.

An agile painter, meanwhile, makes a quick sketch of what she thinks the finished project might be. The painter checks in with the customer first, then, if everyone’s happy, adds a first layer of colour. The painter checks again, then moves on to the detailed painting. Any modification in hairstyle and dress can still be accommodated until the final stage of the work.

Despite being the source of many technological innovations, academics seem to be late in adopting the agile approach. In my research group, Joris Thybaut’s group at Ghent University, Belgium, we wanted to see what an agile PhD might look like. After finding inspiration from the literature1,2, we developed a case study.

The example I use here relates to one of the most common activities in scientific research: running a set of experiments. In a waterfall approach, this long-term activity would be split into a series of consecutive tasks: in-depth planning of all the experiments, execution, and data processing and interpretation. With this approach, real scientific insights are reached only in the final stage of the work.

An agile PhD experimental protocol would involve the following.

1. Splitting the work. Slice a big chunk of work into several layers of activities, in which each layer is characterized by a tangible result to be obtained. In this case:

I. Planning and execution of a smaller number of experiments, followed by immediate data processing and interpretation;

II. Increasing the number of variables to be investigated, execution of new experiments, merging new and old data, and processing;

III. Increasing the number of data points to be acquired for each variable, execution of new experiments, merging new and old data, and processing.

Each layer is addressed in a dedicated, limited period of time (for example, 2–12 weeks), called a sprint.

2. Sprint planning. Meet your supervisor and any other stakeholders (for example, a postdoc, industrial partner or master’s student) in a short meeting (around 30 minutes) with the aim of defining the goal of your sprint (for example, what you want to investigate in the first set of experiments) and its duration (four weeks, for instance). Everybody has to agree on these two points, so that expectations are aligned and the whole research team is on the same page. On this occasion, the sprint-review meeting (see step five) can be scheduled.

3. Sprint execution. Work! Maximum focus is required on a specific task for a limited amount of time. You can do it, keep momentum.

4. Weekly scrum. Meet your supervisor for a maximum of 15 minutes, but ideally every week (for example, the same time slot every week and outside of conventional working hours to ensure there are no commitments, such as meetings or teaching activities, to get in the way). This meeting has to be short and efficient — try to have a stand-up meeting with no laptops or papers. Only three questions need to be addressed: what was done the previous week to contribute to the goal? (For example, which experiments were performed?) What will be done next week to contribute to the goal? (For example, what experiments will be performed next?) And, are there any impediments? (For example, is the set-up working properly? Are all the materials needed available?)

5. Sprint review, retrospective and planning. At the end of the sprint, meet all of the stakeholders to discuss results and whether those are in line with expectations (review). Take some time to go into detail and do some analytical brainstorming together. Discuss the difficulties encountered, so that the next sprint is better than the previous one (retrospective). This is the phase for ‘impediment removal’, or problem solving. Honesty and transparency are crucial. Agile is all about adapting to change: plans can change. Go back to step one and restart the planning, addressing the next layer of work in a new sprint.

Some preliminary applications in our research group (for example, writing a manuscript and building a simulation code) have already highlighted the benefits of an agile approach, compared with the previous, more conventional way of tackling a PhD project. Among those benefits are faster knowledge development, fewer misunderstandings about research expectations, increased output and, last but not least, improved motivation and morale.

It is worth remembering that one-size-fits-all strategies do not apply to research. This is not a comprehensive tool that will magically serve every purpose, but rather a starting point that is meant to provide inspiration for taking a different approach to research management. This is hopefully enough to get you started, and to go back to your PhD with a renewed, agile mindset. For those who are interested, some practical examples and tips will be shared in the following months on the Ristretto blog .

doi: 10.1038/d41586-019-01184-9

This is an article from the Nature Careers Community, a place for Nature readers to share their professional experiences and advice. Guest posts are encouraged. You can get in touch with the editor at naturecareerseditor@nature.com.

References

  1. 1.

    Sutherland, J. Scrum: The Art of Doing Twice the Work in Half the Time (Random House Business, 2015).

  2. 2.

    Stark, E. Agile Project Management: Quick Start Guide (ClydeBank Media, 2014).

Download references

Nature Briefing

Sign up for the daily Nature Briefing email newsletter

Stay up to date with what matters in science and why, handpicked from Nature and other publications worldwide.

Sign Up