Firing someone for not asking enough questions seems extreme.
The way I've seen this happen is that someone is assigned a task to render Bezier Curves in OpenGL, they work on it for a few days stumbling through, and 5 days later when they are done with the task that was assigned to them, they try to commit and find out that someone else had been given a task to remove all curves from the display and replace them with octogon segments or whatever.
With a daily scrum, they would say "I'm working on the Bezier Curves feature today" and someone else would be able to quickly tell them there's a problem with that.
In some teams, this kind of communication happens naturally all the time, but in others, people get focused on their own tasks and avoid it, either not paying attention to group chatter or simply not sending out wild questions. 15-30 minutes of lost focus for everyone everyday is really not that big a cost to pay to ensure this happens early. With any luck, a tight knit team would anyway spend that long on coffee together every day, so the daily just formalizes some informal process which already existed - no extra cost.
I didn't mean to suggest firing them if they don't ask questions per se. But lets imagine there is no daily scrum for whatever reason, people are working on their own things, if they don't ask for help and get stuck for 5 days in something without saying a word, I would have a chat with the person asap. If this continued, then yes, probably fire them as they aren't working.
And with the octagon example, there should be some kind of ticket for Bezier Curves and Octogons, if they cancel each other out, who in the hell created those tickets/decided on them? And again, you don't need a daily stand up to have an idea of who is working on what. The ticket board/tracker should give you a good idea if someone is doing Bezier Curves and you pick Octogons.
> 15-30 minutes of lost focus for everyone everyday is really not that big a cost to pay to ensure this happens early.
The problem it isn't 15-30 minutes. It is much more, because unless you are managing with strict work hours, and can make sure the stand up isn't delayed or interrupts someone's work, you are losing a lot more of the developers time. Context and focus is lost if you were in the middle of a task. Time is lost getting back to the place where you were, etc.
It may help with 'bad teams', but if the punishment for good teams is to do that because of the others, then I am sorry, I'm out. Makes no sense.
If it works for you and your team, more power to you. But not for me. (And I would really advise folks to try and understand if the team actually feels stand ups (or any other thing really) are a positive for the people involved, or they are just to 'scared' to raise concerns to not be that guy, as I have seen this happen a lot, going with the flow, but the moment they can speak freely, raise all concerns)
The way I've seen this happen is that someone is assigned a task to render Bezier Curves in OpenGL, they work on it for a few days stumbling through, and 5 days later when they are done with the task that was assigned to them, they try to commit and find out that someone else had been given a task to remove all curves from the display and replace them with octogon segments or whatever.
With a daily scrum, they would say "I'm working on the Bezier Curves feature today" and someone else would be able to quickly tell them there's a problem with that.
In some teams, this kind of communication happens naturally all the time, but in others, people get focused on their own tasks and avoid it, either not paying attention to group chatter or simply not sending out wild questions. 15-30 minutes of lost focus for everyone everyday is really not that big a cost to pay to ensure this happens early. With any luck, a tight knit team would anyway spend that long on coffee together every day, so the daily just formalizes some informal process which already existed - no extra cost.