Discover two reasons teams balk at attending Scrum events, and how to ensure they are an investment in sprint success rather than a burden.

Mountain Goat Software's resource offers insights, tutorials, and resources for agile software development practitioners and teams. Readers can learn about agile methodologies, Scrum practices, and project management techniques. With articles, guides, and training materials, Mountain Goat Software provides  guidance and expertise for implementing agile practices and delivering successful software projects.

The Mountain Goat Software

Scrum meetings are often criticized for being time-consuming, but these complaints usually stem from misunderstandings or reluctance to adopt agile practices. Scrum requires minimal meetings, with only a daily fifteen-minute meeting plus a few longer sessions at the start and end of each sprint. Effective Scrum meetings occur at the right time, for the right length, and with appropriate focus. Scrum Masters should ensure meetings fulfill their purpose and manage time well. Resistance to meetings may indicate broader discomfort with agile principles. Emphasizing Scrum's benefits like visibility, customer feedback, and team coordination can help gain team buy-in.

What to Do When Teams Complain about Too Many Scrum Meetings

<p>OK, I started to work before Scrum. My first company didn’t have any process, first time I met process In Motorola in 2004, so long time ago when Agile was sexy new thing and we knew about one team doing it…  we had 1 weekly meeting, which took 1 hour. We didn’t have daily, we had designs before coding, we had formal code reviews (with paper!) and we still spend less time on meetings that in some of “scrum teams” I worked later ;-)
Later I remember having 2-3 hours planning each two weeks, each week 1-1.5 hour grooming (now backlog refinement) and 1.5 hour demo + daily each day taking around 15 minutes. And 1 hour meeting each week with PO. So in total on average 5+ hours, 5 times more. For smaller team, with less productivity.
Engineers don’t have attitude “meetings suck”, they have attitude “bad, non productive meetings suck”. Planning session? Nice idea, but lets be honest a lot of “scrum teams” is doing kanban, pretending to use scrum. I remember teams where normal thing was burndown chart where number of points WAS growing.
Demo? Nice idea, but main reason to have demos was to build working software which was demoed to customer/someone who pretended to be customer, and was able to say “good direction” or “bad direction”. Scrum now is in most cases exectly the same ad hoc approach which was used 20-30 years ago, but pretending to be methodology. Funniest part is when people doing scrum the same way last 20 years try to explain how before scrum it was waterfall… which was never used by anyone (iterations, and small iterations were used already in 70’s)</p>
