TITLE: More on Reducing Meetings, Agile-Style
AUTHOR: Eugene Wallingford
DATE: June 09, 2010  4:38 PM
DESC: 
-----
BODY:
Recently I shared my fixation with a tweet from Kevin
Rutherford about replacing unnecessary weekly
meetings with ad-hoc stand-up meetings and a status
wall.  I have been imagining how I might
<A HREF="http://www.cs.uni.edu/~wallingf/blog/archives/monthly/2010-06.html#e2010-06-07T22_19_17.htm">
   do something similar with faculty meetings</A>.
Most CS faculty prefer to work on the courses, their
research, and their outreach activities than to go to
business meetings.  Perhaps there is a better way.

Not all meetings are created equal.  What sort of
meetings are there, and which could be replaced with
other mechanisms?  I like Keith Ray's taxonomy from
a message to the XP list nearly a year ago (June 15,
2009):
<UL>
<LI> meetings to make decisions </LI>
<LI> meetings to gather and disperse information </LI>
<LI> meeting with no decisions, not much information,
     and no collaboration </LI>
</UL>

The first two types are the kind of meetings worth
holding.  Sure, some decisions can be made by e-mail
or some other technology, with a little straightforward
discussion followed by the sending of votes.  We can
also share a lot of information, using e-mail, wikis,
and various collaboration tools.  Whenever I can, I
ask the faculty to make decisions via e-mail.  This
works well for decisions with a narrow range of
well-understood alternatives, where the decision does
not require the group to find any new common ground.
I also try to disseminate as much information from
outside the department as I can via e-mail, mostly
where the new information isn't likely to lead to a
wider discussion that we might want or need to have.
Finally, I try to collect as much information from
the faculty as I can without holding meetings.
Sometimes this data can be assembled and either used
by me or passed on to outside agents without need for
us to meet.

But even agile software developers recognize the
need for meetings to make decisions and to gather or
disperse information.  We hold collaborative meetings
for tasks such as release planning and iteration
planning, in which we make decisions about the work
we want and need to do in the short term.  We hold
short daily stand-ups meetings and conduct periodic
retrospectives of our work, in which we share
information about our progress and gather communal
information that helps us to improve how we work
individually and as a team.

All of these meetings are valuable, even necessary,
and sometimes enjoyable.  The key distinction between
these meetings and the meetings that people usually
complain about is that they are <B>collaborative</B>,
with everyone participating in the conversation, with
decisions actually being made (not just handed down
from above), and with everyone's learning being fed
back into the system to make it work better.

I do my best to limit most of the meetings I call to
these two categories, and try never to call a meeting
with no decisions, no information to share that
requires discussion, and no collaboration.  I am
pretty confident that our meetings aren't legacies
that originally had a purpose but now only fill a
time slot.  In fact, we don't meet weekly any more
because we all could see that there was not enough
business to keep us busy every week.  Of course, if
we all got excited about long-term planning, we could
meet and talk every week but that is not the nature
of our faculty.

All that said, I still wonder whether we could be
more productive and happier with something like
what Rutherford describes.  Focus whenever possible
on small, frequent releases, and track progress in
as
<A HREF="http://xprogramming.com/articles/bigvisiblecharts/">
   visible and obvious</A>
a way as possible.  Meet briefly and collaboratively
when maximum value comes from meeting, not <I>not</I>
meeting.

There are limits to how far one can take this approach
in a large bureaucracy like a university.  Mandates
come from above that require collective discussion
and decision, even when we in the department have
little interest in the issue, perhaps even an active
disinterest.  But that should not distract us from
doing the best we can with what we do control.  As
legendary teacher and coach John Wooden used to say,
there is no point in worrying about what you don't
control; that only steals energy and time from
accomplishing as much as you can with what you do
control.  So, we should try to be as agile as we can!
-----