Effective Team Meetings

I've just sat in on one of the weekly team meetings run by our dev team - they've been getting really good at these meetings lately so I thought I'd share some of my observations...

There's lots of other stuff that can happen in meetings, but the core foundations are listed here - without these core components, the meeting will be a shipment of fail.

Before the meeting

Start by creating a wiki page for the meeting (at least 3 days in advance):

• Page title should be in "yyyy/mm/dd - meeting title" format
• When / where will the meeting will take place
  • If it's a webinar or teleconference be sure to include login details, PIN number, etc
• Who is attending
• Outline the objectives and the agenda (which should be based on objectives)
• The first objective should be "Weekly roundup" - each member of the team recaps what they've been working on since the last meeting

The meeting should last for roughly 1-2 hours depending on the topics covered. Most team meetings last about 45 minutes.

Above all: The meeting must happen! It doesn't matter if key people aren't able to attend, the meeting must go on.

Chairing the meeting

The meeting should ideally be chaired by a project manager, not the team leader. The chair is responsible for making sure everyone takes part and recording notes from the meeting.

In face-to-face and webinar meetings, it's a good idea to make sure everyone can see the agenda page in the wiki. As soon as the meeting starts (see below), the page should be put in to edit mode so that the chair can add action points and tick off objectives and agenda items.

The chair should tick off objectives and agenda items as they are discussed (in wiki notation use (/) which gives ) - you can then see at a glance what's been discussed and what hasn't.

About an hour before the meeting starts, the chair should Yammer (or use some other form of group notification system) the start time and ask participants to get in touch for the meeting wiki page URL. This allows the chair to quickly ensure that required participants are online and ready for the meeting - as well as flagging up any missing participants who can then be located prior to the meeting.

At the start of the meeting

Allow a few minutes for everyone to get settled - but as soon as everyone is ready idle chat must stop so the meeting can start.

Each member of the team should start with a quick recap of what they've worked on since the last meeting (remember, these meetings are weekly) - in particular where are their projects up to and are there any problems.

To keep these recaps short, ignore things that are going well - if a project is finished, say that and don't elaborate. Save time for discussion of any problems.

If any problems are raised they should be added to an action list if they can't quickly be dealt with during the recap.

Middle of meeting

Once everyone has recapped what's happened in the last week, discuss upcoming projects and events, changes to procedures, etc. It's at this stage that the key meeting objectives start getting ticked off.

End of meeting

Any longer topics need leaving to the end of the meeting and need to be strictly controlled by all participants so they don't run on for too long.

In the meeting we've just had, the "long topic" was a discussion of our plugin release process both for open source plugins and also bespoke plugins commissioned by customers. We identified that some additional info was needed on project wiki pages in our intranet so that any member of staff can quickly determine a) when the plugin will be released and b) who it can be released to (eg. is it open source, or just for a specific customer).

All of these notes were added to the meeting page as well as an action item to write some formal documentation in our developer intranet.

A key ending point is to check over the objectives and agenda to make sure everything has been done, make sure the action points are assigned to people responsible for doing them and then arrange the next meeting (usually same time next week).

In-meeting chat

You should also have some sort of IM or other chat service available to meeting attendees - both for broadcasting info (such as "look at this URL which relates to the topic we're now discussing) or direct messaging. There will often be small bits of information that need sending to everyone or one person during the meeting, often resulting in discussions being cut short because problems have been dealt with via text chat.

An example - if someone has a problem with something, while it's being discussed someone might IM a URL to a likely solution, which can then be quickly checked to see if it will work - if it does, end the discussion in the main meeting and remove the action point that was added to address the problem after the meeting.

Remember that Adaptavist is a bit of an odd company...

I must remind you that all our staff work from home - getting together for a face-to-face meeting is a bit of a nightmare, particularly when you have people working in different continents / time zones. As such, we've been adapting our weekly team meetings to make them highly efficient, focussed and effective.

Members of the team are constantly communicating with one another at all times via IM, Yammer, twitter, VoIP, Confluence and JIRA - the weekly meetings are designed to punctuate the distributed conversations in to one focussed meeting of minds, ensuring that everyone knows what's happened in the last week and what's going to happen next week and at any upcoming events.

Almost everything that's discussed in the meeting is usually already available in our JIRA issue tracker or Confluence wiki (the intranet parts that the public can't see) and has often been discussed between two or more members of the team prior to the meeting. The meeting either confirms or clarifies discussions held over the past week and ensures that everyone is aware of what's going on.

Now, if only we could make our management meetings that organised...