7 ms·

Daily stand-ups, the main benefit of which is that managers (EMs/PMs) get daily updates on status. Sprints themselves which promise that a certain amount of wor

by twunde 2y ago

Daily stand-ups, the main benefit of which is that managers (EMs/PMs) get daily updates on status. Sprints themselves which promise that a certain amount of work will always get done, without any free time being wasted. A lot of the ceremonies in general are mostly helpful to the EM/PM. How many things that you're doing are actually improving how you get work done? Especially when you consider how much time is spent on these ceremonies (sprint planning 1 hr, sprint retro 1 hour, daily standup 15-30 minutes. Plus whatever prep is needed and the interruption time.) For many companies this is a 20% or more overhead that's mainly busywork because you still need the additional meetings to understand what you're working on.

gedy 2y ago
This may sound like a no true Scotsman argument, when our company was trained by one of the scrum founders about 18 years ago, they were very clear that the daily standup was only for the team members, and the scrum master. (The scrum master could be a team member, and rotate btw). Managers were not allowed or invited to these. The only thing product managers and engineering managers would participate in and give feedback was in Sprint demos, and the beginning of planning meetings to answer any questions on upcoming stories. At the time it was incredibly freeing and fixed a pretty awful and behind waterfall project. I was (briefly) at a startup a couple years ago that said they "did Scrum" and what a clusterfuck that was - all the managers meeting daily with devs to see if they were behind and scold them if they were. See ya.
- ta_1138 2y ago
  But Managers as the center of the scrum is how many, many tech companies the outside world wouldn't call crappy run things. They also use Jira, mostly because they want reports that let people two or three levels up think they have any control over anything. One of my least favorite standups was even worse than a ceremony for the manager: The manager and the Product representative were there in every single one, but they didn't actually pay any attention: Another 20+ minutes of "parking lot" would be added after the 5-10 minute process as they asked the team all the random questions they thought they needed, in which they also proved that they weren't actually paying attention to the actual updates, or the tickets, or anything. In practice, a sequence of 1:1 meetings where everyone was stuck watching, because after inquisition to one person, it'd come after another. In practice, I don't think I've seen scrum run without a manager in standup, ever.
- LaGrange 2y ago
  Your scrum master is management. It’s just a renamed PM. I can run a very near standup when allowed to. I also think it’s a waste of time. Just send weekly updates to a group email, or something.
wild_egg 2y ago
> Daily stand-ups, the main benefit of which is that managers (EMs/PMs) get daily updates on status. The scrum guide fairly explicitly states that managers should not attend or be part of stand-ups unless they're actively involved in the work as part of the development team.
- erik_seaberg 2y ago
  That's hard to imagine. In big tech it's the team manager who decides that standups should happen and when (maybe this is an expectation from higher-ups). He always joins unless running late.
  - bigstrat2003 2y ago
    Be that as it may, if the scrum guide explicitly says they shouldn't then it isn't really fair to blame scrum for that. Honestly, the recurring complaints with scrum, agile, etc basically boil down to this: shitty organizations can make any system miserable. People generally are blaming the intermediate cause (how we do scrum sucks) rather than the root cause (our company sucks and nothing would work).
    - Aeolun 2y ago
      We blame scrum because the framework provided makes it a lot easier for life to be miserable.
      - rerdavies 2y ago
        Compared to what? You haven't truly experienced process misery until you've done a 4 year death march in a waterfall process.
    - bboygravity 2y ago
      Oh, the good old "the user is doing it wrong, the product is fine" with scrum being the product. Can anybody (not PM/leader) give 1 example of a company where they saw scrum being done "correctly"? crickets I guess scrum is fine and people just don't know how to do it properly.
rolisz 2y ago
Sprint planning 1h? Lucky you. At the former employer that was 6h (so basically the whole day was wasted)
- usea 2y ago
  I interviewed at a place whose sprint planning took a full week and was reportedly incredibly stressful. Customers participated. Their product was a website that agile teams used to track their process.
Lutger 2y ago
There are a lot of things better than scrum, but mostly these are all wrong ways to implement it. Daily: should average at 10 min, 15 min is really the maximum. Including prep. So 5-15 min. No status updates! The daily is about getting people unstuck with their current tasks and quickly aligning on what to do next. If it is not useful for the team, the implementation is wrong. Doesn't mean it always has to be useful and interesting to you, there's a difference. Management stays out of the daily. Sprint planning: the sprints are the compromise to management so we can have some sense of progress, so this is of course the one meeting that is useless to the team getting work done and can hamper productivity. Just make it quick. Retro: you should do a retro about if you think the retro is useful and why/why not. If the team doesn't think it is, either change it until it works or make this the very last one. Management stays out of the retro. ("But are you then not doing scrum anymore?" "So what, save the pedantry for writing out the functional and technical requirements please") Thing is, you do need to understand what you are working on, and it needs to be more or less the same as what your team members think they are working on. If you are 100% efficient at building the wrong thing, your 0% overhead amounts to exactly nothing, and the 80% efficient scrum team is infinitely more efficient. Though these extreme cases are usually a problem from higher up, without any way to align your work you will usually not be efficient. And if you are, then good for you, don't follow scrum like its some cult. But most teams need a little coordination. Basically if anybody feels a meeting (or anything, really) is a waste of time, there is a problem that needs addressing. And the problem is not the feeling, but what is causing that sense of waste. Take it seriously, it is almost always signaling a flaw in the process. Learn how to talk about this in the retro and get to the bottom of it. The retro is about debugging anything that isn't working optimal in the team. If you cannot find any bugs and fix them, then you are either perfect or just not good at debugging, and I know which one to bet one to be the most likely. One sure sign a team isn't very capable is when there is a lot of blaming involved. Usually external factors or tools get the blame, but in very dysfunctional teams people blame each other. If you work in a team that doesn't adequately address these problems and you have no power to change it, then it may be time to look for another job.
- marcosdumay 2y ago
  The ages old "you are doing Agile wrong". When nobody manages to do the thing right, then the thing isn't good. It doesn't matter what platonic ideal you hold for it.

