January 30, 2018, by Raphael Velt
What are Agile processes and how do they relate to research?
In a previous post, we’ve discussed how we’re using Agile methods to deliver Research Data Management (RDM) services. We now explain what these methods are, and how they relate to the way researchers work.
Agile methods have their roots in the world of software development. Traditionally, software would be developed the same way as other engineering works. There would be a first phase in which clients discuss their needs – the requirements of the project. Then, designers and software architects would turn that into detailed specifications that list all the things a piece of software does. Finally, developers and software engineers would code and build the actual software. After some testing, software would be delivered to the client. Because each stage depends on delivering the output of the previous stage all at once, this way of building software is called ‘waterfall’.
There are multiple issues with waterfall software development. First, because of the time dependency at each stage, delays in delivery tend to add up over time, and there are few possibilities for phasing delivery by delivering feature packages over time. Secondly, if the early stages don’t get the requirements right, then the design right, it is very difficult to change things at the point where the client gets to see the result. But software is very complex by nature, and the fast changing nature of the IT industry means that needs, expectations and technological solutions will change over the course of the project. Issues with the waterfall process led to a high rate of failure in large-scale IT projects.
In reaction to these failures, groups of software developers and engineers have challenged that approach. The Manifesto for Agile software development calls for better collaboration, within development teams, across roles, and with clients. Agile processes embrace change and adaptability, and aim to deliver working software continuously, rather than at the end of the project. They are iterative by nature, and they seek to refine their understanding of clients’ needs at the same time as they deliver solutions.
Agile is a global approach, with many possible variations. In practice, specific methods have been created to implement the Agile mindset. One of the most famous methodologies, Scrum, offers a well-defined way of dividing and planning work into short time frames called ‘sprints’.
So, how does that relate to research? Well, one of the reasons Agile works well with software development is that software design questions are ‘ill-structured problems’: they are not problems where there is a clear, unique solution, a well-defined path towards it, or where all constraints are known from the onset. In fact, it is generally the case that the framing of the initial ‘problem’ expressed by clients will change over the course of the project.
Likewise, in a research project, or over the course of a PhD, a research question is likely to change over time. Researchers do not know in advance what their findings will be, and their way of addressing a problem will change as they get a better understanding of it, so in a sense, research has been an agile environment before the word was popularised.