Meetings

The other day I retweeted what I thought was an interesting article from the Harvard Business Review about meetings. The idea was that to avoid those days of back-to-back meetings by scheduling 50, rather than 60 minute long meetings. In this way the day is punctuated with 10 minute interludes that allow one to catch up a little bit.

I thought it was a great idea, but in response someone asked "how does that apply to meetings to discuss 'issues' where an email with the answers would do?" This is a good question, and I can't help but notice that there's a lot of gratuitous meetings. I wanted to comment on my thoughts and ideas about organizing meetings optimally for an agile team. Absent the full opportunity to try out some of these ideas it is more theory that proven methodology. Nonetheless it's based on my own observations and a fair bit of discussion and background reading...so it's not completely off the wall.

Personally, and I've read others feel the same (can't remember who though!), just inviting me to a meeting is a huge mental burden. Compared to emailing me, IM-ing me or even stopping by my desk I find it considerably more invasive. Any one of those other low key approaches and I can probably be done in minutes without really feeling to imposed upon. If needs be I can ignore/deflect the interruption too.

But you send me a meeting invite and it's an entirely different proposition. As the allotted time approaches it tends to creep into my mind...especially when that "15 minutes to go" Outlook remind chimes in. I wind down in anticipation, wander off to the meeting room (or dial in to the call) -- we do the smalltalk as we wait for everyone to assemble, then we're done...then I go make some tea or something. Finally I sit back down at my desk and try and get back into whatever I was doing before. The cost of the meeting in terms of flow is high. This is especially true for some: see Paul Graham's "Maker's Schedule, Manager's Schedule" for a good explanation of why this is.

All this preamble brings me to my first premise of meetings: I'm only interested in really necessary ones. It's far, far too easy for people to adopt a default mode for addressing things by calling meetings. Only recently I and two of my colleagues were invited to a meeting to discuss a bug by the people that found it. Of course the bug didn't really need a meeting. All salient information about the bug could be communicated via the bug report and clarification handled through informal discussion. The meeting was all about impressing upon us the severity of the bug and just how much we needed to pull our finger out and fix it pronto. I'd rather be told that straight so we're all clear about people's expectations.

I digress; moving on...so if we're only to have "really necessary" meetings -- which for me right now is those recommended by Scrum and probably some requirements workshop/story writing/estimation type things -- then how do we deal with all that other necessary communication that must happen on a product development team? How do we get clarity on various issues, or thrash out design decisions, etc.? My answer would be to just go grab the colleague(s) you need and get to it.

That notion may strike fear into some people: "Eeek no, leave me alone, if you must talk to me book some time, I don't want to be interrupted like that without warning."

But there are ways to handle this. In the Paul Graham article above he suggests one approach. I think it's spot on for all the meetings people like myself and my management peers want to have with people on product development teams, namely try and put them at the very beginning or very end of the day. That way people are left with a big hunk of uninterrupted time to do their thing.

But for the intra-team communication that must happen, I think this would be too rigid. Something I believe is more suited here is the Pomodoro Technique. At it's very simplest you can understand this to work as follows:

• set a timer for 25 minutes and focus on whatever your next work task is without stopping until the end
• at the end of the 25 minutes take a ~5 minute break
• repeat
• at the end of four of these "pomodoros" take a longer break
  

It's more subtle than this, but the key additional points that I see are:

• don't permit interruptions when the timer is ticking: ignore email, IM, phone and people walking up to you (gesture pointedly at the ticking timer...)
• deal with any important interruptions during the breaks, e.g. go see what Bob wanted when he wandered over looking for you
• If Bob is also using the Pomodoro Technique he may either have decided to wait until you are free or started up another pomodoro (25 minute work session) of his own. Obviously if he's done the latter whatever he wanted wasn't that important...or maybe he IMed/emailed his question. If he's waited then maybe he's looking to work on something with you: it could even be done as a shared pomodoro.

I think this approach would be a very effective way of handling interrupts without ever forcing people to wait an unreasonable amount of time for access to another team member. I say "I think" because I've not had chance to put this fully into practice in a team with everyone agreeing to work this way. I've use pomodoro's myself as a simple way to just focus on getting stuff done. Procrastination is harder when using them. And it stops me from "allowing" myself to be interrupted. Based on that evidence alone I feel pretty good about how well it could work for a team. Organized this way I they would still be able to have frequent interactions as needed. But they wouldn't be filling up their calendar with "meetings" just to talk to one another.

Of course one key enabler for this approach is probably co-location, maybe even ideally a shared team room/workspace where everybody sits. But even without that I believe it would be a good approach.

There's also a psychological benefit I believe to not having a calendar full of nasty white blocks of meetings. You wouldn't feel so much as though you had been subjected to a day of meetings, unable to "get anything done". Rather, you'd feel like you had been working all day long, some of that time collaboratively with your colleagues as you and they found it helpful.

Therefore, my second premise of meetings is: handling issues via informal discussion doesn't mean you need to be unpredictably interrupted all day long.

Of course there are meetings that have to happen. Sprint planning meetings, retrospectives, requirements workshops etc. And for these I believe it's key to adhere to a few principles to enjoy success.

First of all, any real meeting needs an agenda, preferably with each item on it timeboxed. I've been known to reject invitations or at least tersely question the sender in the absence of agendas. Now obviously you can't go around doing that to everyone...but for a group of peers running a Scrum product development team everyone is free to call out colleagues requesting meetings that are all too vague.

Additionally it's important that any meeting is well facilitated: who's keeping notes? Who's ensuring we stay with the agenda? Who helps encourage the less talkative members of the team to voice their opinions? Some of these things can be shared amongst a good team, but having an identified facilitator makes for a good experience I believe.

Given how invasive meetings are they should be of a reasonable duration. I particularly liked that idea from the HBR of stopping 10 minutes early to avoid filling up entire hours. Multi-hour meetings (like spring planning) should have built in break times and they should be kept to.

Lastly, good meetings need respect from and for all participants. In particular I see the following as key:

• give people and their ideas and contributions a fair hearing
• invite people who haven't yet made contribution to volunteer their opinion
  
• be there and start on time -- lateness is a lack of respect unless there is a good reason
  
• quality phone communications (rooms with poor hardware or acoustics plain suck for those on the other end of the phone)
  
• make the effort to be clear for those not physically present (i.e. those on the phone)
• use a webex if appropriate -- it helps those not in the room follow along
  

Thus my third and final premise of meetings is: if we're going to have a meeting, let's bloody do it well.

Yeah, I'm biased about the not physically present stuff...I do so many meetings over the phone :-)