A mad house or a meeting?

Depending on whom you ask and/or when you ask, meetings are a bane or boon.  Scrum practitioners often call the standard meetings ‘ceremonies’. The term confers a huge amount of gravitas to events that are just meetings.  What sets them aside from many run-of-the-mill conference calls is their explicit purpose.  

Mapping Scrum Ceremonies to Meeting Types

Event \ Type

Status Planning Decision Problem Solving Data Dumps

Refinement

F P

F

Daily Scrum

F P (micro)

F

Sprint Planning

F P

F

Demonstration

F P

F

Retrospective F P

F

 

P – Primary Intent

F – Failure Mode

The liberal use of timeboxing as an agile focusing technique requires whoever is facilitating a meeting to keep it on track or risk getting to the end of the session only to find out that you are not done and ask people to hang around. Having seen people’s schedules, I rather ask to borrow money than to borrow time. 

Having a primary intent does not preclude the pursuit of other secondary purposes on occasion. For example, the refinement meeting’s primary focus is to determine if work items are ready to be taken into sprint planning. If they are not, the people involved in the session will often use problem-solving techniques to get everything shipshape. There are areas that each of the Scrum ceremonies should not stray into or risk failure.  

None of the Scrum ceremonies are designed to be asynchronous data dumps.  Turning any of the standard meetings into data dumps will cause people to check out. Each of the specific meetings has different no-go zones in addition to the data dump morass.  For example, the Daily Scrum turns into something else when it is used for a status meeting. In the Daily Scrum you know you have hit a failure mode when you begin to have attendance problems or become a haven to catch up on email.  

Status comes close to the same morass as data dumps.  At a team level, team members, which include the Scrum Master and the product owner, interact with the “board” or talk to other team members to understand status.  At a program level, status is generally shown as summaries or roll-up of reports from whatever story tracking approach is being used. I have seen organizations that supplement the standard Scrum Meetings with separate status meetings (not a favorite) or use other tools to capture and communicate status. 

Each of the core events identified in Scrum has a primary intent. Any meeting that wanders too far away from its primary purpose will tend to be ineffective. Techniques to handle needs that aren’t core activities for delivering functionality but are still required will be addressed next.