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 do something similar with faculty meetings. 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): 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 collaborative, 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 visible and obvious a way as possible. Meet briefly and collaboratively when maximum value comes from meeting, not not 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! -----