Skip to main content

Agile Scientific Research?

We're doing research. We don't have a customer telling us what to build. Can we do Scrum? What do we put in the backlog?
Sometimes questions get asked so often, that they just demand an answer! When a research group at the EPFL asked me to come and teach them Scrum, they also represented the fourth time this year that someone had asked me these questions!

Before we try to answer them, let's take a look at whether scientific research is similar enough to software development for the values and principles of the Agile Manifesto to really apply!

Science is Different, but Similar

In a commercial environment, there is usually someone who understands what needs to be done. In Science, figuring out how things really work -- and excluding other ways that things might work but don't -- is the the core business. What they have in common is complex problem solving. The feedback comes from users in case of software development and nature in the case of science (though much science involves software development).

Often scientific problem solving is so complex that only a very small number of people understand the underlying models and phenomena. This makes it difficult to simply delegate programming assignments. OTOH the scientists themselves are usually not good software developers. Sponsors of research come with a question they want answered, not a list of features to implement. Trying to select the optimal form of collaboration between scientists, software developers and other stakeholders raises a lot of questions.

The first special characteristic I noticed about the scientific environment was a strong "yes-but" culture. Unlike many commercial environments I have seen, the yes-but culture was not perceived as being toxic, though it did seem to cause some of the expected difficulties in cooperation -- or should I say, lack thereof? Still, challenging assumptions is essential to science. If you observe B, and want to show that A causes B, you have to exclude every other possible cause of B, before you can really conclude that A is the cause. Yes-but is a professional skill.

At the same time, developing an idea often requires a constructive yes-and mentality. Yes-but tends to kill ideas and to make collaboration difficult. So both approaches, yes-but and yes-and, have their place in Science. I am wondering if scientists were to be yes-but and yes-and into their hypothetical Manifesto for Agile Scientific Research, which one would be on the left?

Is the Manifesto for Agile Software Development Relevant to Science?

"We are uncovering better ways of developing software, by doing it and by helping others to do it...." Scientists are not developing software, nor do they do research for customers (per se), so how much of the Manifesto is really relevant?

Suppose we make a few small changes to that manifesto? I used the following modified version to lead some thought exercises during the Scrum Training:
Draft: Manifesto for Agile Scientific Research

We are uncovering better ways of performing Scientific Research by doing it and helping others do it.

Through this work we have come to value:
  • Individuals and interactions over processes and tools
  • Scientific discoveries over comprehensive documentation
  • Collaboration over contract negotiation
  • Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.

(with apologies to Alistair Cockburn and company!)
This is the approach that the devops movement has taken, modifying the Manifesto to identify more directly with the challenges of running systems. But will it work for Science?

Step one is to try it on for size. Look for some practices that feel right or feel wrong. (I will skip the positive examples. Most companies that try this exercise find that the decisions that value stuff on the left are generally better both for their customers and for themselves than those decisions that value stuff on the right.)

Publish, Perish or Discover?

"Publish or perish" is a well known fact of life in academic circles, and it is even more true in the Scientific community. To succeed as a scientist, you need to get published as the lead author (with a bunch of minions supporting you!) in an important journal. But what if your research is too big for one person? What if you're part of team? How can you reconcile working in a team when your career requires you to shine as an individual?

This proved to be a hot topic in the scientific community! Some scientists even questioned whether scientific discoveries and the published paper aren't the same thing!

Publish or perish is something of a fact of life, but it is in conflict with the needs of complex research -- think CERN with its billion-dollar, multi-decade research mandate. How many lead researchers can there be? What is the interest of a researcher to be a team player in a complex field, if the industry does reward such efforts?

This draft manifesto suggests that better ways of doing research will value discoveries over individual glory and that changes to the current rules of the game will be good for future discoveries!

Towards a Culture of Continuous Improvement

I led my class through an exercise of identifying cases where the institute already values things on the left. These precedence cases confirm the validity of an Agile approach.  Then they identified potential areas of improvement the would come by valuing stuff on the left more.

