Should I cancel the daily scrum if the team has only minor issues to discuss?

Question

If there are only minor issues to discuss in the next Daily Scrum, should I hold that Daily Scrum as usual or just tell the Scrum Master to cancel that Daily Scrum and deal with the issues by email or by some similar method or roll those minor issues over into the next Daily Scrum?

Answer 1

If You Aren't Planning Together, You Aren't Working Together

The Daily Scrum is not for addressing "issues," minor or not. It's a just-in-time planning meeting for the Developers to collaborate on the current day's work. If there are issues or blockers identified that won't easily fit within the time box of the Daily Scrum, then this is the time to coordinate who will meet to discuss it, and when that discussion will happen—in other words, coordinating and planning around the issue!

The Daily Scrum is a mandatory framework event. In fact, the 2020 Scrum Guide says (emphasis mine):

To reduce complexity...[the Daily Scrum] is held at the same time and place every working day of the Sprint.

If the team routinely has nothing to discuss during the Daily Scrum, then that's a whiffy project smell indicating that the team is not actively collaborating around a central coherence for the Increment, or that the team may not actually be doing Scrum.

The Daily Scrum Can Be Shortened, When Appropriate

You can certainly trim the length of the Daily Scrum on days when the just-in-time planning and coordination takes less than the maximum of 15 minutes. If you meet for five minutes and none of the Developers have anything else to talk about, everyone gets ten minutes back in their day. If the purpose of the meeting has been fulfilled, you don't have to keep going until you exhaust the time box. However, to implement Scrum properly, you need to provide the framework events like the Daily Scrum at predictable intervals on a reliable cadence. This ensures the entire Scrum Team can rely on the event cadence to coordinate things you may not have thought about ahead of time, and that last-minute planning concerns have a clear place to be addressed each day.

Doing anything else actively works against the empirical control process and the underlying framework. Don't do that.

Answer 2

If there are even minor issues - from my experience, it's better to keep it. Issues can be incorrectly investigated, hence, fixplan may be incorrect, hence estimations of the time to fix can be wrong. If the issues truly minor, it's easier to explain them to the team (people like to tell good news) and more joyfully to save the time remained from the scheduled meeting (those who already responded, may leave the meeting).

Once you skip a meeting, people relax and stop considering the ceremony important. When some time from the meeting is saved, they just saved more time for themselves or for remained tasks.

Check out more information about the importance of the ceremonies for the team spirit - skipping the meeting it disorganizes the team, totally not an option to skip it.

Answer 3

I can offer another reason for not cancelling the daily scrum, even if you don't think there is anything important to discuss.

Developers' personalities vary enormously. Some will gladly announce every obstacle they're currently facing, or highlight every potential issue they can see coming. Others are more reticent, and – if not prompted or given the right opportunity to air their problems – will happily "chip away" at a problem in silence.

One of the benefits of a regular, daily scrum meeting – with an atmosphere of "mention any (real, relevant) problem" – is that it can encourage "quieter" developers to say "Oh, by the way, I'm a bit stuck with...". Without a daily scrum, it might be several days before they think their problem is "important enough" to send an email asking for help.

Of course, as others have said, if – having presented the opportunity for everyone to raise any issues they are facing – there are none forthcoming, then the meeting can end early.

Answer 4

When you ask should I, that makes me wonder whether the developers are being allowed to operate as a truly self-organising team. The daily scrum is owned by the team and is for the team's benefit, so only the team should decide to cancel it. If you are not part of the team then your intervention would be outside interference and the SM should feel justified in resisting it as such. If you are one person in a self-organising team then it isn't your decision and you should instead ask the others for their opinions.

Answer 5

I can't think of a good reason to cancel the Daily Scrum.

First, there's the reason why the Daily Scrum is held every working day of the Sprint, and ideally at the same time and in the same place - it reduces complexity. By removing the decision on if the team should meet (not to mention when and where), it takes away one decision. Removing as many decisions as possible reduces decision fatigue and lets the team focus on making decisions about things that matter.

