1. To force a check in so that everyone keeps the manager up to date. This is annoying for people who already do that as a matter of course, but not everyone is that disciplined.
2. To demonstrate velocity to the higher ups. We can't get away from the fact that upper management needs reassurance that we're not just fucking around. With these bullshit numbers we can make them feel better, and that's just all around a good thing that helps preserve harmony.
The moment you try to explain scrum as an efficiency tool, you're on shaky ground. It's a tool to counterbalance human nature.
(I promise I know the below is an idealist stance)
I disagree; there's nothing saying the manager has to be there. In a properly run team/project with good ticket discipline, managers should get their status updates from the ticketing system.
Standups, applied properly, are an infra-team communication tool. They're a formal structure to encourage communications, and raise issues early. They're not a replacement for the informal comms that all good teams do, just a check.
Similarly, velocity should only be used by the team - your sprint commit is the output, and the expectation you set for outside stakeholders, and velocity is a tool to help you get better at that expectation setting.
Yep, I'm aware of how it "should" be. And for smaller companies it's absolutely feasible. But the larger you get, the more layers between people, the less personal connection there is, and so you need formal practices like this to act as grease (and OMG the stuff we have now is SOOOOO much better than the crap of the 90s, even if imperfect).
At the end of the day, you take some kind of procedure, modify it to your company's culture, and try to make it work. There's no silver bullet, or even a bronze bullet.
My firm introduced Scrum in 2023 and it's so clearly about #2.
* The sector of the business I'm in is 90% about integration with third-party services. How many sprints does it take to walk through their certification process? Depends how many cycles the third-party wants, how fast they respond, etc. So we end up checking in tasks representing "2 weeks of work" that really mean nothing so the points can be made up.
* The long-established policy (pre-scrum) involves several phases (development, another developer reviews, QA, final review by project manager). Any one can be a bottleneck. So if Frank in QA has enough points for his sprint, Dev Steve probably can't take on any more tasks even if he has capacity.
* This also works on a time scale; you're often going to end up with "last Thursday of the sprint, there's nothing left in the queue, and we have to twiddle our thumbs or possibly start some experimenting on next sprint's work" -- it's hardly a smooth process of "just keep pulling tasks".
* The primary outcome of all the meetings is that they complain "we're delivering 80% of our estimate one sprint, and 115% the next sprint, how can we be more predictable?"
Bearing in mind the number of points have nothing to do with actual achievements and business value; a huge spec uplift on the #1 partner can end up as fewer points than just endless weeks of dragon-chasing for a partner that will never deliver a dime of revenue.
1. To force a check in so that everyone keeps the manager up to date. This is annoying for people who already do that as a matter of course, but not everyone is that disciplined.
2. To demonstrate velocity to the higher ups. We can't get away from the fact that upper management needs reassurance that we're not just fucking around. With these bullshit numbers we can make them feel better, and that's just all around a good thing that helps preserve harmony.
The moment you try to explain scrum as an efficiency tool, you're on shaky ground. It's a tool to counterbalance human nature.