I've been enjoying quite a lot of literature, all published within the last ten years, on how to handle projects, ideas, development, thinking, and so in with processes like Extreme, Agile, or Lean. I have searched for similar literature on academic research and projects, but I couldn't find anything modern and relevant that links various parts of the research process, such as project management, hardware/software/experiment development, or refactoring of collaborative writing.

Are there any recent publications about applying these methods to academic research?

  • Some people think the question is too broad. Can you please make it more specific, as it risks being closed. – Dave Clarke Feb 19 '14 at 14:26
  • The question is not focused and is not clear what to answer, Please rewrite it so it remains open and active for answers. – Espanta Feb 19 '14 at 16:46

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 requirements.

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 identified.

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 shippable.

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.

| improve this answer | |
  • 1
    Thanks for this answer. Would you consider adding a few lines explaining "scrum"? Until I saw this answer I had never heard of it. Worse, the idea that there are highly formalized models and/or software for managing interactions with PhD students was also totally unknown to me. (And I have PhD students...) Please help? – Pete L. Clark Feb 19 '14 at 14:36
  • 1
    @PeteL.Clark: Done (albeit somewhat lazily). – Dave Clarke Feb 19 '14 at 14:44
  • 1
    Dave: thanks very much. I admit that I am so clueless that "this is a thing" that I didn't even think to check whether there was a wikipedia article. (Although eventually I would have googled it, of course.) – Pete L. Clark Feb 19 '14 at 14:46
  • 1
    @PeteL.Clark: It's a neat idea. It works well in small software development teams, I hear, though adapting it to research still needs work. Research does not so easily break up into small chunks and you often get people saying "Same as last week", though of course this could be an indicator of problems. – Dave Clarke Feb 19 '14 at 14:53

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.