I recently completed Patrick Lencioni's Literary Fable entitled Death by Meeting. If you haven't read it, it is worth an afternoon. It is written as a literary fable so it is a quick read. In it, Lencioni highlights the ineffectiveness of meetings and how it drives an ineffective corporate culture. He highlights two primary issues with meetings in most organizations - the lack of conflict and context.

While the conflict side is interesting, I want to highlight meeting context and its relationship to Scrum. Lencioni states that most leaders have one kind of meeting - the staff meeting. I can attest to this in my previous role as a leader. The problem is that everyone in the room has a different agenda with respect to what they want from the meeting. Some are looking for coordination details, others tactical information about current projects, and yet others looking at strategic decisions. Attempting to address each of these in the same meeting leads to incompleteness in all of them.

Surprisingly, his proposal is to actually increase the number of meetings - not decrease them as you might expect. However, each meeting requires a distinct and appropriate context. Hold a short 15 minute meeting daily to coordinate activities. Hold a 1 hour weekly meeting to address tactical issues. Hold a 2-4 hour meeting each month and a 1-2 day offsite meeting each quarter to address strategic issues.

Does this sound familiar? Sounds like Scrum to me. Hold a daily 15 minute Scrum of keep everyone on the team in sync. Every couple weeks hold sprint planning and review meetings to address the tactical focus for the product. Every few months hold a release planning meeting to focus on the strategic product direction.

Some would say that Scrum is common sense - it is doing the simplest thing to get results. I agree and I think Patrick Lencioni would agree as well. So if you have some business or executive stakeholders who may not quite understand Scrum, introduce them to this book first, then begin to compare approaches. Sometimes coming at the problem from a non-agile perspective is the best way to influence those with agile filters on. If you have read the book and agree or disagree, I want to hear about it.