The "3 standup questions" are terrible and need to die(morethancoding.com) |
The "3 standup questions" are terrible and need to die(morethancoding.com) |
The business term for this is "best practice".
>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.
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.
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 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.
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?
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.
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.
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.
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.
Managers don't need to attend.
> 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.
Sounds like a decent question to me.
If you do meet daily, though, these 3 questions are still useful.
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.
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.
If a standup goes longer than 2 ish minutes a person, it's no longer a "stand up". Pull up a chair, sit down and chat, you're having a meeting.
The 3 questions could be answered in 1 to 2 sentences... the check in is for every one to see everyone else's face to inform secondary meetings.
One reason is because it eliminates facilitation on my part. I don't have to cut people off and make them stay on topic.
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.
But that's just me, and if a team collectively likes the time and the ritual, then they should keep it.
> Tevye: You know... you are also right.
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.
Mixing it up and asking different questions from time to time can help get people to actually think and provide some new answers.
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.
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.
[0]: https://reharp.com
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.
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.
† 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.
However, the blockers question is a waste of time. Blockers should be resolved as fast as possible, not wait until the next scheduled meeting.
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.
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.
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.
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.
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.
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.
That said, about once per week someone will sincerely speak up with a blocker and get help.
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.
Why do you need a extra meeting to have a sync point to ask for a quick chat.
Just fucking talk to your team mates! Is everyone in kindergarten now?
> Back in the good old days [...] What have we sold ourselves lately?
Maybe I'm just unusually fortunate to have mostly worked on well-functioning teams.
Maybe you are super fortunate. Standups are just one method too. It’s not like it’s dogma and must be followed.
But it’s a useful technique. So saying it’s unnecessary seems odd. At least generally speaking.
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.
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.
Which is one reason look for and ask different questions - if may break someone out of a rut.
It’s easier to change the questions to improve responses.
Gantt charts exist for a reason
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.
Any blockers?
Yes one I told you about earlier today
Yes same one we had for a months
Yes I've been ignoring it until this meeting.
What works in real life is saying to the project manager we need to extend the timeline because of these factors. Things get unblocked quickly.
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.
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.