Thank you! No matter how I explain this simple idea that standups are nothing but micromanagement, it never rings a bell. They might work in very limited situations and scopes, but they are never a generic framework to follow, and I blame Silicon Valley for normalizing it. What is worse is some companies try to force it in engineering work, and not just the software part of engineering, where you could spend a whole two weeks researching some topic. I remember in a previous job a novice manager (who only managed few coops before) tried to force it in a company that built robotics, and later I explained to him that they don't add any value let alone increase productivity. He took it personally and it was the crack that eventually was the reason why I left the company, despite me loving the technical work part.
"micro-management" is not a useful concept, it's just a though-terminating cliche - let's get specific.
The problem with bad stand-ups is usually that they're just "personal status updates" by another name. They're abused as a way for team lead/project manager to "get a feel" for what individuals on the team are doing. Bad managers do this, because they're bad at their jobs. It's literally their job to know what people are doing, where they're at in their various tasks, what's going on with the project. They should be doing that all day, every day - when they're not "managing up". Gathering info in a 15 minute standup is both too short a feedback cycle and too long and nowhere near high enough bandwidth. It's also one of the major reasons stand-ups frequently go off the rails and end up taking so long, in badly run projects. Stopping those derailments is actually supposed to be one of their jobs and should be one of their main priorities during the stand up.
If you're stand-up involves going around the team, one person at a time asking "what did you do yesterday, what are you doing today" - that's a bad stand-up.
Stand-ups should be run from the sprint board - you run through all open tickets for the sprint, asking whoever is assigned to that ticket "what's up with that?"
Once you've gong the through the tickets, you're done. No looking forward to next sprint - that's for backlog grooming and planning sessions. No looking backward, that's for retros.
Don't get to talk during the stand-up? Then WTF are you even working on, and why isn't a story in the sprint? That's a question the manager should be asking and resolving - privately, outside of the standup.
Stand-ups are for "visibility of the team, for the team". Not for managers or other wanna be management.
Stand-ups are for telling your teammates "i unstuck this ticket this way, if that's an issue or there's a better way, hit me up after the standup" or "I'm going to be working on X and I don't know anything about that; anyone who can help me, hit me up after the standup".
If your stand-ups aren't like that they're bad stand-ups. Because your manager sucks. Don't worry - most managers suck. Deal with it, get over it; and stop blaming your tools.
micromanage (verb): control every part, however small, of (an enterprise or activity).
Managers who insist on stand-ups, insist on being present in them, and insist on managing the the backlog of tasks, assigning tasks, and forcing developers to estimate each one... are micromanaging.
No amount of, "I'm the friendly manager you can trust!" is going to melt the ice that your presence, as a manager, brings into a standup. You control salaries, promotions, and the stress levels of everyone there. It's going to be a conflict every time some one pushes back on your demands. Everything devolves into a status update meant to save face rather than be honest. It's wholly a waste of time.
> Stand-ups are for "visibility of the team, for the team". Not for managers or other wanna be management.
I agree.
Standups are a whole different game when it's a group of developers with a goal who need each other to meet it.
A good manager trusts their team to do this work themselves. If that means standups, cool. If they only need to meetup once a week as a group and people meet impromptu based on what they're working on... fine. As long as the team is shipping and meeting it's goals and milestones, all gravy.
What I struggle with is that any blockers or delays that I may have, I’ve already signaled in our team chat.
And the social pressure against saying “I didn’t do much” is tremendous, and it’s hard for anyone who cannot completely abandon worrying about what others may think of them to admit that, even if they have a reason to do so.
An actual progress report meeting 1-2 times a week is so much better.
If I have stuff I didn't finish yesterday, I will usually just say "continuing work on foo" and if there was a blocker that delayed me I will mention that otherwise I don't get into reasons why, that's not really the point of a standup unless someone else can do something about it.
And that’s fine, just say so and who’s helping you unblock it and move on. The stand up is to make sure nothing gets missed because the conversation that needed to be had didn’t happen.
"Scrum" is one of those terms like "jam band" or "martini" or "DevOps" that people apply way too liberally to describe things that they think are similar but are actually completely different. If you try and get people to do real Scrum ceremonies and roles as written you'll run into a host of excuses as to why they can't (or, as is more often the case, just don't want to). This is how you end up with a "daily stand-up" that only happens when Jupiter isn't in declination, is attended by between 0 and n + 3 people where n is the actual team size, and lasts up to an hour and a half with a strong possibility of not everybody giving their required status. Oh, and everybody is sitting down. At a stand-up.
Scrum might not be perfect for every situation but it's a damn sight better than a swirling miasma of agenda-less quasi-recurring meeting invites buttressed by orphaned Google Docs and Slack threads. I've worked on exactly one team where we pretty much did Scrum to the letter and it was great. Meetings were short and sweet and we always knew what we had to build or fix. I was just a kid and we were using a super-janky tech stack but it was among the most productive, low-stress times in my career.
Yeah, we do this basically automatically right now, so it is fast. There are really rare cases when we would need more than 15 minutes. We do more serious stuff asynchronous over Slack or in a smaller round after daily with only affected people.
We were 5 people total - PO, Scrum Master, 3 devs. Been years since I was in that team but it was expected that everyone would give a lengthy update about the previous day
That's 12 minutes a person. How much time did it take 3 devs to say "I worked on 12343, I plan on working on 12354, no blockers"? I assume it was the PO/SM that drug it out?
That takes 2 seconds. But the PO usually expected a detailed breakdown of what went well or bad and what could be improved right then and there. Simply saying "Yeah, I'm doing X, still doing it, bye" would be bad, because you're also not inviting _collaboration_.
Product managers shouldn't be rebranded as "solution managers." The title suggests they can handle solutions, but most lack the chops to solve real problems effectively.
I used to run standups using a Slack plug-in, because my team was in several different time zones. It was really effective. We met once/week in a meeting....
My team does this, with the only downside that people are unlikely to pay attention. It at least satisfies mgmt without getting the team bogged down for an hour.
But if there's a problem I already bring it up via online chat, and will at least get private messages from the extremely shy people (which is most of them).
If stand up takes an hour, there’s some real issues there. I have the occasional one take longer but they generally last 5-10 minutes. Anything that needs discussion is taken to separate calls.
I like the suggestion to look at the system status.
One thing I’d suggest you try is to switch from people-centric to work-centric standup. Instead of going person by person, pick your rightmost “in progress” column and get an update on that issue. What’s needed? Who needs to help? That sort of stuff.
I find this moves through the standup fairly quickly and puts the focus on how to get things done. It also highlights when something isn’t clear for the team and you can follow up after.
I feel so strongly about this topic that I recorded a podcast episode on it with my at the time business partner[1]. I think that maybe the only relevant reason to have a synchronous standup is to align on the biggest problem to solve in the next workday.
A standup of this model goes something like this: what is the goal for the day? What support is needed to make it happen? etc.
You can report on that, yesterday log can give the team important signals. It’s mentioned there. I encourage to focus on planning and cooperation though. Mainly cooperation so even when reporting yesterdays work it’s worth to emphasise things that impact others.
After almost 3 decades in the industry I can definitively say that if someone paid me 9-figure salary which came with daily standups I would politely decline
My teams daily standups are focused around raising issues and blockers, not as an individual status update. Sometimes nobody raises their hand and after 2/3 mins we go our merry way. Sometimes someone raises something that ends up being a 15 min. discussion (if there were no other hands raised, raised hands have priority).
This is an example of when Daniel Kahneman said that people don’t believe in something because there are arguments but believe the arguments because they believe in something. Here’s why I think so:
> syncing plans and priorities for the current day
Most of the work developers do require syncing multiple times a day, either by slack messages, GitHub comments or pair programming, etc. Waiting for the daily to sync is not realistic and would waste tons of time.
> signaling blockers early so the team can help
If you have a blocker and you wait until the daily to mention it, you have a bigger problem. Blockers should be notified right away and most teams do this over slack or other messaging platforms they use.
> encouraging collaboration and knowledge sharing
Teams are usually small, and if you don’t already know what someone is doing, you wouldn’t care what they have to say during the daily, and if you care what they have to say, you already know what they are doing.
> building a sense of team ownership and support.
Just go for a coffee break.
If you believe daily standups are useful, chances are you’re actually part of the problem.
> If you have a blocker and you wait until the daily to say it, you have a bigger problem. Blockers should be notified right away and most team do this over slack or other messaging platforms they use.
They should but it doesn’t always happen. Having a stand up makes sure you can get that information into the open.
This holds for literally everything. You shouldn’t hold back conversations for your 1-on-1 but, if you don’t have them, you’ll find there’s a load of conversations you miss out on that you needed to have.
Having a daily standup might be encouraging people to wait until the daily to mention blockers, which could be harming your team all while you think it’s working
> Daily stand-ups are a cornerstone of agile software development
A cornerstone of micro-management, at best.
Daily stand-ups can work when there is no manager present and it's just the people working on what they need to get done.
Thank you! No matter how I explain this simple idea that standups are nothing but micromanagement, it never rings a bell. They might work in very limited situations and scopes, but they are never a generic framework to follow, and I blame Silicon Valley for normalizing it. What is worse is some companies try to force it in engineering work, and not just the software part of engineering, where you could spend a whole two weeks researching some topic. I remember in a previous job a novice manager (who only managed few coops before) tried to force it in a company that built robotics, and later I explained to him that they don't add any value let alone increase productivity. He took it personally and it was the crack that eventually was the reason why I left the company, despite me loving the technical work part.
In my setup there is no manager there, only me as a team leader but I'm also one of the developers at the same time.
I agree. The best experience i had was with a startup that had zero video calls and audio calls were rare.
"micro-management" is not a useful concept, it's just a though-terminating cliche - let's get specific.
The problem with bad stand-ups is usually that they're just "personal status updates" by another name. They're abused as a way for team lead/project manager to "get a feel" for what individuals on the team are doing. Bad managers do this, because they're bad at their jobs. It's literally their job to know what people are doing, where they're at in their various tasks, what's going on with the project. They should be doing that all day, every day - when they're not "managing up". Gathering info in a 15 minute standup is both too short a feedback cycle and too long and nowhere near high enough bandwidth. It's also one of the major reasons stand-ups frequently go off the rails and end up taking so long, in badly run projects. Stopping those derailments is actually supposed to be one of their jobs and should be one of their main priorities during the stand up.
If you're stand-up involves going around the team, one person at a time asking "what did you do yesterday, what are you doing today" - that's a bad stand-up.
Stand-ups should be run from the sprint board - you run through all open tickets for the sprint, asking whoever is assigned to that ticket "what's up with that?" Once you've gong the through the tickets, you're done. No looking forward to next sprint - that's for backlog grooming and planning sessions. No looking backward, that's for retros.
Don't get to talk during the stand-up? Then WTF are you even working on, and why isn't a story in the sprint? That's a question the manager should be asking and resolving - privately, outside of the standup.
Stand-ups are for "visibility of the team, for the team". Not for managers or other wanna be management.
Stand-ups are for telling your teammates "i unstuck this ticket this way, if that's an issue or there's a better way, hit me up after the standup" or "I'm going to be working on X and I don't know anything about that; anyone who can help me, hit me up after the standup".
If your stand-ups aren't like that they're bad stand-ups. Because your manager sucks. Don't worry - most managers suck. Deal with it, get over it; and stop blaming your tools.
micromanage (verb): control every part, however small, of (an enterprise or activity).
Managers who insist on stand-ups, insist on being present in them, and insist on managing the the backlog of tasks, assigning tasks, and forcing developers to estimate each one... are micromanaging.
No amount of, "I'm the friendly manager you can trust!" is going to melt the ice that your presence, as a manager, brings into a standup. You control salaries, promotions, and the stress levels of everyone there. It's going to be a conflict every time some one pushes back on your demands. Everything devolves into a status update meant to save face rather than be honest. It's wholly a waste of time.
> Stand-ups are for "visibility of the team, for the team". Not for managers or other wanna be management.
I agree.
Standups are a whole different game when it's a group of developers with a goal who need each other to meet it.
A good manager trusts their team to do this work themselves. If that means standups, cool. If they only need to meetup once a week as a group and people meet impromptu based on what they're working on... fine. As long as the team is shipping and meeting it's goals and milestones, all gravy.
It really depends on how you do it. A standup can just be a way to socialize with your team, and share ideas.
That's the opposite of what it's for. It's for communicating what's stopping progress. If everything is going fine, it's over.
It's for whatever you want it to be for.
What I struggle with is that any blockers or delays that I may have, I’ve already signaled in our team chat.
And the social pressure against saying “I didn’t do much” is tremendous, and it’s hard for anyone who cannot completely abandon worrying about what others may think of them to admit that, even if they have a reason to do so.
An actual progress report meeting 1-2 times a week is so much better.
If I have stuff I didn't finish yesterday, I will usually just say "continuing work on foo" and if there was a blocker that delayed me I will mention that otherwise I don't get into reasons why, that's not really the point of a standup unless someone else can do something about it.
And that’s fine, just say so and who’s helping you unblock it and move on. The stand up is to make sure nothing gets missed because the conversation that needed to be had didn’t happen.
Props to you if you manage to follow this and squeeze it into 15 minutes. I‘ve genuinely never had a daily last less than 60 mins.
Your team needs coaching, then. Unless you're getting status from 30 people....which would be a whole other conversation.
I‘m long gone from that team (thankfully). But hey, the Scrum Master was certified, I‘m sure it‘s all proper /s
"Scrum" is one of those terms like "jam band" or "martini" or "DevOps" that people apply way too liberally to describe things that they think are similar but are actually completely different. If you try and get people to do real Scrum ceremonies and roles as written you'll run into a host of excuses as to why they can't (or, as is more often the case, just don't want to). This is how you end up with a "daily stand-up" that only happens when Jupiter isn't in declination, is attended by between 0 and n + 3 people where n is the actual team size, and lasts up to an hour and a half with a strong possibility of not everybody giving their required status. Oh, and everybody is sitting down. At a stand-up.
Scrum might not be perfect for every situation but it's a damn sight better than a swirling miasma of agenda-less quasi-recurring meeting invites buttressed by orphaned Google Docs and Slack threads. I've worked on exactly one team where we pretty much did Scrum to the letter and it was great. Meetings were short and sweet and we always knew what we had to build or fix. I was just a kid and we were using a super-janky tech stack but it was among the most productive, low-stress times in my career.
We do something really similar to this and we're usually through 6 or 7 people in 15 minutes
Yeah, we do this basically automatically right now, so it is fast. There are really rare cases when we would need more than 15 minutes. We do more serious stuff asynchronous over Slack or in a smaller round after daily with only affected people.
that's insane. how many of you are there?
We were 5 people total - PO, Scrum Master, 3 devs. Been years since I was in that team but it was expected that everyone would give a lengthy update about the previous day
That's 12 minutes a person. How much time did it take 3 devs to say "I worked on 12343, I plan on working on 12354, no blockers"? I assume it was the PO/SM that drug it out?
That takes 2 seconds. But the PO usually expected a detailed breakdown of what went well or bad and what could be improved right then and there. Simply saying "Yeah, I'm doing X, still doing it, bye" would be bad, because you're also not inviting _collaboration_.
> _collaboration_
_micromanagement_
Product managers shouldn't be rebranded as "solution managers." The title suggests they can handle solutions, but most lack the chops to solve real problems effectively.
I meant "Scrum Master".
We don't report on yesterday in standup unless it's about a blocker that was hit yesterday.
Yesterday is history, can't change it, and it's documented in commit messages or bug tracker notes. No point in rehashing it for the group.
We report what I am planning for today and any blockers.
This improved update looks entirely like what could've instead been communicated asynchronously.
And some of it is not as timely as it could've been, because it was held back for the standup.
> Here is my attempt to improve such update:
> > Yesterday, I fixed a sidebar flickering bug.
> > Please review my PR soon as it is annoying for customers.
> > I started a video player story that we discussed at the last refinement.
> > Since it’s my first time working with the player module, I’d appreciate pairing up or any tips from someone familiar with it.
> > Today, my focus is on wiring up the play/pause functionality. Happy to sync after stand-up if anyone’s available.
I used to run standups using a Slack plug-in, because my team was in several different time zones. It was really effective. We met once/week in a meeting....
My team does this, with the only downside that people are unlikely to pay attention. It at least satisfies mgmt without getting the team bogged down for an hour.
But if there's a problem I already bring it up via online chat, and will at least get private messages from the extremely shy people (which is most of them).
If stand up takes an hour, there’s some real issues there. I have the occasional one take longer but they generally last 5-10 minutes. Anything that needs discussion is taken to separate calls.
Hitting dismiss and skipping it.
Pro tip haha
I like the suggestion to look at the system status.
One thing I’d suggest you try is to switch from people-centric to work-centric standup. Instead of going person by person, pick your rightmost “in progress” column and get an update on that issue. What’s needed? Who needs to help? That sort of stuff.
I find this moves through the standup fairly quickly and puts the focus on how to get things done. It also highlights when something isn’t clear for the team and you can follow up after.
I feel so strongly about this topic that I recorded a podcast episode on it with my at the time business partner[1]. I think that maybe the only relevant reason to have a synchronous standup is to align on the biggest problem to solve in the next workday.
A standup of this model goes something like this: what is the goal for the day? What support is needed to make it happen? etc.
[1]: https://podcasts.apple.com/us/podcast/better-stand-ups/id163... -- skip to about 10:00 to hear the above.
If I can’t report on what I did yesterday in excrutiating detail, how will I justify my job and avoid layoffs?
You can report on that, yesterday log can give the team important signals. It’s mentioned there. I encourage to focus on planning and cooperation though. Mainly cooperation so even when reporting yesterdays work it’s worth to emphasise things that impact others.
After almost 3 decades in the industry I can definitively say that if someone paid me 9-figure salary which came with daily standups I would politely decline
The SPUR Agenda can be helpful as a template:
• Status (good and bad — things done and left undone)
• Plans (incl. contingency plans)
• Uncertainties (untested assumptions, upsides/downsides, etc.)
• Reports? (e.g., document any agreements reached)
My teams daily standups are focused around raising issues and blockers, not as an individual status update. Sometimes nobody raises their hand and after 2/3 mins we go our merry way. Sometimes someone raises something that ends up being a 15 min. discussion (if there were no other hands raised, raised hands have priority).
My team does a daily update via a slack bot:
- what have you done
- what are you doing next
- are you blocked?
It works well, and any manager can see the output and follow up if needed.
This is an example of when Daniel Kahneman said that people don’t believe in something because there are arguments but believe the arguments because they believe in something. Here’s why I think so:
> syncing plans and priorities for the current day
Most of the work developers do require syncing multiple times a day, either by slack messages, GitHub comments or pair programming, etc. Waiting for the daily to sync is not realistic and would waste tons of time.
> signaling blockers early so the team can help
If you have a blocker and you wait until the daily to mention it, you have a bigger problem. Blockers should be notified right away and most teams do this over slack or other messaging platforms they use.
> encouraging collaboration and knowledge sharing
Teams are usually small, and if you don’t already know what someone is doing, you wouldn’t care what they have to say during the daily, and if you care what they have to say, you already know what they are doing.
> building a sense of team ownership and support.
Just go for a coffee break.
If you believe daily standups are useful, chances are you’re actually part of the problem.
> If you have a blocker and you wait until the daily to say it, you have a bigger problem. Blockers should be notified right away and most team do this over slack or other messaging platforms they use.
They should but it doesn’t always happen. Having a stand up makes sure you can get that information into the open.
This holds for literally everything. You shouldn’t hold back conversations for your 1-on-1 but, if you don’t have them, you’ll find there’s a load of conversations you miss out on that you needed to have.
Having a daily standup might be encouraging people to wait until the daily to mention blockers, which could be harming your team all while you think it’s working
It could but the fact I see conversations on Slack and hear in stand up “person X is already helping me with this” suggests otherwise.
I noticed that by asking my team a quick set of questions after our "good morning" virtual coffee corner helped them focus on the important stuff:
What are you up to today? Any blockers? What do you need help with?