Death by Scrum Meeting

I recently received an email from a senior-level manager, who raises a valid question about all the meetings associated with Scrum. This particular instance of Scrum has over 50 people working in more than one locale. When yet another meeting was created, he raised a valid question:

90 minutes every week for backlog hygiene? And that is on top of all other scrums, scrum of scrums, business reviews, can we ship, planning etc. meetings and scrums? I am getting seriously concerned about our state and efficiency. If we need to spend 90 minutes on this weekly, than, IMHO, someone is not doing their job. Looking forward to find out more.

My answer:

It’s true, this is a lot of time to spend together planning what we are building for this product. Are you familiar with the book, “Death by Meeting“? Essentially, a short daily meeting (15 minute standup) should focus on the daily plan (3 questions). The longer the meeting, the further out we’re looking. Meetings should have a very specific purpose, stick to it, start on time and finish when the purpose is reached. In Scrum, all meetings are finished when they hit the time-boundary (aka time box) as well. We endeavor to reach the objective before hitting the time boundary. Scrum-of-Scrums (SoS) is a little exceptional as you’ll see.

Let’s look at all the meetings in our Scrum.

-Daily stand-up. 15 minutes max. Only pigs are allowed to speak.
Single team daily coordination. Answer 3 questions.
1. What did I complete yesterday?
2. What am I planning on completing today?
3. What’s in my way of completing work?
We stand up to keep it short.

-Daily SoS. Meta-stand-up. Inter-team coordination.
First, answer 4 questions. 15 minutes max and again, only pigs are allowed to speak for this part.
Scrum Master and Product Owner for each team required, other team members are optional as needed and/or interested.
1. What did our team accomplish yesterday?
2. What is our team going to accomplish today?
3. What is in our team’s way?
4. What are we about to put in another team’s way?
Then, we review all the obstacles on the board. Reporter confirms removal of existing ones. Decide how to remove the ones added today. Old obstacles are scrutinized.
Last, we walk through the Air Traffic Control (ATC) board and ensure it reflects reality. If a problem is detected, a plan is set to address it.
This meeting is the only one without a time boundary. We stay in the room until all goals of the meeting have been addressed.

-Weekly backlog hygiene
Keep the backlog in front of the Scrum teams by 4-6 weeks (2-3 Sprints).
+ Review meeting agenda and ask if any item for end
+ Review customer and user input about the Product
+ Review arrangement of the stories in themes and goals.
+ Write new stories, themes and goals. Remove old and wrong ones.
+ Review and update acceptance criteria currently known.
+ Prioritization
+ Team added agenda item, wrap-up.
Add new stories, keep the top prioritized. Look at the bigger backlog map. This will become the release planning mechanism. 90 minutes does seem long right now. Prioritization is not an easy endeavor. I would also like to enhance understanding of the User Story and examine the ones being added together. Some are coming in from user interviews. More are likely with Customer Support involvement. There are some interviewing-like ways to create them, so that eventually the customer/user can write them for us themselves. The time will also be needed later, once the teams pick up value delivery. All of this will intensify to stay in front of the progress we make.

-Review and Retrospective (aka Reflection)
Every 2 weeks we review the current working software with the customer, showing User Stories the Product Owners have accepted on their behalf. We then ask *them*, can we ship this to you? The answer will influence the backlog, too. The teams then gather and go through a retrospective to ask themselves, how did those last 2 weeks go and what would we like to change and experiment with to find improvements and innovation?

We are now planning as we go at many different levels, so that is much less disruptive to the teams. For the pigs involved who are busy creating value, it is an impact of 15 minutes daily, and 2-4 hours for one day every couple of weeks. We are meeting so that they can continue to do their job of creating the actual Product.

-and more!
There should also be monthly meetings to look at the next 3 months, and quarterly meetings to look at the next 4 quarters, and yearly meetings to look at the next 3 years. That last one may be a 2-3 day off site.

This is a complex, adaptive system with emergent properties. The system is continuously running at a sustainable pace, with value flowing through it from concept to cash. We need constant feedback so that we may inspect this system and ensure we are adapting to the best of the emergent capabilities. The concepts are captured as User Stories, and when we release it we determine the market value, when we start getting revenue from the Product. Along the way we keep our customer/user involved at every step and invite them to attend any meeting. Except the Retrospective, which is for the pigs.

The ATC board shows all stories in progress for all teams. It includes the top of the backlog in a stack-rank buffer for teams to accept work from when they have delivered something and have capacity (below the story point WIP limit).

There are more than the 4 meetings mentioned in the book: stand up, SoS, review, retrospective, can we ship?, planning, backlog hygiene. The longer-term Agile strategic meeting is not yet in place. How else should I address the concern? Is there too much mixing up of strategic goals in the weekly tactical backlog hygiene meeting? Should that be pulled out to the monthly strategic meeting? What should be in the tactical one, then? What could be removed from a meeting, or a meeting itself? How would you redo these to be more effective?

This entry was posted in #agile explained and tagged , , , , , , , . Bookmark the permalink.

2 Responses to Death by Scrum Meeting