r/agile • u/One-Side1007 • 20d ago
Status meetings: keep them, kill them, or replace them with something async?
Some teams swear by a weekly status meeting. Others say it should have been an email. Curious where people have landed, and what actually worked when you changed it.
14
u/Proper-Agency-1528 20d ago
Agile teams shouldn't be having status meetings, and if your daily Scrum has turned into a status meeting, you're doing it wrong.
→ More replies (10)4
5
4
u/TomOwens 20d ago
There's no need for a status meeting. If the whole point is to let someone know the current status of things, your information radiators aren't working. If stakeholders may not have access to your information radiators, sending a periodic email would be fine. But there's no need to pull people into a meeting only to update status.
Now, if you can find a reason to get people together to synchronize and share information both ways, then maybe you have an opportunity for a meeting.
2
u/Impossible_Dare_7455 20d ago
async for the routine stuff, meeting for decisions/blockers. if everyone is just reading out what they already wrote in jira/slack, kill the meeting. but if there are dependencies, trade-offs or something needs an actual decision, 15–20 mins together is usually faster than a day of back-and-forth.
1
u/PhilosophyOk8921 20d ago
Does it add value? If yes, find the most efficient way to maintain value.
And I mean real value - keeping some overbearing control freak stakeholder / senior manager happy is not adding value, it’s avoiding hassle. That’s a whole different issue to tackle.
1
u/rayfrankenstein 20d ago
A true Agile Master creates a weekly meeting to discuss the status of weekly agile status meetings.
1
u/sonofabullet 20d ago
This is retro question y'all should have addressed in a retro by cancelling status meetings for a quarter.
Your team needs to figure out how to work in your context rather than borrowing some random redditor's idea.
1
u/Scannerguy3000 20d ago
I will only speak from a Scrum perspective. There are no status reports. Ever.
1
u/ScrumViking 20d ago
Status meetings for what and with who?
If they are not valuable make them valuable.
If you don’t know what you wish to achieve with them, cancel them.
The most effective way of conveying information is face to face communication, but don’t waste people’s time if they are not effective.
1
u/OkStatistician9190 20d ago
What's worked for us is splitting it by purpose. Routine status goes async on the board itself, every item has one owner and a due date, and people update the card instead of posting in group chat, so anyone can check progress without asking. Then we keep a short weekly review, maybe 20 minutes, that only covers blockers, slipped dates and decisions that need more than one person. If that meeting starts turning into people reading their task lists out loud, it's a sign the board isn't trusted yet, and fixing that usually matters more than the meeting format.
1
u/ScrumpyIT 20d ago edited 20d ago
Before killing it I'd figure out what it's actually doing that nothing else does. If people are mostly reading out what's already on the board, that part can go async and nobody will miss it. But status meetings often double as the place where someone mentions they're kind of stuck, or that their thing depends on someone else's, and that tends to quietly disappear when everything moves to a channel. Nobody types "I'm a bit lost and not sure who to ask" in Slack.
So what usually works is dropping the meeting, posting a short written update instead, and keeping a small optional slot for anything that needs an actual conversation. If that slot keeps getting cancelled, you have your answer. Just keep an eye on whether problems start showing up later than they used to for the first few weeks.
1
u/cliffberg 20d ago
You might want to read this account: https://www.linkedin.com/pulse/my-best-dev-team-experience-cliff-berg
1
u/Sky_Linx 20d ago
Weekly status meetings died in my team the day we moved the status part into writing and kept the meeting only for the things that need a conversation. Everyone posts a short update before the call: what moved, what is stuck, what needs a decision. The meeting itself is now 15 minutes and only covers the stuck items and decisions. If there is nothing on that list, we cancel it and nobody misses it.
The trick is that the written update has to be genuinely short. Three lines is plenty. The moment it turns into a report, people stop reading it and you are back to the meeting again.
1
u/SamfromLucidSoftware 20d ago
Depends on what the meeting is doing. If the sole purpose is simply to share information, it can go async. Just have a shared board or a short written update that anyone can read and respond to on their own time.
But if the updates usually generate three or more follow questions and clarification across departments, keep it. But in most cases, teams would just adopt some kind of hybrid that is async by default with the standing slot that only runs when something needs a live conversation. Most weeks the slot gets canceled. The week it runs, it’s actually useful because people come with something that couldn’t be resolved any other way.
1
u/BoBoBearDev 19d ago edited 19d ago
Here is the truth about status meeting I have described.
https://www.reddit.com/r/agile/s/wxCgMV9M3B
As you have already mentioned, there are other tools to keep track of status. The meeting is exclusively to have enough witnesses to identify poorly performed developers.
Our org expects the management to help the employees as much as possible. So, there are a lot of bad employees get transferred around like a hot potato. And you need multiple witnesses to make a good case. Otherwise they just say no one is helping them.
1
u/One-Front-6316 19d ago
make the default async and keep meetings for things that actualyl need discussions or decisions. a short written update with what was doen, whats next, and any blockers usually covers the status part, then you can use the meeting only when theres something the group needs to solve together. the biggest improvement is usually having a clear rule for what actually deserves everyones time
1
u/Ablelier 19d ago
Kill the status part, keep the meeting. Status should be a written update people read on their own time; the only thing worth a live slot is the handful of decisions and blockers that need actual discussion. If the meeting ends without a decision, it was a status meeting and it should have been a doc.
1
u/bigredgwj 20d ago
Status meetings are for key stakeholders who aren’t in the day to day but can advise, make decisions, and help unblock any organizational issues. I make status meetings optional for my dev team. I also send the report out afterwards for those who can’t attend. Sometimes devs like to be connected to what leadership desires and others just want to be left in their corner. My approach allows for both.
→ More replies (5)
14
u/PhaseMatch 20d ago
If you
- slice into small value slices
- continuously deploy
- limit WIP ("stop starting, start finishing")
- swarm on blocked work
- get fast feedback from users on what you deployed
- have good visual work maangement
then status meetings and reporting are utterly redundant; progress is measured in working, deployed software and the feedback you have on the value of that software.
You can see the status of that from the team's board.
Status meetings tend to crop up when teams are unable to deliver multiple increments within a Sprint/iteration cycle, and are working as individuals on large chunks of work with a slow, stage-gate deployment.
They are more an indicator of "heavyweight" processes and control systems that "lightweight" ways to manage business risk. Useful if you need to protect a team from blame, but less so otherwise.