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!
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?
“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.)
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!
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!
|cookielawinfo-checkbox-advertisement||1 year||Set by the GDPR Cookie Consent plugin, this cookie is used to record the user consent for the cookies in the "Advertisement" category .|
|cookielawinfo-checkbox-analytics||11 months||This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Analytics".|
|cookielawinfo-checkbox-functional||11 months||The cookie is set by GDPR cookie consent to record the user consent for the cookies in the category "Functional".|
|cookielawinfo-checkbox-necessary||11 months||This cookie is set by GDPR Cookie Consent plugin. The cookies is used to store the user consent for the cookies in the category "Necessary".|
|cookielawinfo-checkbox-others||11 months||This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Other.|
|cookielawinfo-checkbox-performance||11 months||This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Performance".|
|mailchimp_landing_site||1 month||The cookie is set by MailChimp to record which page the user first visited.|
|CONSENT||2 years||YouTube sets this cookie via embedded youtube-videos and registers anonymous statistical data.|
|_ga||2 years||The _ga cookie, installed by Google Analytics, calculates visitor, session and campaign data and also keeps track of site usage for the site's analytics report. The cookie stores information anonymously and assigns a randomly generated number to recognize unique visitors.|
|_gat_gtag_UA_42152348_1||1 minute||Set by Google to distinguish users.|
|_gcl_au||3 months||Provided by Google Tag Manager to experiment advertisement efficiency of websites using their services.|
|_gid||1 day||Installed by Google Analytics, _gid cookie stores information on how visitors use a website, while also creating an analytics report of the website's performance. Some of the data that are collected include the number of visitors, their source, and the pages they visit anonymously.|
|NID||6 months||NID cookie, set by Google, is used for advertising purposes; to limit the number of times the user sees an ad, to mute unwanted ads, and to measure the effectiveness of ads.|
|test_cookie||15 minutes||The test_cookie is set by doubleclick.net and is used to determine if the user's browser supports cookies.|
|VISITOR_INFO1_LIVE||5 months 27 days||A cookie set by YouTube to measure bandwidth that determines whether the user gets the new or old player interface.|
|YSC||session||YSC cookie is set by Youtube and is used to track the views of embedded videos on Youtube pages.|
|yt-remote-connected-devices||never||YouTube sets this cookie to store the video preferences of the user using embedded YouTube video.|
|yt-remote-device-id||never||YouTube sets this cookie to store the video preferences of the user using embedded YouTube video.|
|COMPASS||1 hour||No description|
|cookies.js||session||No description available.|
|S||1 hour||No description available.|