Daily standup vs. Micro-management
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?)
scrum daily-scrum micro-management
add a comment |
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?)
scrum daily-scrum micro-management
15
The daily standup is a intra-team coordination meeting, not a status pull. pm.stackexchange.com/a/6657/4271
– Todd A. Jacobs♦
Jan 2 at 16:57
The Dev Team maintains the burn-down chart, which can be used as a status update. In every case the (PO) has a lot of contact with the Dev Team during the Sprint and s/he is always updated by the Dev Team in the case of a problem. Thus, the Big Boss has to either check the burn-down chart or to ask the PO directly.
– Stefano Pedone
Jan 3 at 22:16
add a comment |
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?)
scrum daily-scrum micro-management
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?)
scrum daily-scrum micro-management
scrum daily-scrum micro-management
edited Jan 2 at 14:24
tiagoperes
468218
468218
asked Jan 2 at 14:15
Danny SchoemannDanny Schoemann
1,56911535
1,56911535
15
The daily standup is a intra-team coordination meeting, not a status pull. pm.stackexchange.com/a/6657/4271
– Todd A. Jacobs♦
Jan 2 at 16:57
The Dev Team maintains the burn-down chart, which can be used as a status update. In every case the (PO) has a lot of contact with the Dev Team during the Sprint and s/he is always updated by the Dev Team in the case of a problem. Thus, the Big Boss has to either check the burn-down chart or to ask the PO directly.
– Stefano Pedone
Jan 3 at 22:16
add a comment |
15
The daily standup is a intra-team coordination meeting, not a status pull. pm.stackexchange.com/a/6657/4271
– Todd A. Jacobs♦
Jan 2 at 16:57
The Dev Team maintains the burn-down chart, which can be used as a status update. In every case the (PO) has a lot of contact with the Dev Team during the Sprint and s/he is always updated by the Dev Team in the case of a problem. Thus, the Big Boss has to either check the burn-down chart or to ask the PO directly.
– Stefano Pedone
Jan 3 at 22:16
15
15
The daily standup is a intra-team coordination meeting, not a status pull. pm.stackexchange.com/a/6657/4271
– Todd A. Jacobs♦
Jan 2 at 16:57
The daily standup is a intra-team coordination meeting, not a status pull. pm.stackexchange.com/a/6657/4271
– Todd A. Jacobs♦
Jan 2 at 16:57
The Dev Team maintains the burn-down chart, which can be used as a status update. In every case the (PO) has a lot of contact with the Dev Team during the Sprint and s/he is always updated by the Dev Team in the case of a problem. Thus, the Big Boss has to either check the burn-down chart or to ask the PO directly.
– Stefano Pedone
Jan 3 at 22:16
The Dev Team maintains the burn-down chart, which can be used as a status update. In every case the (PO) has a lot of contact with the Dev Team during the Sprint and s/he is always updated by the Dev Team in the case of a problem. Thus, the Big Boss has to either check the burn-down chart or to ask the PO directly.
– Stefano Pedone
Jan 3 at 22:16
add a comment |
6 Answers
6
active
oldest
votes
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).
8
Sadly, in my experience this is very unusual. The Project Manager or their manager is almost always serving as Scrum Master on projects I've been involved with.
– catfood
Jan 2 at 19:19
6
Or sometimes the Scrum Master is in practice "standing in" for the management.
– davidbak
Jan 2 at 21:54
@davidbak A fair point. I added a paragraph.
– Sarov
Jan 2 at 22:19
2
I’m now imagining a scrum master playing hide-and-seek during stand-ups. Thanks for that! :)
– Ian MacDonald
Jan 3 at 23:07
2
@catfood Yes, most companies seem to be very keen on being "Agile", without actually trying to follow the guidelines. Needless to say, even the original paper on SCRUM for software development is very clear that under no circumstances should the scrum master be part of the management (among other things). Ideally, it's a dedicated role that does nothing else (on multiple teams if need be). It definitely isn't the product owner, the team leader, the project manager... the scrum master is there to guide the meetings (keep them on track) and be a cheerleader, he doesn't lead anything.
– Luaan
Jan 4 at 14:48
|
show 2 more comments
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.
add a comment |
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.
Comments are not for extended discussion; this conversation has been moved to chat.
– Todd A. Jacobs♦
Jan 8 at 16:24
add a comment |
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.
add a comment |
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:
- meetings that are not useful in proportion to their lengths of time and frequency,
and
- people taking those meetings and calling them "standup".
As Volaire allegedly said once : "If you wish to converse with me, define your terms."
New contributor
add a comment |
The daily scrum is not to be considered micromanagement because it does not target any individual.
Nobody feels threatened when everybody has to do it.
Furthermore it is more about getting more tasks to do then about reporting about yesterdays progressing - so no feel of microm.
6
Not sure I agree with your first two sentences. If the Big Boss(TM) is requesting status updates from the Team every day... that's still micro-management; s/he's just micro-managing the Team, rather than individuals.
– Sarov
Jan 2 at 15:08
5
If you don't do anything with information, then what's the point of having that information in the first place...?
– Sarov
Jan 2 at 20:45
1
"[I]t is more about getting more tasks to do then about reporting about yesterdays progressing[.]" What is your source for this? It does not seem to align with anything in the Scrum Guide.
– Todd A. Jacobs♦
Jan 3 at 19:29
1
"Nobody feels threatened when everybody has to do it." Even if the whole class is playing dodgeball, the small nerdy kid that's getting picked on feels more threatened than the class bully. It's still management even if you do it in a group setting.
– Zach Lipton
Jan 3 at 22:45
1
@Sarov It's about sharing information with other members of the team, not the management. Sadly, plenty of managers are way too scared to let go of the wheel, and end up messing everything up constantly, and then you have 30-minute long stand ups every day that are utter waste of time and just make everyone hostile to each other.
– Luaan
Jan 4 at 14:57
|
show 2 more comments
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "208"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
noCode: true, onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fpm.stackexchange.com%2fquestions%2f25518%2fdaily-standup-vs-micro-management%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
6 Answers
6
active
oldest
votes
6 Answers
6
active
oldest
votes
active
oldest
votes
active
oldest
votes
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).
8
Sadly, in my experience this is very unusual. The Project Manager or their manager is almost always serving as Scrum Master on projects I've been involved with.
– catfood
Jan 2 at 19:19
6
Or sometimes the Scrum Master is in practice "standing in" for the management.
– davidbak
Jan 2 at 21:54
@davidbak A fair point. I added a paragraph.
– Sarov
Jan 2 at 22:19
2
I’m now imagining a scrum master playing hide-and-seek during stand-ups. Thanks for that! :)
– Ian MacDonald
Jan 3 at 23:07
2
@catfood Yes, most companies seem to be very keen on being "Agile", without actually trying to follow the guidelines. Needless to say, even the original paper on SCRUM for software development is very clear that under no circumstances should the scrum master be part of the management (among other things). Ideally, it's a dedicated role that does nothing else (on multiple teams if need be). It definitely isn't the product owner, the team leader, the project manager... the scrum master is there to guide the meetings (keep them on track) and be a cheerleader, he doesn't lead anything.
– Luaan
Jan 4 at 14:48
|
show 2 more comments
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).
8
Sadly, in my experience this is very unusual. The Project Manager or their manager is almost always serving as Scrum Master on projects I've been involved with.
– catfood
Jan 2 at 19:19
6
Or sometimes the Scrum Master is in practice "standing in" for the management.
– davidbak
Jan 2 at 21:54
@davidbak A fair point. I added a paragraph.
– Sarov
Jan 2 at 22:19
2
I’m now imagining a scrum master playing hide-and-seek during stand-ups. Thanks for that! :)
– Ian MacDonald
Jan 3 at 23:07
2
@catfood Yes, most companies seem to be very keen on being "Agile", without actually trying to follow the guidelines. Needless to say, even the original paper on SCRUM for software development is very clear that under no circumstances should the scrum master be part of the management (among other things). Ideally, it's a dedicated role that does nothing else (on multiple teams if need be). It definitely isn't the product owner, the team leader, the project manager... the scrum master is there to guide the meetings (keep them on track) and be a cheerleader, he doesn't lead anything.
– Luaan
Jan 4 at 14:48
|
show 2 more comments
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).
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).
edited Jan 2 at 22:19
answered Jan 2 at 15:05
SarovSarov
8,89421841
8,89421841
8
Sadly, in my experience this is very unusual. The Project Manager or their manager is almost always serving as Scrum Master on projects I've been involved with.
– catfood
Jan 2 at 19:19
6
Or sometimes the Scrum Master is in practice "standing in" for the management.
– davidbak
Jan 2 at 21:54
@davidbak A fair point. I added a paragraph.
– Sarov
Jan 2 at 22:19
2
I’m now imagining a scrum master playing hide-and-seek during stand-ups. Thanks for that! :)
– Ian MacDonald
Jan 3 at 23:07
2
@catfood Yes, most companies seem to be very keen on being "Agile", without actually trying to follow the guidelines. Needless to say, even the original paper on SCRUM for software development is very clear that under no circumstances should the scrum master be part of the management (among other things). Ideally, it's a dedicated role that does nothing else (on multiple teams if need be). It definitely isn't the product owner, the team leader, the project manager... the scrum master is there to guide the meetings (keep them on track) and be a cheerleader, he doesn't lead anything.
– Luaan
Jan 4 at 14:48
|
show 2 more comments
8
Sadly, in my experience this is very unusual. The Project Manager or their manager is almost always serving as Scrum Master on projects I've been involved with.
– catfood
Jan 2 at 19:19
6
Or sometimes the Scrum Master is in practice "standing in" for the management.
– davidbak
Jan 2 at 21:54
@davidbak A fair point. I added a paragraph.
– Sarov
Jan 2 at 22:19
2
I’m now imagining a scrum master playing hide-and-seek during stand-ups. Thanks for that! :)
– Ian MacDonald
Jan 3 at 23:07
2
@catfood Yes, most companies seem to be very keen on being "Agile", without actually trying to follow the guidelines. Needless to say, even the original paper on SCRUM for software development is very clear that under no circumstances should the scrum master be part of the management (among other things). Ideally, it's a dedicated role that does nothing else (on multiple teams if need be). It definitely isn't the product owner, the team leader, the project manager... the scrum master is there to guide the meetings (keep them on track) and be a cheerleader, he doesn't lead anything.
– Luaan
Jan 4 at 14:48
8
8
Sadly, in my experience this is very unusual. The Project Manager or their manager is almost always serving as Scrum Master on projects I've been involved with.
– catfood
Jan 2 at 19:19
Sadly, in my experience this is very unusual. The Project Manager or their manager is almost always serving as Scrum Master on projects I've been involved with.
– catfood
Jan 2 at 19:19
6
6
Or sometimes the Scrum Master is in practice "standing in" for the management.
– davidbak
Jan 2 at 21:54
Or sometimes the Scrum Master is in practice "standing in" for the management.
– davidbak
Jan 2 at 21:54
@davidbak A fair point. I added a paragraph.
– Sarov
Jan 2 at 22:19
@davidbak A fair point. I added a paragraph.
– Sarov
Jan 2 at 22:19
2
2
I’m now imagining a scrum master playing hide-and-seek during stand-ups. Thanks for that! :)
– Ian MacDonald
Jan 3 at 23:07
I’m now imagining a scrum master playing hide-and-seek during stand-ups. Thanks for that! :)
– Ian MacDonald
Jan 3 at 23:07
2
2
@catfood Yes, most companies seem to be very keen on being "Agile", without actually trying to follow the guidelines. Needless to say, even the original paper on SCRUM for software development is very clear that under no circumstances should the scrum master be part of the management (among other things). Ideally, it's a dedicated role that does nothing else (on multiple teams if need be). It definitely isn't the product owner, the team leader, the project manager... the scrum master is there to guide the meetings (keep them on track) and be a cheerleader, he doesn't lead anything.
– Luaan
Jan 4 at 14:48
@catfood Yes, most companies seem to be very keen on being "Agile", without actually trying to follow the guidelines. Needless to say, even the original paper on SCRUM for software development is very clear that under no circumstances should the scrum master be part of the management (among other things). Ideally, it's a dedicated role that does nothing else (on multiple teams if need be). It definitely isn't the product owner, the team leader, the project manager... the scrum master is there to guide the meetings (keep them on track) and be a cheerleader, he doesn't lead anything.
– Luaan
Jan 4 at 14:48
|
show 2 more comments
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.
add a comment |
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.
add a comment |
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.
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.
answered Jan 3 at 9:19
TomTom
26113
26113
add a comment |
add a comment |
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.
Comments are not for extended discussion; this conversation has been moved to chat.
– Todd A. Jacobs♦
Jan 8 at 16:24
add a comment |
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.
Comments are not for extended discussion; this conversation has been moved to chat.
– Todd A. Jacobs♦
Jan 8 at 16:24
add a comment |
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.
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.
edited Jan 3 at 16:14
answered Jan 3 at 9:22
Stefan KarlssonStefan Karlsson
2213
2213
Comments are not for extended discussion; this conversation has been moved to chat.
– Todd A. Jacobs♦
Jan 8 at 16:24
add a comment |
Comments are not for extended discussion; this conversation has been moved to chat.
– Todd A. Jacobs♦
Jan 8 at 16:24
Comments are not for extended discussion; this conversation has been moved to chat.
– Todd A. Jacobs♦
Jan 8 at 16:24
Comments are not for extended discussion; this conversation has been moved to chat.
– Todd A. Jacobs♦
Jan 8 at 16:24
add a comment |
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.
add a comment |
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.
add a comment |
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.
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.
edited Jan 2 at 21:28
Sarov
8,89421841
8,89421841
answered Jan 2 at 21:19
Eric TexleyEric Texley
411
411
add a comment |
add a comment |
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:
- meetings that are not useful in proportion to their lengths of time and frequency,
and
- people taking those meetings and calling them "standup".
As Volaire allegedly said once : "If you wish to converse with me, define your terms."
New contributor
add a comment |
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:
- meetings that are not useful in proportion to their lengths of time and frequency,
and
- people taking those meetings and calling them "standup".
As Volaire allegedly said once : "If you wish to converse with me, define your terms."
New contributor
add a comment |
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:
- meetings that are not useful in proportion to their lengths of time and frequency,
and
- people taking those meetings and calling them "standup".
As Volaire allegedly said once : "If you wish to converse with me, define your terms."
New contributor
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:
- meetings that are not useful in proportion to their lengths of time and frequency,
and
- people taking those meetings and calling them "standup".
As Volaire allegedly said once : "If you wish to converse with me, define your terms."
New contributor
edited Jan 8 at 19:06
Sarov
8,89421841
8,89421841
New contributor
answered Jan 8 at 18:17
luis.espinalluis.espinal
1213
1213
New contributor
New contributor
add a comment |
add a comment |
The daily scrum is not to be considered micromanagement because it does not target any individual.
Nobody feels threatened when everybody has to do it.
Furthermore it is more about getting more tasks to do then about reporting about yesterdays progressing - so no feel of microm.
6
Not sure I agree with your first two sentences. If the Big Boss(TM) is requesting status updates from the Team every day... that's still micro-management; s/he's just micro-managing the Team, rather than individuals.
– Sarov
Jan 2 at 15:08
5
If you don't do anything with information, then what's the point of having that information in the first place...?
– Sarov
Jan 2 at 20:45
1
"[I]t is more about getting more tasks to do then about reporting about yesterdays progressing[.]" What is your source for this? It does not seem to align with anything in the Scrum Guide.
– Todd A. Jacobs♦
Jan 3 at 19:29
1
"Nobody feels threatened when everybody has to do it." Even if the whole class is playing dodgeball, the small nerdy kid that's getting picked on feels more threatened than the class bully. It's still management even if you do it in a group setting.
– Zach Lipton
Jan 3 at 22:45
1
@Sarov It's about sharing information with other members of the team, not the management. Sadly, plenty of managers are way too scared to let go of the wheel, and end up messing everything up constantly, and then you have 30-minute long stand ups every day that are utter waste of time and just make everyone hostile to each other.
– Luaan
Jan 4 at 14:57
|
show 2 more comments
The daily scrum is not to be considered micromanagement because it does not target any individual.
Nobody feels threatened when everybody has to do it.
Furthermore it is more about getting more tasks to do then about reporting about yesterdays progressing - so no feel of microm.
6
Not sure I agree with your first two sentences. If the Big Boss(TM) is requesting status updates from the Team every day... that's still micro-management; s/he's just micro-managing the Team, rather than individuals.
– Sarov
Jan 2 at 15:08
5
If you don't do anything with information, then what's the point of having that information in the first place...?
– Sarov
Jan 2 at 20:45
1
"[I]t is more about getting more tasks to do then about reporting about yesterdays progressing[.]" What is your source for this? It does not seem to align with anything in the Scrum Guide.
– Todd A. Jacobs♦
Jan 3 at 19:29
1
"Nobody feels threatened when everybody has to do it." Even if the whole class is playing dodgeball, the small nerdy kid that's getting picked on feels more threatened than the class bully. It's still management even if you do it in a group setting.
– Zach Lipton
Jan 3 at 22:45
1
@Sarov It's about sharing information with other members of the team, not the management. Sadly, plenty of managers are way too scared to let go of the wheel, and end up messing everything up constantly, and then you have 30-minute long stand ups every day that are utter waste of time and just make everyone hostile to each other.
– Luaan
Jan 4 at 14:57
|
show 2 more comments
The daily scrum is not to be considered micromanagement because it does not target any individual.
Nobody feels threatened when everybody has to do it.
Furthermore it is more about getting more tasks to do then about reporting about yesterdays progressing - so no feel of microm.
The daily scrum is not to be considered micromanagement because it does not target any individual.
Nobody feels threatened when everybody has to do it.
Furthermore it is more about getting more tasks to do then about reporting about yesterdays progressing - so no feel of microm.
answered Jan 2 at 14:46
Issy ForstIssy Forst
399
399
6
Not sure I agree with your first two sentences. If the Big Boss(TM) is requesting status updates from the Team every day... that's still micro-management; s/he's just micro-managing the Team, rather than individuals.
– Sarov
Jan 2 at 15:08
5
If you don't do anything with information, then what's the point of having that information in the first place...?
– Sarov
Jan 2 at 20:45
1
"[I]t is more about getting more tasks to do then about reporting about yesterdays progressing[.]" What is your source for this? It does not seem to align with anything in the Scrum Guide.
– Todd A. Jacobs♦
Jan 3 at 19:29
1
"Nobody feels threatened when everybody has to do it." Even if the whole class is playing dodgeball, the small nerdy kid that's getting picked on feels more threatened than the class bully. It's still management even if you do it in a group setting.
– Zach Lipton
Jan 3 at 22:45
1
@Sarov It's about sharing information with other members of the team, not the management. Sadly, plenty of managers are way too scared to let go of the wheel, and end up messing everything up constantly, and then you have 30-minute long stand ups every day that are utter waste of time and just make everyone hostile to each other.
– Luaan
Jan 4 at 14:57
|
show 2 more comments
6
Not sure I agree with your first two sentences. If the Big Boss(TM) is requesting status updates from the Team every day... that's still micro-management; s/he's just micro-managing the Team, rather than individuals.
– Sarov
Jan 2 at 15:08
5
If you don't do anything with information, then what's the point of having that information in the first place...?
– Sarov
Jan 2 at 20:45
1
"[I]t is more about getting more tasks to do then about reporting about yesterdays progressing[.]" What is your source for this? It does not seem to align with anything in the Scrum Guide.
– Todd A. Jacobs♦
Jan 3 at 19:29
1
"Nobody feels threatened when everybody has to do it." Even if the whole class is playing dodgeball, the small nerdy kid that's getting picked on feels more threatened than the class bully. It's still management even if you do it in a group setting.
– Zach Lipton
Jan 3 at 22:45
1
@Sarov It's about sharing information with other members of the team, not the management. Sadly, plenty of managers are way too scared to let go of the wheel, and end up messing everything up constantly, and then you have 30-minute long stand ups every day that are utter waste of time and just make everyone hostile to each other.
– Luaan
Jan 4 at 14:57
6
6
Not sure I agree with your first two sentences. If the Big Boss(TM) is requesting status updates from the Team every day... that's still micro-management; s/he's just micro-managing the Team, rather than individuals.
– Sarov
Jan 2 at 15:08
Not sure I agree with your first two sentences. If the Big Boss(TM) is requesting status updates from the Team every day... that's still micro-management; s/he's just micro-managing the Team, rather than individuals.
– Sarov
Jan 2 at 15:08
5
5
If you don't do anything with information, then what's the point of having that information in the first place...?
– Sarov
Jan 2 at 20:45
If you don't do anything with information, then what's the point of having that information in the first place...?
– Sarov
Jan 2 at 20:45
1
1
"[I]t is more about getting more tasks to do then about reporting about yesterdays progressing[.]" What is your source for this? It does not seem to align with anything in the Scrum Guide.
– Todd A. Jacobs♦
Jan 3 at 19:29
"[I]t is more about getting more tasks to do then about reporting about yesterdays progressing[.]" What is your source for this? It does not seem to align with anything in the Scrum Guide.
– Todd A. Jacobs♦
Jan 3 at 19:29
1
1
"Nobody feels threatened when everybody has to do it." Even if the whole class is playing dodgeball, the small nerdy kid that's getting picked on feels more threatened than the class bully. It's still management even if you do it in a group setting.
– Zach Lipton
Jan 3 at 22:45
"Nobody feels threatened when everybody has to do it." Even if the whole class is playing dodgeball, the small nerdy kid that's getting picked on feels more threatened than the class bully. It's still management even if you do it in a group setting.
– Zach Lipton
Jan 3 at 22:45
1
1
@Sarov It's about sharing information with other members of the team, not the management. Sadly, plenty of managers are way too scared to let go of the wheel, and end up messing everything up constantly, and then you have 30-minute long stand ups every day that are utter waste of time and just make everyone hostile to each other.
– Luaan
Jan 4 at 14:57
@Sarov It's about sharing information with other members of the team, not the management. Sadly, plenty of managers are way too scared to let go of the wheel, and end up messing everything up constantly, and then you have 30-minute long stand ups every day that are utter waste of time and just make everyone hostile to each other.
– Luaan
Jan 4 at 14:57
|
show 2 more comments
Thanks for contributing an answer to Project Management Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fpm.stackexchange.com%2fquestions%2f25518%2fdaily-standup-vs-micro-management%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
15
The daily standup is a intra-team coordination meeting, not a status pull. pm.stackexchange.com/a/6657/4271
– Todd A. Jacobs♦
Jan 2 at 16:57
The Dev Team maintains the burn-down chart, which can be used as a status update. In every case the (PO) has a lot of contact with the Dev Team during the Sprint and s/he is always updated by the Dev Team in the case of a problem. Thus, the Big Boss has to either check the burn-down chart or to ask the PO directly.
– Stefano Pedone
Jan 3 at 22:16