Second, it's not a long meeting. The Daily Scrum should take no more than 15 minutes. Getting the team together, making sure that everyone is aware of the issues (even if they are minor), and either determining how those issues will be resolved or setting aside additional time with the right subset of the team to resolve the issues seems well worth no more than 15 minutes out of the working day.

Given these two factors, I'm not sure why anyone would want to cancel the Daily Scrum. The cost is relatively low, and the value in planning the next immediate steps or raising a flag if the team's goals are in jeopardy seems well worth the cost.

Answer 6

The idea of a daily stand up isn't just to discuss issues, but for the team to which includes the scrum master, the product owner and the rest of the team (developers, BAs, etc.) to confirm what they've worked on, are going to focus on during the day and any issues. Sometimes the feeling between the team is 'well, we already know the answers', but the practice and routine of doing this calls out the unknowns and also opens opportunities to say something typically individuals don’t always do (and on time) until they are face to face or being asked about it.

There isn't any textbook way of running them, and should be run in a way that drives the best output from the team and the project being worked on. Sometimes the team wont always agree with the scrum master approach and that is OK, but the scrum master should always ensure everyone is clear on what the lay of the land is for the day.

Some times there is a case where you can't or don't need one for whatever reason. Still you could invite the team together and focus on anything urgent and then cut short.

I would always encourage email communication, but only after the physical (or virtual) get together. After the team can ping out anything they feel the other team members should know if the need is there (or through any other collaboration method e.g. instant messaging through Microsoft Teams, Skype, etc.).

Answer 7

The idea of daily standups long pre-dates Scrum, and the textbook format--yes, there is one--makes clear the function is not primarily to discuss issues. It is not a status meeting; it is a commitment meeting. If we take the standard three questions and reorder them with the psychology of motivation in mind, here is what is happening:

1. One day, you come in and say what you are going to do for the customer and team over the next business day.
2. The next day, you have to tell your team whether you did that or not.
3. If not, you share whether any obstacles (technical, organizational, personal, etc.) blocked you, and can ask for help with those blockers.

So for reasons of motivation, transparency, collaboration, and communication, teams that choose to use Scrum meet every day whether the Scrum Master is available or not. If there are no issues, I've seen meetings of 12 people last as few as five minutes, so there is no downside. Unless there is a crisis the whole team has to be involved in right away, let everyone go at that point.

Answer 8

The items on the agenda may seem trivial, however, let the discussion take place as sometimes what seems trivial initially may turn out to be rather challenging. Better to catch the minor ones as they can sometimes develop into major challenges.

Answer 9

Yes you should cancel the scrum. The ideas of scrums are overblown to start with. Most of the answers sound like they come from people who are not developers. From a developer perspective scrums are mostly an interruption to the day. Any useful collaboration happens during smaller ad hoc sessions with developers who are closely aligned on daily/weekly tasks.

Answer 10

Here's a response from an in-the-trenches developer for decades - a daily meeting of any length is an interruption in my thought process. If in the middle of trying to figure out some intricate logic, I always figure that any meeting imposes an unseen penalty of 15 minutes before the meeting while trying to adjust what you are doing to be ready for the meeting, and another 15 minutes afterwards to work back into the mental framework from before the meeting. So your 15 minute scrum amounts to a 45 minute chunk out of the day (sometimes worse if in the middle of a really tough problem).

Have also experienced spending a full day debugging a problem only to find a switch statement with no logic - had already entered the logic for case A and case B, was just getting to case C when had to go to the scrum - while there the system re-booted, so had to restart everything, forgetting what was in process before the scrum so case C went on with no logic.

Ask yourself, if you were a patient having open heart surgery would you want your surgeon to run off for a quick meeting in the middle? Sorry, not a meeting, a ceremony. And just the fact that you have to rename it should be a hint.