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?
21How do you know they only have minor issues without having the scrum?– TimDec 7, 2020 at 0:24
What is the purpose of your daily scrum? What problems do these meetings solve? It looks, based on your question, your meetings have no purpose and do not solve any problems. I would not have any meetings without a purpose. If you track issues (you better be) and you are happy with tracking then why to have meetings?– OSGI JavaJan 3, 2021 at 22:32
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.
11what happened to 'people over process'?– lalalaDec 7, 2020 at 7:07
1Isn't this meaning that the idea of scrum is old fashioned in the post-corona era where working together simply means only meeting up at max once a week? Since we are not allowed to physically meet each day, and internet isn't good enough to actually meet with 4+ people.– paul23Dec 7, 2020 at 8:05
2@paul23 I think this just means if you really want to efficiently collaborate in a team you will need the technical basis so that all of them can talk to each other. If you are remote and your connection cannot support a meeting with everyone, I think you will need to split into smaller teams, until everyone in a team can in fact collaborate. - I think this could be a good question for this site you could ask!– FalcoDec 7, 2020 at 12:44
5@paul23 there are a whole slew of tools that allow 4+ people to hold a meeting over the internet and they work just fine even on a bad connection. The requirement is to hold it at the same time and place every day, holding a digital meeting every day at the same time fulfils this requirement. Having said that, if adding the small extra complexity of meeting in person rather than digitally when all team members are physically present in the same location and have an appropriate room available doesn't sound like it will break anything...– CronaxDec 7, 2020 at 13:14
4When confronted with questions about cancelling ceremonies (and certainly the daily stand-up) , I always turn the reasoning around : "Why do you want to cancel it? Because it would be useless. OK, then instead of cancelling it, what can we do to make it useful?" Dec 8, 2020 at 7:36
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.
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.
"mention anything" - my god the meeting will never end. My experience is that engineers have a great deal of trouble distinguishing between "I need help with this issue" and "This is a problem that fascinates me and I'd like to discuss in depth. At the beginning of time...." Dec 7, 2020 at 14:09
2@MarkC.Wallace Yes, that phrase probably needs a bit more qualification... the point still stands (IMHO) that one benefit of daily stand-ups is to encourage early mention of (real, not "interesting") problems rather than have (some) developers sit on them for days. Dec 7, 2020 at 15:16
1Interesting take indeed (+1) Dec 7, 2020 at 15:18
1Concern notwithstanding, I should note that I heartily approve of considering the personalities involved and designing activities to be inclusive. Dec 7, 2020 at 15:20
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.
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.
7We can also flip this around and say, the decision to cancel the scrum is a team decision, so the whole team should meet for a short team meeting at the beginning of the day to decide whether or not to hold the scrum. Now, what does this meeting sound like?!? Dec 6, 2020 at 9:14
Well, they could make that decision in team chat, or however they're communicating outside standups. Dec 7, 2020 at 19:41
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.).
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:
- One day, you come in and say what you are going to do for the customer and team over the next business day.
- The next day, you have to tell your team whether you did that or not.
- 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.
+1 for " It is not a status meeting; it is a commitment meeting" - elegant, concise, informative. Well done. Dec 17, 2020 at 11:57
Very kind of you, Mark! Dec 18, 2020 at 13:45
It's worth noting that the 2020 Scrum Guide did away with the "three questions," presumably for straitjacketing what should be (as you point out) a collaborative, short-term planning process.– Todd A. Jacobs ♦Dec 21, 2020 at 21:48
Thanks, Todd, I'm heads-down on a project and haven't had time to review the new guide. I'm not sure how I feel about that. If people would do those three questions--and only those three questions--it seems like that would solve a lot the other complaints in this thread. When I've freed teams to make changes (after hitting certain performance standards), all of them retained those questions even if they reduced meeting frequency! Dec 22, 2020 at 22:40
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.
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.
1Even though your example is purely anecdotal, your general point about flow-recovery time is valid and backed by research. However, unless you are solely an individual contributor who operates independently, the cost of collaboration in personal flow is generally made up in overall process efficiency for the whole Scrum Team. To quote Bob Lewis, "One of the basic, unexpected principles of design is that in order to optimize the whole you have to sub-optimize the parts."– Todd A. Jacobs ♦Dec 21, 2020 at 22:02
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.