Agile methods on software development are very popular. The root of these methods must be sought in the on the Agile Manifesto that says:

In short, these lines says that the world is always changing, the adaptation to change, the collaboration between people and the transfer of knowledge should be a priority in our professional life.

These objectives fit with software development but also with research because, we software developers and researchers are always looking for new challenges, always updating our professional network and making improvement in science.

The scrum methodology is the most popular of the Agile methods in software development. Like others agile methods, Scrum focus on quick adaptability to changes on the developed products and prefer  face to face communications between the members of the team and the customers (from the Agile Manifesto), but also, scrum declares some formal activities, roles on the development team and tools that must be used with that method.

Scrum declares the following activities:

• Sprint planning
• Sprint
• Daily meeting
• Review
• Retrospective

Scrum also declares the following team roles:

• Scrum master
• Research owner (or in general Product owner)
• Team

And finally exposes these tools:

• Research backlog (or in general Product backlog)
• Sprint backlog
• Burndown chart

Scrum defines time periods called Sprint where the team will develop portions of their research (or in general products). On development teams, the work is something deliverable to the client. In a research environment, the final work of a sprint will be something that can be started and finished in the period and something that gives an added value to the research.

In general, the tasks to be done (in software development or research) will be listed in the Research  backlog (or in general Product backlog). The list must be ordered in descending order of priority. Important tasks must be done first.

At that point, you must define what is a task on your research. In our experience tasks is something that can be started and finished in a sprint. In a normal case, a full paper is not possible to write and review in a sprint, but parts of it can be done and finished in a sprint.

Examples of tasks can be:

• writing the introduction of a paper
• making a review of the literature of a theme
• write a short blog entry
• writing a questionnaire
• preparing an experiment
• …

Prior to starting a sprint, the Research team will do a meeting in order to plan the work to do in the sprint (Sprint planning). From the Research backlog, the team will select the tasks to be done (those tasks with high priority). After selection the appropriate number of tasks to be done, these tasks must be moved to the Sprint backlog. Here appears the problem of measuring the work to be done. The work (or effort )to be done depends on the capacity of the team, the team size, the difficulty of the tasks and the sprint period. It is always related to the daily work capacity of each team member. Sometimes, effort or work equals to hours of work, but it always depends on how you want to measure your effort.

In our case and for simplicity, we measure our effort in hours. So, for instance, writing a short entry on a blog could be 8 working hours.  

Once the tasks are in the Sprint planning, the sprint can start. A typical period for a sprint is 2 or 3 weeks. These short periods let the Research team to add tasks to the Research backlog and change the priority of the already existents tasks. This is what the Agile manifesto call ‘adaptation to change’.

When the sprint is over, the finished work can be released and everybody on the Research team will show their work to the others members on the Review meeting.

Just after the meeting, and this is not a mandatory task, another meeting called Retrospective can be done. On the Retrospective meeting, each team member talks about the difficulties he had faced during the sprint, how he/she deal with it and how to avoid these difficulties in the future.

The daily work is the second important feature of the scrum methodology. On the daily meeting, each team member explains to their fellows what he did last day, what he is going to do the current day and what were the problems the member faced the previous day. With that information, the member can update the Sprint board and the Spring burndown chart.

Boards

The sprint board and the burndown chart are something optional but help the team know how they are performing. The Sprint board show the state of the tasks that must be done in the sprint.

Typical scrum boards from software developers have the following states (or a combination of them):

• Todo or Backlog
• Plan or Sprint backlog
• Develop / test / deploy or “In progress”
• Done

In our case, a Research team with only research activities and some software development, there are only 3 states: todo, doing, done. Every task in our sprint can be categorized in these states. Of course, every task will achieve the 3 states till being categorized as ‘done’ that is the final state of our board.

The Sprint burndown chart shows how was the work estimation and how we are performing against that estimation. In short, each day a quantity of work must be done and the chart shows if the accumulated work until the current day is done, something is left or more work than the estimated work have been done.

 

Conclusions

The improvement on the research is clear: the work to be done and their priority is something that must be done prior to start working. This is one of the main problems of research: tasks and priority are not always clear.

The estimated effort (or work) to be done in a period can be estimated without compromising other tasks. Tasks are ordered by their importance, so it helps to focus in a concrete part of the research.

The research and the team can be tracked because is easy to know what has been done, who did the tasks and what remains to be done.

Scrum is a methodology that any research team can use. The researchers do not need to be physically in the same place because this methods helps the team in both aspects: improving the team and improving the individuals.

What is important to understand is that Scrum is open to change. There are no fixed rules, you can modify every aspect. So If you do not need the daily meeting (in the case of working with people on other research centers), you can do a meeting every two or three days. If the Retrospective is not needed, you can skip it… Everything can be changed and adapted to our needs.

Scrum is interesting when tracking different PhD students. Although they do not work on the same research, this methodology helps the tutors to know in a quick way on what have been working every student and how the are performing.

If you want to read more, check out the following references:

1. Agile Manifesto
2. Scrum Alliance
3. Scrum.org