I think context is really important. The design of the stand up was meant to be a light touch checkin at regular intervals just to make sure we're staying aligned and people aren't getting stuck on stuff. So criticisms like
>Focuses on activity, not outcomes
Isn't really valid, because the standup isn't where you discuss outcomes, that's a separate thing that alredy happened, we've already decided the activities you're doing and how they align to outcomes. We don't need to rehash that daily.
>Doesn’t reveal any information about when that work will be completed
Again, there's a separate process for that.
I think it's a fair point that if you're doing standups, and you're not doing them as part of a broader agile framework then yes - maybe you do need to think about what role the standup fills and therefore what questions to ask. But if you're actually trying to follow something like Scrum then those questions are not stand up questions, there's a separate process for that.
I think that the author is making a mountain out of a molehill. But even aside from that, they don't really give an argument for the thesis. Things like "Focuses on activity, not outcomes" are not evidence for something being harmful. It's just arguing against buzzwords with buzzwords.
The primary point of standup is to make sure the team gets face-time together every day to talk about their shared workload. Humans are social creatures and getting everyone together for a few minutes is a pretty high ROI activity.
Standups could make sense in a team that isn't operating well, but in a well-functioning team, everyone is having these sorts of discussions with each other during the natural course of each workday anyway. Standups are unnecessary then.
My experience with standups is that they're almost entirely worthless. They're rote and performative and rarely, if ever, provide anything that was missing.
It's still valuable to share information about progress and impediments with the whole team. Alice and Bob may have some blocker that they've been communicating about, but Chris wasn't a part of those one-on-one conversations, so the standup gives him some valuable context about what's going on with the rest of the team. Maybe his work depends on something Bob was supposed to complete today that's going to take a few more days, or maybe he's encountered a similar problem before and has some advice, or maybe he'll remember the issue when something similar pops up later on. Alice and Bob would have resolved the blocker themselves, but this helps make sure the information is shared across the team in a way that simply moving cards on a kanban board wouldn't communicate.
I've begun to believe that all of this ceremony is driven from an unspoken belief that well functioning software teams are a myth.
sure it would be great if people raised issues themselves instead of skulking. were proactive, took pride in their work, engaged joyfully with their collaborators, and developed real consensus and velocity.
but that's just a fairy tale. developers are generally useless, stubborn, lazy, petty, and fundamentally disorganized. lets not shoot for the moon and try to get them to work together. lets just dumb the whole thing down to try to get _something_ out of them.
I disagree. Especially with remote teams, standups are how I find out that other people on the opposite end of my team are blocked on something I can easily help them with, or that they're doing something that has implications on my own work. I communicate with some people continually. There are others I'd hardly see if it weren't for standups.
> There are others I'd hardly see if it weren't for standups.
If that's a problem, it's a sign that the team is not functioning well. Standups can be a band-aid for the issue while a real solution is being developed, but it isn't a long-term solution in and of itself.
I think the routine maintenance is key for staying well-functioning. The problem is that once things are not functioning well it may be too far along to fix.
So it’s like saying why should married couples have routine date nights because if they were well functioning, they wouldn’t need to schedule. The point is to function well and it’s a useful technique.
But since in a well-functioning team everyone knows where everyone else is already, there is nothing that can be said in a standup that isn't already on everyone's radar.
Maybe I'm just unusually fortunate to have mostly worked on well-functioning teams.
I think that there is separation between intentional knowledge transfer and accidental. It's great as an opportunity for accidental knowledge transfer, where one developer didn't know she could ask for help by another developer. Or that task can be picked up because it hasnt changes the status yet( not released) but other can start working if needed.
yeah, getting alignment across the team and doing a vibe check at the cost of ten minutes seems pretty reasonable to me, the questions are basically just variants on "how's it going?"
They are too specific, formulaic, and reek of management tactics. If you mean, "how's it going?", say, "how's it going?" As the wise Dr. Seuss said, "I meant what I said and I said what I meant."
Hows it going is too vague for many. Every ask a kid what they learned at school today? The answer is always "nothing", or silence. You need to ask a different question to get a good answer.
Which is one reason look for and ask different questions - if may break someone out of a rut.
If you answer "fine" to "how's it going" at standup, you aren't doing your job. It's not the prompt that needs to be specific, it's the engineer. If there are follow up questions, those can be asked, but asking the same three specific but thoughtless questions is just like having a form you have to fill out any time you make a change.
Yeah but that's to be expected because they are kids. If your coworkers act like children, that's a problem; they should act like adults because they should be adults. What's easy usually isn't what's right.
It’s not acting like children. It’s acting like humans.
If it’s easier to tweak questions or retrain everyone on my team, me included, I’m going with the easier path every time.
In this case easy is right because the specific question isn’t what’s important. What’s important is the community, discussion, and information shared.
I don’t think so. People know what the purpose of a standup is. You don’t even need a prompt to get one going, just have everyone go around in a circle and talk. They will do it automatically. Isn’t this basically the point of the article?
The primary purpose is provide highlights that can be sold as stories for management.
If you are looking for a social event that's what happens at lunch over an hour while sitting not a 5 minute standup where everyone is trying to say just enough so they can get back to work.
It's sad the standups are considered a social event. Back in the good old days you finished your work chilled on a cheap startup couch while two others played ping pong and you chatted. Or you met up a bar after and threw darts. What have we sold ourselves lately?
> The primary purpose is provide highlights that can be sold as stories for management.
Speak for yourself. My team has a small window of overlapping time zones and it's a valuable opportunity to get everyone together and sync on all our projects. But our work is all loosely interrelated, so that's actually something we need to do.
It's not a "social event" in the sense that you all get to hang out and make friends. It's a social event in the sense that it's an opportunity to verbally engage with your colleagues in a group setting.
I agree that standup makes little sense on a team of people who are all working on unrelated projects. The silliest thing you can do here is assume that what works for you will work for everyone, and what doesn't work for you won't work for anyone.
My company makes a big point in work-life balance. We can meet up in a bar to throw darts at most 2 times per year - anything more and we are impacting family time. Lunch is a good social time, but that is personal time and often better spent meeting with people not on the team (some always go home, some meet with old team members...) Your team should meet during your normal 40 hour work week (or whatever hours you work) for team social time.
Meeting up over lunch doesn't work for remote teams. Nothing worse than eating while on camera. No thank you, I've tried and it's really not great. Especially if you have a hybrid team where some people are in the office eating together in a conference room and some are remote solos, the dynamics get really weird.
One of the biggest benefits to a synchronous standup is you know everyone has showed up and is available to discuss work stuff. With remote teams and flexible schedules, having a hard sync point helps people communicate better, even if it's just "hey, let's stay on the call (or start a new one) for an extra 10 minutes to sort this out" instead of spending hours or days in async communication.
Fly everyone to one place so they can do this. Twice a year is good - enough that it is a good vacation/team building exercise, not so much that people feel like they are married to their job not their spouse.
Sure, we get it. But when you add forced rituals to the mix (such as the very worst: coerced standing), it ends up being just numbing and grating, especially over time.
And when it gets to the point where you can just tell that most people are mouthing something to check boxes, while checking out, internally -- in that sense, it basically defeats the intended purpose.
I also do not see any value in the current questions; individual status should be communicated with in a tracking tool.
The standup is a chance to get everyone together, raise and share any issues or clever solutions or whatever, maybe get a 'feel' for status, and tell some jokes. It should be short, maybe extremely short sometimes.
The standup questions are awkward motivation killers. The people that look good in those meetings are usually just pandering. I'm convinced standups have stuck around because they make managers feel like they're adding value. If people are waiting until the next workday to be unblocked your team is moving too slowly.
On the flip side having the team chat regularly is a value add. Maybe you can talk about upcoming product things, ideas people have, the market in general, and any other thoughts people have top of mind. But forcing everyone to talk about what they're working on is counter productive. Everyone on the team knows if they want to know. If there isn't team visibility to what everyone is working on then something else is broken.
> If people are waiting until the next workday to be unblocked your team is moving too slowly.
Nobody said anything about waiting. Getting blocked can come up after yesterday's standup and still be an issue lesss than 24 hours later despite working on it.
> If there isn't team visibility to what everyone is working on then something else is broken.
Some people don't claim/update their tickets. Most people don't update their tickets with progress every day. Most people don't push WIP branches (and if they did, who has the time to look thru the entire team's WIP code?). Teammates on the ground are interested in what, specifically, their peers are working on and thinking about overlap/potential conflicts on the ground.
The process isn't to wait until the next standup. Asking for blockers is the manager's way of ensuring no-one is keeping a blocker from them. A functional team would have devs who float blockers when the arise and most of the time they would answer the question with "no blockers."
This is in contention with the usual developer gripe about being interrupted from focus. Sometimes the blocker is your teammate who doesn’t like interruptions. Or a junior has been told to or assumes they need to “figure it out” and wastes a bunch of time instead of asking.
> a junior has been told to or assumes they need to “figure it out” and wastes a bunch of time instead of asking.
Often you don't even know. More than once I've discovered someone working on a complex problem - they were making progress so didn't realize that someone else already had a solution and so they could save days of effort by asking the right person the right question.
Right. My point is there's a cohort of people here who are like "dont bother me, I only check email/slack in the morning, need extended focus time". At least some of those people are the ones who might know a thing or too, but they breed a culture of discouraging even bringing an issue up.
You're missing the purpose. It isn't to just sit and wait till the next day to get help. It's to highlight issues that could not be resolved in that time frame, and pointing out that help (or intervention) is necessary.
It's the equivalent of saying "Service X was down yesterday, still hasn't come up, and if nothing is done about it, we'll lose another day."
In teams without standups, these blockers could go on for several days, and no one other than that one engineer would know about it. Now everyone knows and can adjust/react accordingly.
Server is still down today.. we can forget about it until tomorrow meeting. Look it's still down.
Cancel the standup and go work on the server.
A meeting around this issue with people from other teams/external actors causing the blockage is the help you need. Not a daily status meeting. The standup rarely helps here
If someone spent 3 hours on it the previous day and couldn't get it to work, that extra 15 minutes on it are not really critical, wouldn't you agree?
> The standup rarely helps here
The standup is not intended to solve the problem, but to inform. It's to say "Hey, it's down. Tried all day to get stakeholders to work on it. It's still down because X[1]. We may not hit our commits for this sprint (or month, or quarter, or whatever)".
The goal is to keep everyone on the same page, and make a point of sync. They could have emailed this out, but in my experience, half the team isn't going to read the emails. Or they'll read it and forget it immediately because they're busy with Y. As much as people like to say it, I've found highlighting blockers in the SUM more effective.
At the other end of the spectrum, you don't want a "Oh, the server went down 5 days ago so I couldn't work on X" to be followed with "Why didn't you tell us?!" With the SUM, a lot of those surprises go away.
As an aside, in SUM-less teams, I often have seen "Why didn't you tell us?!" followed by a response pointing to the email that was sent 3 days ago telling everyone. With the SUM, if you have a good scrum master (external to your team), he will force everyone not to ignore it: "OK, this person has been blocked for 3 days due to an external team. Can anything be done about it? If not, I think it's time to inform management/stakeholders of the delay in their timelines".
As another aside: The other purpose of the SUM is to prevent someone from doing something wrong for days on end. It's common to have someone say he's blocked because of X, to be told straight away "What are you doing? You don't need X at all! We need to talk" The conversation resumes between the two after the SUM. In Scrumless teams, I've seen people work on the wrong thing for weeks because no on else knew the developer misunderstood the problem.
BTW, I'm not a fan of Scrum. When done well, it's great. But it rarely is done well. However, I've not seen Scrumless teams perform better than one with an effective Scrum. And a poorly run Scrum is often the worst of them all.
[1] X could be the team responsible isn't responding, has higher priorities, are working on it but haven't resolved it, etc.
This sound eerie and exotic to me. In what world when server is down people wait for the next standup to announce it? Why not just create a shared channel (slack, teams, mattermost, irc, whatever the company standardized on) and use it to communicate asynchronously and resolve problems like that immediately?
> In what world when server is down people wait for the next standup to announce it?
I'm not sure why this is so strange to you. There are many possible scenarios where a server can be down, with varying levels of severity/impact to our team.
It happens all the time. I have 4 things to do. One of them involves a server (that we don't own). It goes down. I file a ticket and work on the other 3 things. It doesn't need to be resolved immediately. But if it isn't resolved in 2+ days, it may affect our timelines. People should know. If it got resolved in a few hours, I've wasted people's time by emailing them.
If it's critical and we need it resolved ASAP, sure - email/IM others in your team immediately to let them know.
> Why not just create a shared channel (slack, teams, mattermost, irc, whatever the company standardized on) and use it to communicate asynchronously and resolve problems like that immediately?
This was answered in my comment: People often ignore it. I can't count how often I've been in non-SUM teams where a developer is asked "Why didn't you tell us?" only to have him whip out one (or several) emails/IMs where he did tell it. Calling it out (repeatedly) in a SUM gives other developers less deniability, and the SM will highlight it: "This person has pointed out 3 days in a row. What's preventing it from being fixed?"
But the question for you: Are you always going to leave it to the individual developer to decide what is important to tell others? He may view it as unimportant whereas others believe it is. Making them explicitly say it as a blocker in a daily meeting ensures the disconnect doesn't last long.
Often blockers can persist for several days or even weeks if they come from external factors. If your manager/team lead spots that you've reported the same blockage from infrastructure twice in a row they can chase that up for you. The idea that any given blocker could/should be resolved within the same working day is just a fantasy.
Yep, my team rarely reports blockers but when they do it's almost always some external factor. If they are reporting the same thing multiple days in a row, I can light a fire under someone's ass, otherwise I might not even know about it.
Excuse me? I didn't say anything at all about the timeline being pushed. You literally just made that up. Talk about strawmen.
Blockers that are reported on daily standups are things that can be worked around for now but will become problematic if not fixed. If something preventing my team from doing literally any part of their job they'd report it right away, of course.
I agree this is a great question. Maybe more for managers, but it let's people think "This is day 2 of that blocker, I need to step in". Sometimes junior devs will let external asks sit too long and write it off as "blocked on another team". Managers can manage this.
A better version I recently came across is “is there anything you need from anybody?”
This includes the classic “blocker” but besides that opens up for interesting conversations, encourages cooperation and isn’t overly management focused.
For the manager it helps uncover potentially hidden dependencies or team animosities.
With my workplace, this one is always kicked around at the end of standup and is usually taken as a joke. Even the boss is in it. It basically means "we're done, now back to work."
That said, about once per week someone will sincerely speak up with a blocker and get help.
A better title (supported somewhat by the article) is "standup needs to die". If you have a task list and keep it updated, you don't need to meet daily.
If you do meet daily, though, these 3 questions are still useful.
I support daily standup (and stand down as needed) during times of churn / tight deadlines. These should be exceptions not the rule.
The current use of stand up meetings as status meetings while also expecting everyone to be interruptible all day every day is a joke. It's just people reverting to desire for power to "see what people are doing".
I think a healthy, highly functioning team needs to meet once or twice a week at designated times and otherwise, _ESPECIALLY_ for remote teams, comms should be free flowing and work tracking tools up to date enough that no scheduled meeting is needed as it is pointless repetition.
These three questions are intended to keep standups short. I haven't, personally, been on a team that sticks to this format. It always ends up with individuals talking about their individual implementation thoughts on whatever they are working on. During this time, others zone out, missing anything that could be important. Nobody learns anything, and nobody is able to fully concentrate on their tasks.
I purposefully schedule meetings after our standup to make sure I cut it off after 30 minutes. Our team of 11 will go for almost an hour if nobody cuts people off.
I had 8 people in standup today, the whole meeting took 4 minutes - mostly because of 2 people who had some after meeting news to share. As the team tech lead I need to keep track of what everyone is doing and just looking at stories in progress isn't enough to know if they are making progress or I need to jump in. (most of the time they are or they ask questions after the meeting). There is value in everyone knowing how the current story is progressing, but it should only be a few minutes. I run my standup 3x week as I don't need this daily, but I need to keep track that things are happening.
Ouch. 15 minutes is the rule. 30 minutes is way too long. I was in only one team that followed the rule, and after 15 minutes people would start leaving the room regardless of whether others are talking. If someone had a habit of speaking too much, he was coached.
When we were on site, we would try to schedule the room such that someone else had a booking at the 15 minute mark - so you had no choice but to keep it in that window.
This is easily solved by just having a facilitator who actually facilitates. Whether that's a scrum master, a manager, a team lead, or just a member of the team who isn't afraid to cut people off, it really is not that hard to keep standups to 15 minutes, maybe 20 for a team that big.
I'm surprised to not see not more agreement on here so far. I personally find the three questions rote, boring, and coming up with content that feels satisfactory is a chore. I agree with trying to think critically about the goals of the practice and whether the default standard practice is best serving those goals.
But that's just me, and if a team collectively likes the time and the ritual, then they should keep it.
The comparison to a soccer team is very odd. Further, Brian seems to completely misunderstand the point of standup as he's trying to argue that standup is not conducive for collaboration.
Standup is not the forum for collaboration. Standup, and the three associated questions is purely and simply a dialog enabler. A healthy team has multiple dialog enablers. It's what helps break down the invisible barriers of communication and collaboration. ShapeUp recommends another great dialog enabler - appetite. It's quite literally why dialog enabler tools like gather.town and Slack Huddles exist - because teams struggle enabling dialog.
Cherry on top: Brian opens up by ridiculing appeal to authority, then finishes the article by appealing to authority.
> Managers around the world blindly adopt the same standup meeting format, without critical thought to its usefulness. It is the meeting agenda version of “you won’t get fired for buying IBM”.
> Now that the latest official Scrum guide has already removed the 3 questions, our industry should consider eliminating them too.
The 3 questions help keep the meeting on track. I was once part of a team that didn't follow the "3 questions rule" and all standups were at least 1hr+ in length with a few going to 2-3 hours in length, basically a debugging session with a ton of people on the call that didn't need to be there.
It seems like a decent jumping off point for young teams, but any question asked daily will become routine. I know on my team most people reflexively say, “no blockers,” at the end of their standup, even when they have blockers. In some cases they just talked about their blockers for several minutes while talking about what they were working on, then claimed there were no blockers.
Mixing it up and asking different questions from time to time can help get people to actually think and provide some new answers.
Yes the good old format of "take an everyday developer routine and attack it, thus causing outrage and clicks". Standups are necessary. It gives a start in the day. The 3 questions are necessary but short, they are answered in 10 seconds. All the other additional ad-hoc info is what's important.
> and suddenly the manager walks on to the pitch and says, “OK, gather around! Where did you kick the ball yesterday? Where are you planning on kicking it today? Any blockers?”
There are sports, like handball, where each coach can call a very short timeout at more or less any time during the game for exactly this purpose. The team and coach gets to spend a minute together to adjust their tactics on the fly, based on what is working, and what isn't.
Otherwise, I agree with the conclusion of this piece, that a manager/leader should tailor their meeting(s) to what is required for their specific team to work best. If the team consists of people that all pro-actively communicate, then the meeting might not be needed. If the team has problems with making deliveries on time, then slightly more shepherding is perhaps needed.
I have a product that's an alternative to this. [0]
It's a video shorts hub for your team. You press a hotkey that activates screen & audio recording. You can record little blurbs about things throughout the day.
As someone who was a project manager before "agile" and during I think it is funny to remember how I used to get pressure go from waterfall planning or kanban to agile with daily stand ups. It always felt like a fad and yet I felt a lot of pressure to get with the program.
That phase of my career is long done but my advice to people in that phase is this. Beware of management fads and beware of companies that slavishly adhere to a fad, particular one advocated by consultants. One of the companies I encountered that was most fanatic about "agile methods" was also probably one of the least efficient and slowest to roll out a product. They also had a number of senior execs from management consulting.
We've eliminated a lot of the structures of scrum from our team and it's helping be flexible and happier.
Since we don't have any meetings besides when we actually need to be available to coworkers, standup is now a time for us to hang. "What do you have going on?". Sometimes it's sharing an idea, sometimes it's a blocker, or it's to show off a little demo of what they did.
It's not a Frankenstein of postmortem and playtesting and demos and tgif, it's just being there for the team every day.
I've found what could be called the SPUR agenda to be useful: Status; Plans; Uncertainties; Risks.†
† As I understand it, in economics, "uncertainties" are things that simply can't be known; "risks" are things that have known outcome possibilities but it's not (yet) known which will happen, e.g., which sides of a pair of dice will come up. This is from a book I'm reading, Fluke, by Brian Klass.
Talking about what I did/what I’m planning to do on a regular cadence forces me to reflect on my time spent and makes me more focused. I also love hearing what others are up to because it promotes collaboration between us. The latter point is completely ignored by the author.
However, the blockers question is a waste of time. Blockers should be resolved as fast as possible, not wait until the next scheduled meeting.
I disagree. They're a great way to quickly get a status update on how things are progressing, what progress is going to be made today, and what is potentially blocking that progress.
Stand-ups meetings by definition are activity focused and not outcome focused. You don't need a daily reminder of what the outcome is, but you do need a daily status update as to how you're moving towards achieving that outcome.
Stand ups suck, long live stand ups. It's like any other meeting, signal to noise ratio is quite low, but what's the alternative? I love remote work, hope to never go back into an office, but humans are social animals. I feel like if I don't get some face time with people, communication becomes challenging. Chalk it up to overhead.
I have always complemented the three questions with a row-by-row look at the current stories or goals for the team, with the guiding question there being “what do we need to do to achieve this goal?”
The two are complementary in that the person-by-person polling helps flush out which people might need some extra help or swap around tasks.
Honestly, any and all of these fads - Scrum or whatever - are just ways for poor managers to feel important. Oh, and for expensive consultants to earn money.
If you have a solid team, literally any methodology will work. The best methodology is the one the team chooses, and that may well change for each particular project.
I can't help but have a negative reaction to having this discussion at all. All human beings are unique and different. Getting a group of them together means you will have a unique group dynamic.
Each team needs to develop a process that meets the needs of the group. For some teams standups are useless because the team is on the high end of the communication spectrum and also on the high end of the process spectrum, meaning they communicate well and update their tickets. Other teams are on the low end of both of these and benefit from standups and management structure that forces improvements to both of those.
Agile is about building systems, tools, and processes that allow your team to win. That requires understanding how your team operates and what they need to do their best work. There will never be a right answer to the majority of these types of questions.
> Managers around the world blindly adopt the same standup meeting format, without critical thought to its usefulness. It is the meeting agenda version of “you won’t get fired for buying IBM”.
>Focuses on activity, not outcomes
Isn't really valid, because the standup isn't where you discuss outcomes, that's a separate thing that alredy happened, we've already decided the activities you're doing and how they align to outcomes. We don't need to rehash that daily.
>Doesn’t reveal any information about when that work will be completed
Again, there's a separate process for that.
I think it's a fair point that if you're doing standups, and you're not doing them as part of a broader agile framework then yes - maybe you do need to think about what role the standup fills and therefore what questions to ask. But if you're actually trying to follow something like Scrum then those questions are not stand up questions, there's a separate process for that.