I have discussed previously on this blog about how well the Scientific Method adapts to Agile approaches. These ideas also took me to an unfinished effort to draft an Agile Research Manifesto. However, by talking to several people with similar ideas, I realized that these attempts were largely interpreted as an intellectual exercise with little practical application. It is clearly my fault for not having explained that all of this in reality comes from many practical experiences. Some of these experiences go back to my PhD years when managing the CLAM framework, as well as many undergrad student projects. As a matter of fact, during those days I published a practical guide for students on how to do their final project the “agile way” (I still keep the webpage, in catalan, for historical reasons).
In any case, in this post I wanted to address the practical side of agile research management by giving you a flavor of how I try to manage projects.
The anatomy of a research project
What am I talking about when I say a “research project”? Although they might be completely different in theme and even scope, all of the projects that I have in mind when explaining the agile management approach should share at least some of the following properties:
- Small-sized team: It is very likely that we are dealing with a one or two researchers team. A 3-4 people research team can already be considered large in my experience.
- Very open and imprecise requirements: Especially at the beginning, we might have a coarse idea or hypothesis to validate. However, the approach, method, and scope, are likely to be undecided until very late in the game.
- High risk: By definition, a research project has to be highly innovative and therefore… risky. Our goal is to minimize the cost of a failure and realize early on but not to remove failure since this is an intrinsic feature of risk.
- Imprecise resources: The fact that requirements are not clear and risk is high is usually accompanied by the fact that resources that can be allocated to the project are usually imprecise. If the project is highly successful and proves its interest in the first iterations, it can grow into something larger with more resources added to it. On the other hand, it is also very likely to be killed quickly if it does not yield promising initial results.
The planning game
I will usually start-off by devoting a couple of weeks to a Sprint 0 during which the main tasks will be:
- Understand what has been done before: Obviously, this requires lots of reading. However, it is good practice to also start writing at this same time, maybe in an informal wiki or the like.
- Define the tools: Unless you are in a very specific environment, tools are likely to change for every project. Sometimes it is not only about what is the best tool, but also about what the team is most familiar with. This is usually an important thing in most projects, but it is more so in a project that it is high risk in nature and should avoid spending lots of time/resources in adapting to new tools.
- Define the initial scope: There is no way you can have a complete picture of what is going to be the output of the project by this time. However, you should be able to list what you think will be the main steps and even some findings you anticipate. This list should be written like an ever changing Product Backlog (prioritized list of high-level features).
Prioritizing
One of the most important activities that you end up doing when planning any project, be it at the initial phase or at any of its iterations, is prioritizing the different requirements, stories… Doing this in a group meeting is a great way to gain insights on the project and to be strategic. Prioritizing tasks is not much different from any cost/benefit analysis: you measure cost, you measure benefit, and then sort items according to benefit/cost ratio.
In the case of project planning, I usually like to assign cost to “complexity”, and benefit to “interest”. In other words, the cost of a feature or story will be how difficult or complex we anticipate it is to implement it. And the benefit is how interesting or important it is for our final goal. Once you sort items using the interest/complexity ratio, you will find that easy-to-do yet interesting features float to the top, while complex and not so important sink down to the bottom.
Of course, the interesting discussions happen right in the middle. And especially when we have something that seems to be very important, but also very complex to achieve. In these cases, we feel tempted to jump right away at the problem and devote 100% of our energy to it. However, one of the agile principles is that things seem more complex when you don’t have enough understanding. If you put them off to later iterations, they will eventually become clearer and clearer and end up surfacing to the first positions on your priority list. I have found this sort of smart procrastination to be extremely useful for agile research management.
Iterate, Iterate, Iterate
Once you have come up with your initial product backlog, it is all a matter of breaking the process down in short iterations – I usually plan for one-week. At the beginning of each iteration (or Sprint), you look at your product backlog, pick some of the top stories and break them down into finer grain tasks. You do the prioritization game on this new list and come up with your next week’s scrum/iteration backlog.
When doing this finer-grain prioritization, I have found it very useful to use the estimated number of hours as the measure of “complexity”. Therefore, when picking the top tasks of our list, we will also have an estimate of how feasible it is to have them during this iteration and how much will be the relative effort put into each of them. And, if any task is estimated to be more than a day long, do yourself a favor and break it into several tasks.
Also, it is important that, especially during the first iterations, you realize that the continuation of the project might be at stake at each iteration (or at least the current approach). Therefore, when measuring the “importance” of tasks to prioritize, ask yourself how relevant will that task be to convince you and others that you are onto something or you need to change routes.
Test-driven research
If you are familiar with agile methods, you will probably know how important testing is in an agile project. Tests not only guarantee the stability of the project but are actually a way to specify requirements in a more verifiable form. In a similar way, you can think of specifying many of your research hypothesis as a test. For example, you can turn your hypothesis that the effect of a given procedure on your data or population is significant by a verifiable assertion that for t-test(D_original, D_after_procedure)-> p is smaller 5%. There are many hypothesis and research tasks that can – and should – be written in this form before making it to your prioritized todo list. At least you should worry on how any of your results will be validated and how you can trust for them to be consistent and significant.
Related approaches
If you are interested in this kind of approaches, I recommend you read the article on the SCORE method, which is somewhat related to many of the things I am mentioning here. Here you can read an interesting paper on doing test-driven research. Finally, I find the Pomodoro method a very interesting approach to individual time management. Since many research projects end up being quasi-individual, Pomodoro fits them pretty well.
