mjhjmtu

Why isn't the daily scrum considered to be micromanagement?

Under any other circumstances expecting to get a daily update from developers would be considered micromanagement. Maybe even pico-management. (did I just invent a term?)

Even a weekly update was considered borderline micromanagement by many.

What changed that the daily scrum is acceptable, both to the engineers and the Project Managers?

^{(Future question: can this change (if it exists) be used for more frequent updates in a non-scrum setup?)}

The Daily Scrum is not an update-to-management meeting!

From the Scrum Guide (emphasis mine):

The Daily Scrum is a 15-minute time-boxed event for the Development Team [...] This optimizes team collaboration and performance [...] The Scrum Master ensures that the Development Team has the meeting, but the Development Team is responsible for conducting the Daily Scrum. [...] The Daily Scrum is an internal meeting for the Development Team. If others are present, the Scrum Master ensures that they do not disrupt the meeting.

If someone outside the Team is asking for progress reports or otherwise attempting to micromanage during the Daily Scrum, the Scrum Master should request for him/her to stop.

If the developers are automatically reporting to someone outside the Team during the meeting (you can tell this if they always face someone during the meeting) even without being asked, then that someone should be removed from the meeting to remove this temptation.

If the developers are automatically reporting to someone inside the Team during the meeting (such as the Scrum Master), then steps should be taken by the Scrum Master to discourage this. For example, the Scrum Master could make certain to move about the room during the meeting, to prevent the person speaking from being able to see him/her (and, thus, force the person speaking to shift his/her attention to the group at large).

In addition to Sarov's excellent answer, there is also the purpose of the meeting.

The daily standup is not a management engagement. Neither the Scrum Master nor any other project or senior manager is doing any managing during the daily standup. I see this even stronger than Sarov does - not only is management not being reported to, there is also no flow from management towards the team. Nobody tells the team what to do or how to do it during the daily standup. There is no management activity going on during the daily standup and that is why it isn't micro-management - because it isn't management at all.

That doesn't mean this culture as-written is strictly put into practice in your environment, so your confusion might very well result from the practice being different from the book. If management has taken over the daily standup and is using it to micro-manage the team, then indeed the daily standup has become micro-management. If you continue to run it in that way, then yes you are engaging in micro-management. But it shouldn't be called the daily standup anymore.

If you ask this question, or even if you have troubles answering it, you are likely a victim of dark scrum. A daily scrum meeting, done right, has no micro-management.

Terms have power, and dark scrum is one of these potentially important terms that I would like to see spread. Scrum was never made for this kind of micro-management, and its mis-use can have dire consequences for developers, projects and scrum itself (as a concept). If you can, consider using the term "dark scrum".

from the linked page(ronjeffries.com),

EDIT: I emphasize that below is a description of "dark scrum":

Every day, the team is supposed to get together and organize the day’s work. This practice, the “Daily Scrum”, is imposed on the typical team. There might be one person in the room, the ScrumMaster, who has been told how it should be done. The programmers haven’t been told. Quite often, even the Product Owner hasn’t been told. Almost certainly other power holders haven’t been told.

But the power holder already knows his job. His job is to stay on top of what everyone is doing, make sure they’re doing the right things, and redirect them if they’re not. How convenient that there’s a mandatory meeting where he can do that, every single day!

The result: instead of the team rallying around their joint mission and sorting out a good approach for the day, someone else drags information of of them, processes it in their head, and then tells everyone what to do. Since nothing ever goes quite as we expected yesterday morning, this improper activity often comes with a lot of blame-casting and tension.

Dark Scrum oppresses the team every day. Self-organization cannot emerge.

When the "stand-up" is properly orchestrated, it's a free exchange of ideas about each other's work. It's meant to enforce collaboration, not confrontation. Unless your manager is actively developing with you (they usually are) they should not be in the meeting.

Too many times have I worked on projects where people who worked across the isle from each other could have saved the other person 6 months' work.

Under any other circumstances expecting to get a daily update from
developers would be considered micromanagement.

That's not true. I'm not even sure if we are defining micromanaging properly here as there are ways to micromanage without requiring a daily update from developers.

A Scrum standup is not for management. It's for developers and by developers. It's where developers get in sync and plan what to do next, who needs help and who can provide help.

It is meant to go quickly, a few minutes per developer to sync with the other developers and then call it quits. I've work in actual Scrum and Kanban teams doing real standups, and those have been the most productive exercises in my 25 years in software.

Problem is, many people hijack the term 'standup' to conduct an actual 30-min or even hour-long meeting. Now, a 30-60 min daily meeting can be valid and useful in some organizations and contexts.

The problem here is two-fold:

1. meetings that are not useful in proportion to their lengths of time and frequency,

and

2. people taking those meetings and calling them "standup".

As Volaire allegedly said once : "If you wish to converse with me, define your terms."

I thought I will also add my 2 cents although Sarov gave an very good answer.

Under any other circumstances expecting to get a daily update from
developers would be considered micromanagement.

The developers should not give feedback in the stand up as and update to Managers but rather give the team an update using the three stand up questions

1. What tasks have you worked on since we last talked?




2. What tasks are you planning to work on next?




3. Is anything getting in the way of finishing the work as expected?

Scenario:

A NFL team mid game gets together to discuss plans for the next play. The players do not give plays individually but rather a player will say " What did he try the last play, What play he wants to try, and if there is any obstructions he ask if someone to help opening the field" - He did not give an micromanaged update but rather informed the team how he plans to reach the goal.

Rather giving "someone an update" look at the sprint board and inform the team what you are doing and keep within the timebox.