Academia Stack Exchange is a question and answer site for academics and those enrolled in higher education. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Startups I've been enjoying quite a lot of literature on how to handle project, ideas, development, thinking, etc, with theories such as Extreme, Agile, Lean, etc. All dating of less than 10 years.

I was looking around for similar literature on academic research and project, and couldn't find anything modern, socially-aware (eg. connected) and relevant, making links between doing, thinking, envisioning, writing and more.

I am thinking of the project management, hardware/software/experimentation development needed in the research processes, reafactoring of collaborative writings, etc.

Does someone have seen some initiative, publication, blog about this topic ?

Thanks !

share|improve this question
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
up vote 18 down vote accepted

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.

share|improve this answer
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
@PeteL.Clark: Done (albeit somewhat lazily). – Dave Clarke Feb 19 '14 at 14:44
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
@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

"STREAM Tools" is a technique for agile development of complex documents, such as academic papers, proposals, dissertations, etc.

share|improve this answer
Can you please expand this answer a bit, to give more than just the name? – jakebeal May 31 '15 at 3:40

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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