Some people and some organisations like meetings. If you drop Agile with its Agile Heartbeat into the mix then you might find that meeting madness strikes.
I’m a Kiwi living in the UK and I’ve noticed the British will form a queue if given the barest of excuses. Similarly, in some organisations, the people will call a meeting at the drop of a hat. People in coordination roles (e.g. project manager, discipline lead) seem particularly prone to this.
Don’t.
Less is more
Stop the Meeting Madness
(from Daxko)
Meetings are a symptom of bad organization. The fewer meetings the better.
Peter F. Drucker
I would add the two words “too many” to the front of Peter’s statement. Put another way, fewer meetings is always good, but no meetings would be bad. Some meetings are essential.
The trick is retaining the essential meetings and abandoning the time wasters.
Good meetings
I think meetings are great for sharing and synchronisation. Meetings are pretty rubbish for making decisions. Use meetings for sharing. Make decisions somewhere else.
The Agile Heartbeat comes with a bunch of meetings. The various planning meetings are very much about synchronisation – planning what needs doing and who will do it. This is particularly true for the daily stand up (aka Scrum) but I often drop in public service announcements at the start or end of these meetings – an information sharing opportunity while everybody is together.
The Scrum of Scrums is a synchronisation meeting too. I don’t run a Scrum of Scrums for my programmes, instead I have a weekly meet up for the workstream leads. But the goals are similar. The primary focus is what do we have to do to fix each other’s problems. With that in mind I don’t have a fixed or pre-set agenda. We make the agenda up on the spot and when we’ve gone through the list we finish the meeting.
Product demonstrations, which in Scrum or XP happen at the end of a Sprint and in Kanban happen at more flexible moments, are a information sharing meeting. A chance to get everybody up to speed on the latest drop of the product. I like to call these “Show ‘n’ Tell” sessions to emphasise the sharing aspect.
Information sharing can be a real draw card. When I had a team of 105 spread across a large building the monthly team meeting was one of the few things that made the team seem like a team. Although I had management stuff to share I tried to minimise that portion of the meeting as it was rather dull by itself. The juice, and the draw card, came from guest speakers. And interestingly, the guest speakers were from inside the team. Each month a couple of people would share something interesting from their teams. This was so popular that not only did my team turn up but people from other teams also came. Not bad for a “team” meeting.
Meetings to avoid
As I said I think meetings are pretty rubbish for making decisions. You should make decisions somewhere else.
Sign off meetings are top of my love to hate meeting list. Usually this type of meeting involves a big bunch of people going through a lot of detail to decide something they are not really qualified to decide. I try to avoid these. In general and certainly in my teams. “Sign off” is a decision point. Signing off is not important. Deciding is. I don’t seek approval from outside for decisions that should be made inside the team. I’m happy to decide on behalf of my team. If I’m not qualified to decide then I’ll delegate to somebody who is. Then, if it helps, I’ll tell interested stakeholders what we’ve decided.
Product owners can easily fall into the trap of abdicating responsibility to a group. They often have a lot of stakeholders to canvas before dropping requirements into the development team. One way of doing this, a bad way, is to bring the stakeholders together to decide what requirements to prioritise. I think a product owner that calls this kind of meeting doesn’t understand their role. It is fine to call a meeting to gather suggestions, and feedback what the team are doing, but the product owner should make the decisions themselves.
Barely sufficient meetings
You also have a problem if the Agile Heartbeat starts to dominate the team’s time. These meetings should provide a useful framework for the real work, not interfere.
The secret is to find a balance. The phrase “barely sufficient” is used in Agile to describe how much documentation should be produced by the team. I believe the same is true for meeting. You need meetings but aim for barely sufficient meetings. If the wheels are dropping off then have more or longer meetings. If you spend all your time in meetings then cut back.
This post is part of my What do I do When … ? series. Please drop me a line or add a comment if you’ve got a question you’d like answered.