Overcoming Four Common Objections to the Daily Scrum

I totally understand some team members’ resistance to participating in daily scrum meetings. I don’t like meetings either. But, some meetings are helpful and worth the time investment. I put well-run daily scrum meetings in that category.

In this article, I’ll share how I handle four common objections to participating in daily scrums. I’ll then share some attributes of a well run daily scrum so that there will be no objections to participating.

We Talk A Lot Already

The first common objection to the daily scrum is for someone to insist that team members speak to one another frequently already and so the daily scrum is unnecessary overhead.

When I hear this objection, I counter it by agreeing that team members do, indeed, speak to one another frequently. But they rarely all speak together.

The daily scrum provides that opportunity. For many teams it is the one time each day when each team member is able to speak to all other team members.

Nothing Important Is Ever Discussed

A second common objection to daily scrums comes from team members who feel that daily scrums are unnecessary because nothing important is ever discussed during them.

Set Expectations

The first thing I do when faced with this objection, is to set the proper expectation for the meetings with the objector. I am very clear that I do not expect something important to come up every meeting. Some daily scrums do turn out to be fairly useless&emdash;the ones where everyone made decent but unremarkable progress yesterday and no one has any issues with today’s work.

But, most daily scrums do turn up something useful to the team.. And the idea is that the many daily scrums where important things are discussed make up for the more infrequent occasions where nothing important gets discussed.

Determine if the Objection Is Valid

The second, and more important, thing that I do when I hear this objection, is to consider whether it’s valid. It may be. If so, the Scrum Master needs should take that as an indicator that the daily scrums could be improved.

Common mistakes that make this a valid objection include participants being allowed to ramble off topic, letting the meeting go too long, or having a team of individuals who aren’t really a team. This last mistake occurs when a “team” is made up of individuals working on completely unrelated projects.

Can’t We Just Do This by Email?

Some team members don’t object to the concept of checking in with their teammates daily, but instead, object to doing it in a meeting. They’ll often request to abandon a daily scrum meeting in favor of each person sending a daily email addressing the usual questions of the in-person meeting.

I have rarely seen this work. The biggest problem is that most people don’t read the emails. Or, if they do, they read them a day or two later. This makes the team less responsive to issues.

Also, conducting a daily scrum by email loses all the benefits of in-the-moment discussion that should be part of the meetings.

What about Slack and similar tools? You’d think my answer would be the same as for email. However, I have seen teams successfully conduct the equivalent of daily scrum meetings using Slack.

I don’t know if this is the newness of such tools or something fundamentally different about messaging versus email. I still don’t favor replacing the live interaction of a daily scrum with a Slack-based equivalent for most teams. But for some teams, especially those that are highly distributed, it does seem to work adequately.

The Meetings Take Too Long

A fourth and final objection you’ll hear is that the meetings take too long. Naturally, you’ll want to take this complaint seriously if your meetings are taking longer than the standard fifteen minutes prescribed by nearly all Scrum proponents.

But if your meetings are finishing well within the fifteen-minute limit, I’ve found the best response to this complaint is to ask any objectors how much time they think would be appropriate.

You’ll get a useful answer especially if you include a few of the meeting’s benefits when asking the question. For example, you might ask, “How much time do you think would be appropriate each day to make keep us all synchronized, avoid communication problems, provide visibility into what each of us is working on, identify and correct mistakes, build trust, and provide a feeling of accomplishment?”

Seven Attributes of a Well-Run Daily Scrum

The advice above will help overcome the most common objections team members may have to participating in the daily scrum. Even better, would be to conduct the meetings so well that team members value them. Here are seven attributes of a well-run daily scrum.

Meetings Are at the Same Time and Place Each Day

You want to make these meetings as easy possible. For most teams, that means holding them at the same time and place every time.

Meetings Start on Time

I’m as on time as anyone you’ll ever meet. I once had to talk myself out of calling a doctor when I thought I’d be a minute late arriving at his office.

But even I’ll acknowledge that arriving a few minutes late for a full-day meeting isn’t a big deal. Being five minutes late to an eight-hour meeting is 1% of the meeting time.

But being late to a daily scrum is a much bigger deal. If meetings start five minutes late every day, team members who arrived on time will have spent over 20 hours in the year waiting for the meeting to start.

The Meetings Are Kept to No More than Fifteen Minutes

There’s a reason many teams conduct these as standup meetings: Standing helps us remain aware of the time and will keep the meetings short.

Problems Are Identified But Not Solved in the Meeting

A common, good practice is to discuss (and hopefully, resolve) issues immediately after the meeting. Ideally this can be done only by the subset of the team necessary to address the issues; the other team members are encouraged to return to their desks.

Participants Stay on Topic

Most teams follow an approach of having each person address what they accomplished since the last meeting, what they will do before the next meeting, and any problems slowing them down. Any discussion beyond those topics should be severely limited.

Rules Are Enforced by the Whole Team, Not Just the Scrum Master

When the Scrum Master is the only one enforcing the team’s rules for its meetings, the meeting takes on an air of being for the Scrum Master. This leads to it feeling like a status meeting with each participant providing status solely for the benefit of the Scrum Master.

The Whole Team and Only the Team Participates

Everyone on the team should participate in daily scrums. Those outside the team should be allowed to observe the meeting. They should be discouraged from contributing to the discussion during the meeting unless asked a short question by a team member.

Once a daily scrum is concluded but before participants dissipate, many teams will ask observers if they have any questions or comments. The Scrum Master or a subset of the team may stay and address those. The key is that observer comments are kept out of the actual daily scrum.

What’s Your Experience?

Team members may undoubtedly have objections other than the four most common I’ve addressed here. And there are certainly additional things important to having well-run daily scrums than the seven essential attributes I’ve listed.

What’s your experience? What objections have you heard and how have you overcome them? Please share your thoughts in the comments below.

Rescue Your Daily Scrum!

Rescue Your Daily Scrum!

Learn how killing your daily scrum might be the best way to save it. Free 30-minute video training from Brian Milner.



Mike Cohn

About the Author

Mike Cohn specializes in helping companies adopt and improve their use of agile processes and techniques to build extremely high-performance teams. He is the author of User Stories Applied for Agile Software Development, Agile Estimating and Planning, and Succeeding with Agile as well as the Better User Stories video course. Mike is a founding member of the Agile Alliance and Scrum Alliance and can be reached at hello@mountaingoatsoftware.com. If you want to succeed with agile, you can also have Mike email you a short tip each week.