Then they prioritized these potential improvements to identify what would help the organization most. This produced a backlog for starting a continuous improvement in the research process. The most exciting part was watching the light go in in people's eyes when they saw how this process, if implemented consequently, could turn any organization into an awesome place!

Agile Scientific Research?

Being Agile doesn't mean simply doing Scrum (although Scrum may well prove useful in many scientific contexts). The juxtaposition of things that we value, e.g. discoveries and publishing, provides the basis for some fascinating discussions, which are resonating with the deeply important issues of the wider community.

The Manifesto for Agile Software Development is powerful tool for understanding the priorities in an organization or industry, determining whether you are really setting the right priorities, and for identifying improvements to make the organization (or even the industry) more effective. It naturally leads an organization to a culture of servant leadership. With a little bit of modification, it can serve many different human endeavors, including scientific research.

I hope that the principals involved here will remain intrigued by what they learned in their Scrum course and start to build a community beyond their institutional boundaries to look for better ways of performing scientific research, by doing it themselves, and by helping others to do it.


Matt Libby said…
A late typo comment here: in your sixth paragraph, I think you meant to say "So both approaches, yes-but and yes-and, have...". Instead, you have two instances of "yes-but" in that sentence.

Thanks for the article!
Peter said…
Hi Matt,

Thanks for catching this! Fixed. And I wish, I too had responded quicker ;-)


Popular posts from this blog

Sample Definition of Done

Why does Scrum have a Definition of Done? Simple, everyone involved in the project needs to know and understand what Done means. Furthermore, Done should be really done, as in, 'there is nothing stopping us from earning value with this function, except maybe the go-ahead from the Product Owner. Consider the alternative:
Project Manager: Is this function done?
Developer: Yes
Project Manager: So we can ship it?
Developer: Well, No. It needs to be tested, and I need to write some documentation, but the code works, really. I tested it... (pause) ...on my machine. What's wrong with this exchange? To the developer and to the project manager, "done" means something rather different. To the developer in this case, done means: "I don't have to work on this piece of code any more (unless the tester tells me something is wrong)." The project leader is looking for a statement that the code is ready to ship.

At its most basic level, a definition of Done creates a sh…

Scaling Scrum: SAFe, DAD, or LeSS?

Participants in last week's Scrum MasterClass wanted to evaluate approaches to scaling Scrum and Agile for their large enterprise. So I set out to review the available frameworks. Which one is best for your situation?

Recently a number of approaches have started gaining attention, including the Scaled Agile Framework ("SAFe") by Dean Leffingwell, Disciplined Agile Development (DAD), by Scott Ambler, and Large Scale Scrum (LeSS), by Craig Larman and Bas Vodde. (Follow the links for white papers or overviews of each approach).

How to compare these approaches? My starting point is Scrum in the team. Scrum has proven very effective at helping teams perform, even though it does not directly address the issues surrounding larger organizations and teams. An approach to scaling Scrum should not be inconsistent with Scrum itself.

Scrum implements a small number of principles and constraints: Inspect and Adapt. An interdisciplinary Team solves the problem. Deliver something of va…

What is the role of a Business Analyst in Scrum?

When I teach a CSM class, my goal is that my participants go home delighted (and of course that they learn about Scrum, that they are motivated to do Scrum, and can pass the online CSM exam). So after every class, I ask for feedback, in particular what could I do to get a better score. And for the next class, I strive to implement or address two or three of the points raised by my participants.

One issue that was raised was unanswered questions. It is annoying to ask questions and not get answers! Time is limited, so it is not always possible to answer all questions, so I thought, why not answer them on my blog? So here goes, first question:
What is the role of a Business Analyst in Scrum? This question is a challenge because Scrum doesn't answer this question! Scrum is a simple, team-based framework for solving complex problems. The roles and ceremonies in Scrum are designed to ensure that inspect and adapt can occur regularly with complete and correct information. Scrum does not…