May I ask why? This coming from the guy that has to facilitate them.
I’m especially curious about the stand-ups, since I have mixed feelings about retrospectives myself, they have their place and I think they play a part in a team’s growth, but at the same time I’d rather just cancel them if I don’t feel we’d get anything useful out of it and I don’t want to hold a retro just because the process says so.
LE: Gonna just edit this to say thank you to the people who replied, gave me some new perspectives to think about.
I think the value of standups depends a ton on the team’s composition and maturity.
On a team with a lot of junior or low-performing devs who don’t have the experience or the ability to keep themselves on track, or a team with a culture that discourages asking for help as needed, a daily standup can keep people from going down useless rabbit holes or unwittingly blocking one another or slacking off every day without anyone noticing.
On a team of mostly mid-level and senior devs who are experienced enough to work autonomously and who have a culture of communicating in real time as problems and updates come up, a daily standup is pure ceremony with no informational value. It breaks flow and reduces people’s schedule flexibility for no benefit.
When I’m thinking about whether it makes sense to advocate for or against daily standups on a team, one angle I look at is aggregate time. On a team of, say, 6 people, a 15-minute daily standup eats 7.5 hours of engineering time a week just on the meetings themselves. The interruption and loss of focus is harder to quantify, but in some cases I don’t even need to try to quantify it: when I ask myself, “Is the daily standup consistently saving us a full person-day of engineering time every week?” the answer is often such a clear “yes” or “no” that accounting for the cost of interruptions wouldn’t change it.
I’ve just had some unlucky jobs, I think. Think 30-45 minute stand-ups for a team of 4, because the team lead or PM or “Scrum Master” feel like they have to prove their worth or something when ultimately the standup provides little to no value after the first 4 minutes (if any).
For jobs with a single ADO or Jira board, just look at our ticket status and comments.
I had one job that had daily stand-ups, a single ADO board, a requirement to send EOD status update emails, and a requirement to copy those updates to individual ticket comments EOD as well. I rage quit that job after 2 months because, frankly, that’s absurd (it had other issues too).
My favorite standup at a job was one with 12-16 people and it took no more than ~6 minutes. It was no BS. The manager got his quick update notes across all supported clients (and separate ADO/Jira boards) and everyone got to go about their day. If you talked too long you’d get cut off.
But generally, daily stand-ups are just an interruption and a thing where I end up having to make up some BS to appease management. If my update is too long, team members hate it. If it’s too short, management thinks I’m not doing any work.
As for retrospectives, of 15+ jobs in my life, only 2-3 of them ever even did anything with the feedback. Thus, it typically felt like a waste of 1-3 hours (yes one job had 3 hour retrospectives every two weeks, it was brutal). If none of the bads or nexts are ever going to happen, then don’t pretend like we even have a voice.
If your stand-ups and retrospectives aren’t BS, provide understood value, and don’t waste time then I’m fine. But if all they exist for is to check a “we’re agile!” box and allow management to flex, then I’d say it’s doing the exact opposite of agile and merely annoying the engineers.
For stand-ups you really need at least one person that keeps it on track and limits the time each person has, cutting them off and telling them to talk after.
In my experience I feel like I’m basically talking to myself during the stand ups. No one is actually listening to anyone’s status except maybe the scrummaster. I’ve said things in the standup to have coworkers be surprised later on when they’re actually carried out.
May I ask why? This coming from the guy that has to facilitate them.
I’m especially curious about the stand-ups, since I have mixed feelings about retrospectives myself, they have their place and I think they play a part in a team’s growth, but at the same time I’d rather just cancel them if I don’t feel we’d get anything useful out of it and I don’t want to hold a retro just because the process says so.
LE: Gonna just edit this to say thank you to the people who replied, gave me some new perspectives to think about.
I think the value of standups depends a ton on the team’s composition and maturity.
On a team with a lot of junior or low-performing devs who don’t have the experience or the ability to keep themselves on track, or a team with a culture that discourages asking for help as needed, a daily standup can keep people from going down useless rabbit holes or unwittingly blocking one another or slacking off every day without anyone noticing.
On a team of mostly mid-level and senior devs who are experienced enough to work autonomously and who have a culture of communicating in real time as problems and updates come up, a daily standup is pure ceremony with no informational value. It breaks flow and reduces people’s schedule flexibility for no benefit.
When I’m thinking about whether it makes sense to advocate for or against daily standups on a team, one angle I look at is aggregate time. On a team of, say, 6 people, a 15-minute daily standup eats 7.5 hours of engineering time a week just on the meetings themselves. The interruption and loss of focus is harder to quantify, but in some cases I don’t even need to try to quantify it: when I ask myself, “Is the daily standup consistently saving us a full person-day of engineering time every week?” the answer is often such a clear “yes” or “no” that accounting for the cost of interruptions wouldn’t change it.
I’ve just had some unlucky jobs, I think. Think 30-45 minute stand-ups for a team of 4, because the team lead or PM or “Scrum Master” feel like they have to prove their worth or something when ultimately the standup provides little to no value after the first 4 minutes (if any).
For jobs with a single ADO or Jira board, just look at our ticket status and comments.
I had one job that had daily stand-ups, a single ADO board, a requirement to send EOD status update emails, and a requirement to copy those updates to individual ticket comments EOD as well. I rage quit that job after 2 months because, frankly, that’s absurd (it had other issues too).
My favorite standup at a job was one with 12-16 people and it took no more than ~6 minutes. It was no BS. The manager got his quick update notes across all supported clients (and separate ADO/Jira boards) and everyone got to go about their day. If you talked too long you’d get cut off.
But generally, daily stand-ups are just an interruption and a thing where I end up having to make up some BS to appease management. If my update is too long, team members hate it. If it’s too short, management thinks I’m not doing any work.
As for retrospectives, of 15+ jobs in my life, only 2-3 of them ever even did anything with the feedback. Thus, it typically felt like a waste of 1-3 hours (yes one job had 3 hour retrospectives every two weeks, it was brutal). If none of the bads or nexts are ever going to happen, then don’t pretend like we even have a voice.
If your stand-ups and retrospectives aren’t BS, provide understood value, and don’t waste time then I’m fine. But if all they exist for is to check a “we’re agile!” box and allow management to flex, then I’d say it’s doing the exact opposite of agile and merely annoying the engineers.
For stand-ups you really need at least one person that keeps it on track and limits the time each person has, cutting them off and telling them to talk after.
Exactly this. Nothing ever gets done with the feedback so what is even the point? Just to make it look like we care?
In my experience I feel like I’m basically talking to myself during the stand ups. No one is actually listening to anyone’s status except maybe the scrummaster. I’ve said things in the standup to have coworkers be surprised later on when they’re actually carried out.