Agile Science #3: Xavier came up with Agile Research a decade ago

As described earlier here in this blog series, science has been very slow to respond to Lean and Agile. However, the earliest signs of a science person doing an intellectual exploration of Agile goes back almost ten years. 

When I first started to google for the concept ”Agile Science”, I quickly found stuff signed Xavier Amatriain, a Catalan computer scientist (although he chose to call it Agile Research). For example, in a presentation on SlideShare from 2008, he describes how Agile methods are used in the software industry, and then speculates how it could be used in a scientific process (see slide below).

.

He even wrote a draft for an Agile Research Manifesto in 2009!

 

 

I got in touch with Xavier by email.

Hi, Xavier! Tell me a little about your background and how you came to be interested in Agile.
I have been in research and research management for quite some time. Even as I was doing my Ph.D. back in the year 2000, I was already managing teams of researchers and open source developers around the world. After my Ph.D., I went on to manage research teams both in academia and industry. I eventually went completely into the industry, but I have always managed teams with a very strong research component.

What was the response when you wrote about the concept Agile Research in 2008–2009?
To be honest, I did not invest at all in promoting the manifesto beyond some blog posts. What I was writing seemed mostly “common sense” and I was more interested in sharing my research projects. So, while I did get some response, especially through a LinkedIn group I created to discuss Agile Research, it was not very impactful.

What was the outcome of your early initiatives, e.g. the Manifesto?
As I mentioned, I did not seek nor get much public impact, so the outcome was mostly in my most immediate circles and projects I managed.

How are you using Agile today in your current work position?
Agile is now part of everyday technical work in all innovative tech companies. I now work in a small startup in the Silicon Valley after having managed teams at companies such as Netflix and Quora. The interesting thing now in the Valley is that most innovative “agile” companies rarely talk about Agile anymore.

On the one hand, it is assumed that you need agility to succeed, and practices like Scrum or the like have a bit of a bad name because of the way they have been implemented in larger corporations. However, all startups try to be lean and agile. As a matter of fact, if you read about the popular “Lean Startup” approach you realize that most of it is borrowed from agile methods, and it has a lot of similarities with my original thoughts around Agile Research.

In general – how to do think science can benefit from Agile?
Science, in general, should aim to be Agile. There is a lot of value in scientific research in designing smaller experiments, having continuous feedback, and iterating while adapting requirements to the new data. Even in longer, larger projects, it is beneficial to find the way to break them into smaller increments. Science, even more so than software development, is a learning process. You cannot expect to have the complete specification of what you are going after from the beginning.

Which special modifications have to be done when using Agile in a scientific setting?
Probably the biggest difference in a scientific setting is that there is no clear “client” with whom you can discuss the results of each iteration. Because of that, it is important to find who can take on that role. In my experience, this generally has to be the mentor or manager. However, that does introduce a set of requirements on how that person/people are able to provide meaningful and continuous feedback.

1 reply
  1. SmoothStack
    SmoothStack says:

    Once requirements were complete and development had begun, change was just not something that was easily entertained. Let’s keep in mind that concepts such as Continuous Integration and Configuration Management were unknown and use of source control repositories was not as mainstream as it is now. A change in requirements was just quite difficult to accommodate and was generally frowned upon.

    Reply

Leave a Reply

Want to join the discussion?
Feel free to contribute!

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.