by twunde 2y ago

gedy 2y ago

This may sound like a no true Scotsman argument, when our company was trained by one of the scrum founders about 18 years ago, they were very clear that the daily standup was only for the team members, and the scrum master. (The scrum master could be a team member, and rotate btw). Managers were not allowed or invited to these. The only thing product managers and engineering managers would participate in and give feedback was in Sprint demos, and the beginning of planning meetings to answer any questions on upcoming stories. At the time it was incredibly freeing and fixed a pretty awful and behind waterfall project. I was (briefly) at a startup a couple years ago that said they "did Scrum" and what a clusterfuck that was - all the managers meeting daily with devs to see if they were behind and scold them if they were. See ya.

ta_1138 2y ago
But Managers as the center of the scrum is how many, many tech companies the outside world wouldn't call crappy run things. They also use Jira, mostly because they want reports that let people two or three levels up think they have any control over anything. One of my least favorite standups was even worse than a ceremony for the manager: The manager and the Product representative were there in every single one, but they didn't actually pay any attention: Another 20+ minutes of "parking lot" would be added after the 5-10 minute process as they asked the team all the random questions they thought they needed, in which they also proved that they weren't actually paying attention to the actual updates, or the tickets, or anything. In practice, a sequence of 1:1 meetings where everyone was stuck watching, because after inquisition to one person, it'd come after another. In practice, I don't think I've seen scrum run without a manager in standup, ever.
LaGrange 2y ago
Your scrum master is management. It’s just a renamed PM. I can run a very near standup when allowed to. I also think it’s a waste of time. Just send weekly updates to a group email, or something.

wild_egg 2y ago

> Daily stand-ups, the main benefit of which is that managers (EMs/PMs) get daily updates on status. The scrum guide fairly explicitly states that managers should not attend or be part of stand-ups unless they're actively involved in the work as part of the development team.

erik_seaberg 2y ago
That's hard to imagine. In big tech it's the team manager who decides that standups should happen and when (maybe this is an expectation from higher-ups). He always joins unless running late.
- bigstrat2003 2y ago
  Be that as it may, if the scrum guide explicitly says they shouldn't then it isn't really fair to blame scrum for that. Honestly, the recurring complaints with scrum, agile, etc basically boil down to this: shitty organizations can make any system miserable. People generally are blaming the intermediate cause (how we do scrum sucks) rather than the root cause (our company sucks and nothing would work).
  - Aeolun 2y ago
    We blame scrum because the framework provided makes it a lot easier for life to be miserable.
    - rerdavies 2y ago
      Compared to what? You haven't truly experienced process misery until you've done a 4 year death march in a waterfall process.
  - bboygravity 2y ago
    Oh, the good old "the user is doing it wrong, the product is fine" with scrum being the product. Can anybody (not PM/leader) give 1 example of a company where they saw scrum being done "correctly"? crickets I guess scrum is fine and people just don't know how to do it properly.

rolisz 2y ago

Sprint planning 1h? Lucky you. At the former employer that was 6h (so basically the whole day was wasted)

usea 2y ago
I interviewed at a place whose sprint planning took a full week and was reportedly incredibly stressful. Customers participated. Their product was a website that agile teams used to track their process.

Lutger 2y ago

There are a lot of things better than scrum, but mostly these are all wrong ways to implement it. Daily: should average at 10 min, 15 min is really the maximum. Including prep. So 5-15 min. No status updates! The daily is about getting people unstuck with their current tasks and quickly aligning on what to do next. If it is not useful for the team, the implementation is wrong. Doesn't mean it always has to be useful and interesting to you, there's a difference. Management stays out of the daily. Sprint planning: the sprints are the compromise to management so we can have some sense of progress, so this is of course the one meeting that is useless to the team getting work done and can hamper productivity. Just make it quick. Retro: you should do a retro about if you think the retro is useful and why/why not. If the team doesn't think it is, either change it until it works or make this the very last one. Management stays out of the retro. ("But are you then not doing scrum anymore?" "So what, save the pedantry for writing out the functional and technical requirements please") Thing is, you do need to understand what you are working on, and it needs to be more or less the same as what your team members think they are working on. If you are 100% efficient at building the wrong thing, your 0% overhead amounts to exactly nothing, and the 80% efficient scrum team is infinitely more efficient. Though these extreme cases are usually a problem from higher up, without any way to align your work you will usually not be efficient. And if you are, then good for you, don't follow scrum like its some cult. But most teams need a little coordination. Basically if anybody feels a meeting (or anything, really) is a waste of time, there is a problem that needs addressing. And the problem is not the feeling, but what is causing that sense of waste. Take it seriously, it is almost always signaling a flaw in the process. Learn how to talk about this in the retro and get to the bottom of it. The retro is about debugging anything that isn't working optimal in the team. If you cannot find any bugs and fix them, then you are either perfect or just not good at debugging, and I know which one to bet one to be the most likely. One sure sign a team isn't very capable is when there is a lot of blaming involved. Usually external factors or tools get the blame, but in very dysfunctional teams people blame each other. If you work in a team that doesn't adequately address these problems and you have no power to change it, then it may be time to look for another job.

marcosdumay 2y ago
The ages old "you are doing Agile wrong". When nobody manages to do the thing right, then the thing isn't good. It doesn't matter what platonic ideal you hold for it.