top | item 41544997

(no title)

twunde | 1 year 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.

discuss

order

gedy|1 year 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|1 year 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|1 year 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|1 year 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.

Aeolun|1 year ago

It may be explicitly stated, but I’ve never had a scrum meeting without all managers and project managers.

They also tend to make the stand-ups one hour long.

thayne|1 year ago

In my experience, if the PM isn't part of it, the standup doesn't happen, because no one else cares that much. If someone gets stuck on something or needs help we just send a slack message, no need to wait for a fixed meeting.

erik_seaberg|1 year 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.

jboggan|1 year ago

Real scrum has never been tried!

scotty79|1 year ago

Right. So in one team I worked in, the team leader had to take notes during stand-ups of what everyone is doing to deliver them to managers so they can browse at their leisure.

Lutger|1 year 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|1 year 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.

haspok|1 year ago

> The daily is about getting people unstuck with their current tasks

This I don't understand. Why do people need a daily to "get unstuck"? Are they not talking to each other? If I have a problem, I can proactively work on it, and contact whoever necessary. Unless you are very junior, this should not be a problem.

geodel|1 year ago

> 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.

Huh, this is same for all employers I have known or worked at. Maybe on some distant planet it is done right.

rolisz|1 year ago

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

usea|1 year 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.