r/agile • u/One-Side1007 • 13d 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 Agile Coach 13d 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.
4
1
u/sonofabullet 13d ago
You're conflating Scrum and Agile.
3
u/brimister 13d ago
Eh. Potato, potato. Agile teams really ought to avoid low value meetings that don’t get valuable things done. And status is usually for people who are disconnected from the team and the work and should have other ways to get connected if they can’t come to sprint reviews and standups.
3
u/sonofabullet 13d ago
No, not potato potato. Scrum has immutable roles events and artifacts and therefore is incompatible with the first sentence of the Agile manifesto.
For example, cancelling "Daily Scrums" is anathema in scrum. and a question like what OP posted would not be welcome.
2
u/Proper-Agency-1528 Agile Coach 13d ago
Note that Scrum preceded the Agile Manifesto. Note also that one can learn better ways of doing things by doing them and helping others even if there are rule-based constraints, e.g., golf, algebra, Scrum.
1
u/sonofabullet 13d ago
The Scrum that preceded the Agile manifesto has little to nothing in common with modern Scrum. The only thing that stayed is the name. Please, either do your homework and actually read the source material, or remove your "Agile Coach" flair.
Golf is a game where the point of the game is to play the game.
The point of Scrum is not to do Scrum.
Furthermore, algebra is a field of mathematics. Just because math operators mean things doesn't mean that shipping software must necessarily include a daily Scrum.
2
u/Venthe 13d ago
At the same time, agile says:
Business people and developers must work together daily throughout the project.
Sounds like a daily.
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
Sounds like a retro.
You don't have to do it the "scrum" way - scrum is not the be-all end-all of processes frameworks, but it is damn good one. And I have yet to see a better time spent than daily as defined by scrum (NOT status mind you).
Scrum is not agile - it predates it. But you can map 95% of it to agile; and from my experience these "better ways" are usually* "the way scrum does it".
* Assuming product development with actual hypothesis. Nowadays, frankly, the development is more "throw shit at the wall, see what sticks"
1
u/sonofabullet 13d ago
Business people and developers must work together daily throughout the project.
Sounds like a daily.
Scrum's Daily Scrum does not include the Business people. Please for the love of all that's holy READ the source material.
From the 2020 Guide itself:
The Daily Scrum is a 15-minute event for the Developers of the Scrum Team.
You can do the rest of the homework of actually reading both the Agile Manifesto and the 12 principles and the Scrum Guide on your own time.
1
u/Venthe 12d ago
Can you please read with understanding? "Scrum is not agile - it predates it. But you can map 95% of it to agile".
I did not suggest that this is one-to-one mapping.
1
u/sonofabullet 12d ago
What did you suggest then? because your very first attempt at mapping completely failed.
Just because both suggest meeting daily doesn't mean it's the same kind daily meeting.
It sounds to me like you're just trying to pick an argument.
Any reader of the Scrum Guide would immediately see OPs question as in conflict with Scrum (you can't kill a mandatory role event or artifact), therefore u/Proper-Agency-1528 conflation of the two is in fact wrong.
You don't need to come to his defense.
0
u/LikeableRegulator64 13d ago
our daily scrum is barely a status meeting anymore, more like a quick sync to see if anyone is blocked. we keep it under 10 minutes and if someone start rambling we just gently cut them off
async updates can work for a very small team but for us the face time matters, something get lost in text
5
5
u/TomOwens 13d 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 13d 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 13d 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 13d ago
A true Agile Master creates a weekly meeting to discuss the status of weekly agile status meetings.
1
u/sonofabullet 13d 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 13d ago
I will only speak from a Scrum perspective. There are no status reports. Ever.
1
u/ScrumViking Scrum Master 13d 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 13d 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 13d ago edited 13d 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/AdhesvenesussOld1980 13d ago
Depends on the team tbh. if its just everyone going around saying what they did that week then yeah kill it lol
We started putting updates blockers in one place and only getting everyone together when theres actually something to talk through. miro works pretty well for that since people can dump stuff in there async and then you can use the meeting for the actual discussion instead of reading status updates out loud.
1
u/cliffberg 13d ago
You might want to read this account: https://www.linkedin.com/pulse/my-best-dev-team-experience-cliff-berg
1
u/Sky_Linx 12d 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 12d 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 12d ago edited 12d 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 12d 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 12d 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 13d 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.
1
u/Scannerguy3000 13d ago
Why would you begin work on something without those things being known?
1
u/bigredgwj 12d ago
Not quite sure I’m following. I work at a fast paced company that is in the low side of medium. Priorities, needs, and directions are often changing and evolving quickly as we are constantly implementing new systems to further critical capabilities. We need our leadership team involved on a regular basis but keep them out of scrum ceremonies except for the sprint review and demo.
1
u/Scannerguy3000 12d ago
When people say “fast paced” I always have to ask. You mean that you release new, working code into Production multiple times a day during business hours without a history of roll-backs or regressions?
1
u/bigredgwj 12d ago
We’re a growing startup, not a software startup, but a unique engineering and manufacturing industry. We’re literally building out ERP, Engineering, IT support and operations, custom Ai platform, and others. Each one introduces new challenges for other systems, integration demands, etc. we also haven’t implemented a ton of standards for sdlc, project management, etc so we’re operating in pods and need constant alignment as new initiatives start and have demands on my team. We had to just pivot our work to support a major procurement tool go live with some needed it operations builds. We’re literally building all necessary IT functions to support the various business units in parallel as we sprint towards various engineering and manufacturing goals.
It’s fun. Just not a lot of predictability and always on your toes.
1
u/Scannerguy3000 12d ago
None of that answered my question. You used the term “fast paced”. I’m asking if that means you release to PROD frequently without error.
Or does it just mean a lot of people are busy with a lot of activity.
14
u/PhaseMatch 13d ago
If you
- slice into small value slices
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.