Doing Agile for Research
There are many occasions where I was asked whether Agile is feasible to be used outside of software development or information technology (IT) in general. I said, ‘Hell yeah!” Well obviously I didn’t say it like that; at least not in front of an audience. I used something along the lines of “Definitely! If you take the IT or technical context out of Agile, it will still be relevant no matter what it is that you’re working on.”
Doing Agile outside of IT is really about defining the product. From there, we can do Agile just like how it’s done in software development, except for the actual work. We start by breaking down the requirements of the product, make them as clear as possible, and prioritize them. Prioritization highly depends on the product, but there are common criterias like difficulty and complexity. The more difficult or the more complex an item in the requirement, the lower it is on the list of requirements.
Next, we collaborate on what to do next, i.e. planning. Prioritization of requirements plays a crucial role in making this activity effective. Because Agile means delivering results incrementally and iteratively, planning is really about picking the most important requirement(s) to be done immediately.
After we agreed on the short-term work plan, we work. How we do this work depends on the nature of the product. The team knows best how to do this. What’s important in Agile is that we collaborate during work and, when work is done, we collaborate to review the result of our work against the plan we made earlier. If we agree that our current work result is accepted, we move on to the next important items in the list of requirements using the same incremental and iterative process. Simple, right?
What about doing Agile for research?
I actually stumbled upon a 2015 paper discussing the use of Agile for doctoral dissertation supervision [1]. It proposed a model on how to improve the quality and result of doctoral dissertation supervision by adapting Agile. The Agile model itself, in my opinion, is not new. Although it is tailored to meet the environment and needs in supervising a doctoral dissertation, the only difference in any common Agile approach is simply the product, i.e. the dissertation.
I’ve done this myself before. There was this one time when I work with 2 colleagues to write a paper. I took the lead by defining the title, the purpose of the paper, the general idea, and the outline of the paper. Those things were simply an initial definition of the product. It was open for changes in the future. The most important thing is that the requirements of the paper was clear enough so that the team can start working on the paper.
Back then, we’re doing weekly iterations. That means we plan, review, made modification to the requirements once a week. During work, i.e. gathering information and writing the paper, we collaborate as often as possible to align our individual work. This is important because, even though we make our tasks as independent as possible to one another, our combined work should be seamless. Once we’re done with one iteration, we continue with the next iteration using the same process.
When doing Agile for writing our paper, me and my colleagues didn’t follow any specific model. We did adapt some elements of the Scrum Framework like Sprints and some of the events. Our method was simply Agile with weekly Sprints added in. We do have a backlog, but it was simply a breakdown of the paper into parts small enough to be completed by any member of the team in a single week.
Fortunately the result was successful. With more frequent communication, we were able to have more discussion regarding the paper like which source should we refer to, the flow of the discussion in each section, what materials we need to gather, etc. Because of that, integrating our individual work was not really difficult. All that’s left to do was a little tweaking to make it look like it was not written different people.
That hands-on experience of using Agile for successfully writing a paper, the proposed model for Agile dissertation supervision, and my understanding of Agile made me believe that doing Agile for research is possible. Not only is it possible, doing Agile will also lift the experience of working on the research and improve the quality of the result. Moreover, the possibility of doing it is not limited to doctoral dissertations or papers, but also to any scientific writing in any fields of research.
That being said, we still need to consider the willingness and availability of related parties such as the researcher(s) or the supervisor(s). There is still a chance that in certain condition, considering all related factors, Agile is more of a burden instead of an improvement. In that condition, we can either find the lightest Agile method to use or go back to whatever works. Just remember that in it’s simplest form, Agile is really about more collaboration, higher responsiveness, and more frequent delivery of results in an iterative and incremental manner.
If you’re interested in the general concept of implementing Agile in different circumstances with no problem reading (translating) an article in Bahasa Indonesia, you might want to read “Agile Di Mana Saja” (translated to Agile Everywhere) here: https://medium.com/pemerintah-tangkas/agile-di-mana-saja-6e1e5910bc83.
References
- L. G. W. Tengberg, “The Agile Approach with Doctoral Dissertation Supervision,” International Education Studies, vol. 8, no. 11, pp. 139–147, 2015.
