Vviewpoints
DOI: 10.1145/1831407.1831421
viewpoint
ScOre: Agile research
Group Management
Adapting agile software development methodology toward
more efficient management of academic research groups.
WOrKinG with AnD men- toring Ph.D. students is the central activ- ity in running an aca- demic 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
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 con-ference-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 prescheduled, we are able to reserve large
blocks of time (most afternoons) for
holding on-demand meetings, and the
meetings can be of varying durations—
as 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.
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
Photogra Ph FroM istocKPhoto.coM
