Hands up if you love meetings… nobody?
It’s one of the most common complaints I hear from development teams: “Urgh! We have far too many meetings.” It’s not often true but that is their perception because the meetings felt boring and wasteful.
Meetings don’t have to be like that. I’ve just started reading a book called Meeting Design: For Managers, Makers and Everyone by Kevin M Hoffman (Two Waves Books, 2018) which I’m hoping will help me plan more productive, more meaningful gatherings in the future.
In this post, I offer a few simple rules to help meeting feel more manageable.
What does Scrum say about meetings?
The Scrum Guide outlines four sprint events with some recommendations about timings. Adjusting these for a two-week sprint (the Scrum Guide defaults to month-long sprint) it looks something like this:
- Sprint planning (4 hours maximum)
- Daily scrum (9 × 15 minutes, so 2¼ hours maximum as we don’t have a daily scrum on the morning of sprint planning)
- Sprint review (2 hours maximum)
- Retrospective (1½ hour maximum)
So, given my current company’s 35-hour week and two-week sprints, that adds up to 9¾ hours in meetings, or nearly 14% of the sprint.
Then there are the other gatherings and workshops that pop up throughout the sprint to clarify things, plan and design, and… other stuff.
I have found that setting ground rules for meetings can be very helpful. These are based on the rules we created in the digital communications team at the University of St Andrews for use in all meetings outside the standard agile events.
All meetings must have an agenda with clear objectives. The agenda (and any supporting documentation) must be included in the calendar in Outlook (or other calendar system) so everyone has access to it.
If there is no agenda then the meeting should be cancelled.
Start meetings on time.
Invite as few people as possible to meetings. The people invited should have a direct relationship to the meeting objectives. If there are people you only need for part of the meeting, where possible, try to arrange the agenda to address their items first.
Meetings should be 30 minutes’ long. You must justify through the agenda to extend the meeting to 45 minutes or 60 minutes; anything longer should probably be regarded as a workshop.
Timebox all meetings. Set a timer. When the timer goes off, the meeting ends.
The location must be appropriate for the kind of meeting being held. It must have enough seats and contain the right equipment (e.g. data projector, screen, whiteboard, etc.). If you can, get there early and set up any equipment before the meeting begins.
Obviously, in these days of online meetings everything is being done on Zoom, Microsoft Teams or Cisco Webex, etc. Consider whether webcams should be used—these can be useful to switch on at the start of the meeting while people are gathering and checking in with each other but it can help to switch them off when the meeting begins.
All meetings should produce actionable tasks (or those tasks must have been done during the meeting). These actions must be SMART (specific, measurable, achievable, relevant and time-bound) and someone must be responsible for each action. Make a decision about who needs to be informed about these tasks being completed, when and how.
6. Permission to leave
In meetings you have permission to leave if you have nothing further to add (this also goes for post-daily-stand-up discussions). Check with the other attendees before leaving, “Do you think you’ll need me for the rest of the meeting?” If they do need you later, they can always call you back in.
Meetings may end as soon as the objective(s) have been reached. The meeting does not need to fill the time available.
Don’t interrupt deep work
It is also worth considering when meetings are held. Knowledge workers need time to get into a state of flow, what computer scientist Professor Cal Newport calls deep work. This is when they are most productive and can remain in that state, if uninterrupted, for a few hours.
It makes sense, then, to schedule meetings at times when it won’t interrupt a developer’s most productive time of the day (you’ll need to figure out from your own team when that might be).
For example, if you have a stand-up meeting from 10:15 to 10:30 and schedule a refinement meeting at 11:00 there isn’t enough time for any of the developers to get stuck into anything complex during the intervening half-an-hour, so it may be best to move the refinement meeting to 10:30.
In my team at St Andrews, these rules improved engagement and energy in meetings. The right people were in the room, they had clarity about why they were there and what contribution they could make, they had supporting documentation up front, and were empowered to make decisions during the meeting about when to leave.
Feel free to use or adjust these meeting rules in your own teams.