|
Status Meeting Protocols
In 2002, Michael Hicks and Jeffrey Foster joined the computer
science department at the University of Maryland as newly minted
assistant professors, where they began working together to establish
a research group. Faced with the need to mentor the students they
were hiring, Hicks and Foster deployed a strategy that’s nearly
ubiquitous among computer science professors: they set up weekly
meetings with each of their students to check in on progress and
work together on research problems.
For a while, this approach worked fine. Like many junior
professors, Hicks and Foster had only two or three students to
supervise and a relatively light load of additional responsibilities
outside of research and teaching. As they explain in a technical
report on research productivity that they published in 2010,
however, as their careers advanced, this standard mentoring strategy
began to “reach its limits.”
20
They went from supervising two or three
students total to six or seven students each. As their mentoring load
grew, so did their outside commitments to review papers and write
grants, further restricting their free time. Their weekly meetings with
each student became “extremely inefficient,” as they were always
scheduled for the same amount of time, thirty minutes to an hour,
which was almost never the right duration—sometimes they needed
only ten minutes for a status update, while other times they needed a
couple of hours to tackle a particularly hard problem.
Hicks’s and Foster’s increasingly busy schedules made it difficult
to fit in additional student meetings beyond those already scheduled
for each week. As a result, students began to fall through the cracks.
If someone was struggling on a problem, it could take a week before
any remedies could be discussed. Hicks and Foster also noticed that
one-on-one meetings failed to produce a sense of community in their
research group. “We had built up a set of great individual students,
rather than a collaborative research group,” they wrote. Considering
all these issues, their conclusion was simple: “Clearly, something
needed to change.”
The instigation of that change was a research meeting that Hicks
attended in 2006. He was chatting with his officemate from graduate
school, who had since gone on to become a software developer. The
old officemate began telling Hicks about how much he enjoyed
Scrum, the agile methodology his employer used to organize software
development work. Something about the idea resonated with Hicks.
When he returned to Maryland, he suggested to Foster that these
exotic organizational techniques from the world of software
development might be just what they needed to get their research
group operating more effectively.
I introduced Scrum, and agile methodologies more generally,
back in chapter 5 as part of our discussion of task boards. Of this
strategy’s various elements, the one that most resonated with Hicks
and Foster was the discipline of daily scrums. As you might recall, in
standard Scrum, software development teams break up work into
sprints: sessions lasting two to four weeks that are dedicated to
developing a specific set of features. During the sprints, the team
meets every morning for fifteen minutes, in a gathering called a
scrum. During this meeting, each person in the group answers the
following three questions: (1) What did you do since the last scrum
meeting? (2) Do you have any obstacles? (3) What will you do before
the next scrum? They then spend the rest of the day actually working
on their objectives. In software, this coordination method turns out
to be much more efficient than trading emails or instant messages
throughout the day. To enforce the fifteen-minute limit, and thereby
prevent the meetings from dragging on into time-wasting territory,
scrums traditionally require everyone to stand up.
Hicks and Foster adapted the daily scrum concept to their
research group. Instead of holding the meetings every day, they held
them on Mondays, Wednesdays, and Fridays. They also changed the
name to “status meetings.” Otherwise, the details remained largely
the same: these gatherings lasted for fifteen minutes, and everyone
on the research team answered the traditional three questions. They
even experimented with holding the meetings standing up and found
that, “surprisingly,” it really did help them stick to the constrained
time limit. Hicks and Foster would participate as well, updating the
students on their own daily activities. They called their modified
system SCORE.
A key to Hicks and Foster’s SCORE was clearly distinguishing
these status meetings from more involved technical discussions. If
during a status meeting it became clear a student needed a more
detailed discussion to make progress, a separate “technical meeting”
would be scheduled right there on the spot. Unlike the old weekly
meeting system, these technical meetings were scheduled only when
needed. Because their purpose was clear the moment they were
scheduled, they also tended to be very efficient—everyone arrived
knowing the goal of the discussion. As Hicks and Foster elaborate,
because they had cleared the standing weekly meetings with every
student off their calendars, there was more than enough schedule
space to fit these on-demand meetings as the need arose.
Curious whether their students shared their appreciation of the
SCORE approach, the professors conducted a formal survey of their
research group. They asked them to rate seven different aspects of
their research experience as graduate students, including “quality of
interactions with adviser,” “productivity level,” and “enthusiasm for
research.” For those students who were around before SCORE was
instituted, they were asked to also rate their experience with the old
way of organizing the group. “The responses were uniformly
positive,” Hicks and Foster summarize. “SCORE improved students’
experience in every way we considered.”
—
The regular status meeting strategy that Hicks and Foster extracted
from Scrum methodology is both a powerful and widely applicable
communication protocol. For many different knowledge work
settings, deploying these short meetings, three to five times a week,
can significantly reduce ad hoc email or instant message interaction
throughout the day, as everyone synchronizes during the regular
gathering. This trades the small number of cognitive cycles needed
for the status meetings for the large number of cycles needed to
achieve the same coordination through sporadic back-and-forth
messaging. As Hicks and Foster report, the regular rhythm of short
meetings also creates a sense of “momentum” that helps people both
feel better about their work and experience more productivity. It also
increases group cohesion, as everyone knows what everyone else is
working on.
This protocol brings with it some inconvenience costs. In
Do'stlaringiz bilan baham: | 
