Sign In

Communications of the ACM

Viewpoint

Score: Agile Research Group Management


View as: Print Mobile App ACM Digital Library Full Text (PDF) In the Digital Edition Share: Send by email Share on reddit Share on StumbleUpon Share on Hacker News Share on Tweeter Share on Facebook
circle of connected people

Credit: iStockPhoto.com

Working with and mentoring Ph.D. students is the central activity in running an academic research group. At the start of our careers as assistant professors, we took a fairly typical approach to managing student interactions: once or twice per week, we met with each of our students in prescheduled sessions of approximately half-hour or hour-long duration. However, this approach started breaking down as we gained more students and our other responsibilities increased: our time became fragmented and inefficiently used; hard-earned lessons were not shared effectively among students; and our group lacked any real cohesion or identity. In September 2006, we learned about Scrum,1 an "agile" software development methodology, and realized we might be able to solve some of the problems we were having by adapting it to our research group.

In this Viewpoint, we briefly describe the resulting process, which we call SCORE (SCrum fOr REsearch). We have been using SCORE for several years, and have discovered it has many benefits, some we intended and some that surprised us. While every situation is different, we hope others may learn from our approach, in idea if not in form, and that we might inspire further discussion of research group management strategies. A longer version of this Viewpoint, with more information and space for feedback, is available at the SCORE Web page.3

Back to Top

SCORE

The major feature of SCORE is its meeting structure, which consists of two parts:

Regular all-hands status meetings. Several times a week (late mornings on Tuesdays, Wednesdays, and Fridays in our group), the group meets for a 15-minute, all-hands status meeting, modeled after the daily "scrum" meeting for which Scrum is named. During the meeting each person gives a brief update on what they did since the last meeting, what problems they encountered, and what they plan to do for the next meeting. If someone cannot physically attend the meeting, they may conference-call in, but physical presence is much preferred. Everyone stands during the meeting, to encourage brevity.

Though brief, status reports are information-rich. Students report on a wide range of activities, such as progress in implementing code, carrying out an experiment, reading a paper, working on a proof, writing up a result, or preparing a talk. We encourage students to present their status to the group, rather than just to the faculty. Students may also say there has been no change in their status, typically because of classwork or for personal reasons.

On-demand research meetings. Whenever a student or one of us thinks a more in-depth, one-on-one meeting is needed, we schedule it on demand. Since only the status meetings are pre-scheduled, we are able to reserve large blocks of time (most afternoons) for holding on-demand meetings, and the meetings can be of varying durationsas long, or as short, as required. We often schedule on-demand meetings immediately following a status meeting, typically for the same afternoon.

We kicked off SCORE with a "research review day" of conference-style talks describing ongoing research projects, to provide context for the ensuing status reports. As needed, we inject some of these talks to inform the group of a new project or to "checkpoint" a recent major result. To help increase group spirit further, we have a weekly lunch, and we also hold a reading group one day per week.

Back to Top

Why It Works for Us

Though simple, SCORE works remarkably well for us. After nine months of using SCORE, we surveyed our students for feedback, and their responses were very positive. Since then, colleagues at various institutions have adopted aspects of SCORE, and they have offered us feedback. From these and our own assessments, we have identified the following list of SCORE's benefits. While none of these benefits is unique to SCORE, it is convenient that SCORE has them all.

More efficient time use for faculty. A major problem we had with prearranged meetings was schedule fragmentation. When a student had only a quick status update, the meeting slot was too long, and the remaining chunks of time were difficult to use. On the other hand, when a student had a deep technical issue to explore, the slots were too short. Because we had so many prescheduled meetings, subsequent discussion might have to wait a day or two, slowing progress. Moreover, context-switching frequently over the course of many meetings was very draining, reducing the meetings' effectiveness.

SCORE solves these issues very well by separating quick status reports from in-depth technical discussions. On-demand meetings have a clear purpose and are therefore much more productive than our weekly meetings used to be.

Improved productivity for students. By our own observations and those of our students, frequent student-adviser contact at SCORE status meetings has improved student morale and productivity. In response to our survey, one student said: "I like the frequency of the status meetings. Frequent meetings make incremental progress necessary: to have something to say at each meeting, you can't goof off for an extended period of time. Also, if you don't know where to go next, there isn't much time before another meeting, when you can get back on track. On the other hand, the frequency of the meetings means that, if something came up and you don't have anything to report for today, it's not a big deal; you'll have something for tomorrow or the next day."

