The paper Adapting Scrum to Managing a Research Group by Michael Hicks and Jeffrey S. Foster, describes the experiences of adapting Scrum to running a research group.
For those who don't know about Scrum, wikipedia has the following:
Scrum is an iterative and incremental Agile software development
framework for managing software projects and product or application
development. Its focus is on "a flexible, holistic product development
strategy where a development team works as a unit to reach a common
goal" as opposed to a "traditional, sequential approach". Scrum
enables the creation of self-organizing teams by encouraging
co-location of all team members, and verbal communication among all
team members and disciplines in the project.
A key principle of Scrum is its recognition that during a project the
customers can change their minds about what they want and need (often
called requirements churn), and that unpredicted challenges cannot be
easily addressed in a traditional predictive or planned manner. As
such, Scrum adopts an empirical approach—accepting that the problem
cannot be fully understood or defined, focusing instead on maximizing
the team's ability to deliver quickly and respond to emerging
Scrum is built around the idea of a sprint, a short burst of activity. Again, from wikipedia:
A sprint (or iteration) is the basic unit of development in Scrum. The
sprint is a "timeboxed" effort; that is, it is restricted to a
specific duration. The duration is fixed in advance for each
sprint and is normally between one week and one month, although two
weeks is typical.
Each sprint is started by a planning meeting, where the tasks for the
sprint are identified and an estimated commitment for the sprint goal
is made, and ended by a sprint review-and-retrospective meeting,
where the progress is reviewed and lessons for the next sprint are
Scrum emphasizes working product at the end of the Sprint that is
really "done"; in the case of software, this means a system that is
integrated, fully tested, end-user documented, and potentially
The emphasis is thus on highly dynamic, short cycles of work, and interaction between the team
members and the customer to get the right product delivered by rapidly ensuring that the development team is on target.
Now, returning to the paper: it advocates 2 or 3 short meeting per week with the entire research group, rather than infrequent meetings between supervisors and PhD students. In these meetings goals, progress and achievements are reported on frequently. One outcome is that it helped quickly identify when a student was off-track, unmotivated or stuck.
I used the technique for my research group for a while. It was good for the various members to learn about what the others were doing, but as everyone was doing quite different things, in the end it didn't create any synergies I'd hoped for. Now that I am in a different institution and the new research group works on topics that are closer together, I think it could work, but we've decided to use a different approach to our research meetings.