Most graduate students struggle at some pointone study found "At [UC] Berkeley, 67% of graduate students said they had felt hopeless at least once in the last year."2 With thrice-weekly status meetings, we can identify struggling students quickly and therefore help them much sooner than we would have when meeting once per week.

Improved group identity and shared knowledge. By giving each person a window onto the activities of others, participants learn from others' successes and failures, which helps create a group sense of momentum and accomplishment. One student specifically commented he liked hearing about other students' progress: "I can follow other people's research and 'daily research routine.' That helps because it's interesting and I learn things, but also because I can compare my productivity and have a better idea of how I fare."


On-demand meetings have a clear purpose and are therefore much more productive than our weekly meetings used to be.


More than half of the students surveyed specifically cited a "research community" or "sense of belonging" as a benefit of SCORE. The students said they feel the joy of their fellows' successes, which then creates further motivation and enthusiasm for their own work. At the same time, one student mentioned it was consoling to learn that other students hit slow patches, too: "It helped me with the realization that everyone has rough patches and that it is not a big deal." Several students said regular social gatherings and proximate offices were also important in fostering this sense of community. One student said, "Status meetings and the office atmosphere make it worth my while to come to school." Finally, group meetings remove faculty as the bottleneck to developing new ideas or solving technical problems, as students offer advice and begin collaborations with their fellow students based on what they hear in the meetings.

Back to Top

Can SCORE Work for You?

Every research group is different and must find its own process that works best. We hope knowing about SCORE will prove useful to other groups, either as a new process to experiment with or as inspiration for other ideas. For example, instead of SCORE's status meetings there may be other good stategies to engender frequent contact and create opportunities for focused, in-depth meetings. Among others, some possible approaches are regular faculty "office hours" in a lab-space that co-locates many students; less formal "coffee hours"; or perhaps co-locating faculty with students. Lessons learned might be communicated more permanently by incorporating group mailing lists, wikis, or blogs. Prescheduled research meetings may also play a role, for example, for external collaborators who do not attend status meetings.

SCORE can also be further improved, as it is silent about some important elements of running a research group. For example, SCORE has no specific process for generating and discussing research ideas. Currently we explore ideas during the on-demand meetings, but doing so does not take advantage of the perspective of the larger group, nor does it give students a broader view of this process.

We encourage interested readers to read the longer version of this Viewpoint at the SCORE Web page,3 and to provide comments on the ideas and issues raised. The long version goes into more detail about running SCORE in practice, describes elements of SCORE that we tried but did not work for us, and reports more in-depth responses to our student survey. We look forward to further exploring strategies for mentoring and working with graduate students to produce high-quality academic research.

Back to Top

References

1. Agile Development Methods Inc. About ScrumOverview (2008); http://www.controlchaos.com/about/

2. Fogg, P. Grad-school blues: Students fighting depression and anxiety are not alone. The Chronicle of Higher Education. (Feb. 20, 2009).

3. SCORE Web page; http://www.cs.umd.edu/projects/PL/score

Back to Top

Authors

Michael Hicks (fmwh@cs.umd.edu) is an associate professor in the Computer Science Department and UMIACS, and an affiliate associate professor in the Electrical and Computer Engineering Department, at the University of Maryland, College Park.

Jeffrey S. Foster (jfoster@cs.umd.edu) is an associate professor in the Computer Science Department and UMIACS at the University of Maryland, College Park.

Back to Top

Footnotes

We would like to thank Jens Palsberg, Dan Boneh, David Notkin, Alex Aiken, and Kathryn McKinley for helpful comments on drafts of this Viewpoint. We would also like to thank all those who have given us feedback on SCORE, especially the students in the programming languages group at the University of Maryland.

DOI: http://doi.acm.org/10.1145/1831407.1831421


Copyright held by author.

The Digital Library is published by the Association for Computing Machinery. Copyright © 2010 ACM, Inc.


Comments


Xavier Amatriain

This is an interesting and worth-noting initiative. However, it is not the only one and , definitely, not the first one to introduce agile methods into research teams. So I miss some references...

We have been working on drafting an Agile Research Manifesto for some time now. It is available here: http://xavier.amatriain.net/AgileResearchManifesto/

You can find some background on how this started in this blog post: http://technocalifornia.blogspot.com/2008/06/agile-research.html

Also, it would be great to have you join the Agile Research LinkedIn Group to share some discussions on the topic.


Displaying 1 comment