Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Scrum Sucks

blog.mb-consulting.dev

Post reply on HN
Print view View original

41–50 of 298 posts

Re: Scrum Sucks

#41

Post by yieldcrv »

rightbyte wrote: post #14
Aurornis wrote: post #7

I added up all of the time we were spending in Scrum-related activities at a recent job. The company hired a lot of project and program managers who were pulling everyone into everyone meeting. I presented the number of hours (meetings multiplied by engineering participants) to our VP and he insisted I must be wrong. He insisted there was no possible way we could be spending that much time doing Scrum things and that…

The far biggest time sink is not what you logged though, but how you need to pad estimates and delay work to please the Scrum Lords. Like, the burndown chart has to be nice and steadely go to zero. There is no way to do that without decoupling reported hours and estimated hours from actual hours. Or points. It doesn't matter which.

I saw this on my last job!

I was already adding time to my work like an extra point or two here and there

But then in the grooming session the whole team would guesstimate even more story points! I was dumbfounded! This was beyond all of my levels of tolerance and rationality but it kept happening every sprint until something that was a 0.5 for me was a 5 point and I would have two 5 point tickets for the whole sprint that I would submit to QA one day before the sprint ended, 9-10 business days later

and actually doing that made me a star performer, what the hell!?

Re: Scrum Sucks

#42

Post by hknmtt »

Scrum/Agile is awesome! I always used the daily calls to ask as much dumb shit as possible to make the meetings as long as i could so i could keep charging my hourly rate without actually working.

Re: Scrum Sucks

#44

Post by lacrimacida »

Aurornis wrote: post #7

I added up all of the time we were spending in Scrum-related activities at a recent job. The company hired a lot of project and program managers who were pulling everyone into everyone meeting. I presented the number of hours (meetings multiplied by engineering participants) to our VP and he insisted I must be wrong. He insisted there was no possible way we could be spending that much time doing Scrum things and that…

I have a similar experience to yours. My organization even hired a scrum expert who is probably just deadweight, he’s on mute in all our meetings for the past 6-8 months. It’s also true about having little actual work time, in my org we spend so much time in meetings that in the end 3-4 hours of actual work are left on a daily basis. I objected to this but was told everyone should learn everything, end of story. We’re supposed to be repleaceable cogs in a machinery and that goal was reached by now.

Re: Scrum Sucks

#45

Post by pydry »

milesvp wrote: post #33

I’ve seen “scrum” work. The single most important thing we did was the retro always happened. In the retro we somehow managed to create a safe space where we could honestly discuss ways to improve. This may never be repeatable depending on the culture of the company, but the goal of a retro is to be a safe space where honesty is possible. Without honesty there can be no improvement to the process. Is some ceremony pr…

Retros are useful. I don't think it's original to scrum though. I think it emerged out of one of those Japanese manufacturing process thingies.

Re: Scrum Sucks

#46

Post by lowercased »

rightbyte wrote: post #14
Aurornis wrote: post #7

I added up all of the time we were spending in Scrum-related activities at a recent job. The company hired a lot of project and program managers who were pulling everyone into everyone meeting. I presented the number of hours (meetings multiplied by engineering participants) to our VP and he insisted I must be wrong. He insisted there was no possible way we could be spending that much time doing Scrum things and that…

The far biggest time sink is not what you logged though, but how you need to pad estimates and delay work to please the Scrum Lords. Like, the burndown chart has to be nice and steadely go to zero. There is no way to do that without decoupling reported hours and estimated hours from actual hours. Or points. It doesn't matter which.

"POINTS AREN'T TIME! THEY'RE EFFORT AND/OR COMPLEXITY!" I've been routinely told. Yet... low complexity stuff was expected to take less time, even if it was high effort. All 'in my experience' of course.

Changing 95 files because someone didn't want to centralize some value in a method call last year (YAGNI!) is now high effort, even if low complexity.

Then... "that's too many files in a PR! break it up! no one can review that many files!" It's the same two line change in each file - this shouldn't take that long to 'review'.

I've often spent more time arguing about points/effort/estimates than doing the low effort work. But if we don't record it properly, you won't get 'credit' for the work!

Slow-paced insanity when taken anywhere near close to its logical conclusions.

Re: Scrum Sucks

#47

Post by lucidguppy »

Holy shit people - scrum does not work without a fundamental understanding of the theory of constraints.

If you're burndown chart isn't burning down, something is blocking your team. A manager finds out what is blocking the team and works on it.

If your team has a bunch of tickets in process- then your WIP is high - that's bad. Someone taking on more tickets to just get to work should be pulling the equivalent of an Andon cord.

Tasks should not have estimates - tasks should roughly have the same time to complete - a task that takes 10 days is not a single task.

A sprint meeting should only assign new tickets based off the previous rate of completion. Adding more WIP only fucks things up more than they are.

Management sees the rate of completion of features - and then calculates the time to project completion in sprints.

IF YOU HAVE A DEADLINE and you're missing it...

- cut back on features - or find out what's blocking your team.

Developers need to be told to emphasize and raise up items that are blocking them.

In any value stream - there is only one current constraint. The rest of the production process needs to be subordinated to the constraint. Is it pull request reviews? Is it the QA process? Is it ambiguous tickets? Are questions not getting answered?

Re: Scrum Sucks

#48

Post by azangru »

> Scrum is broken

That section describes various scenarios how scrum can be misapplied — starting from a team that doesn't find value in it ("Does your team still attend the stand-up meeting [without PO and SM in the office]? I doubt it."), and ending with various organizational dysfunctions (bosses, hierarchy, confusion, estimation, someone writing useless tickets, people not collaborating, and so on).

Why are those organizational dysfunctions Scrum's fault? Why is the title of the article "Scrum sucks"? Not clueless bosses suck, or orgs that are too firmly set in their ways suck?

Re: Scrum Sucks

#49

Post by onion2k »

Aurornis wrote: post #7

I added up all of the time we were spending in Scrum-related activities at a recent job. The company hired a lot of project and program managers who were pulling everyone into everyone meeting. I presented the number of hours (meetings multiplied by engineering participants) to our VP and he insisted I must be wrong. He insisted there was no possible way we could be spending that much time doing Scrum things and that…

The amount of time lost to doing Scrum things was so out of control that some people had fewer than 3-4 hours per day to actually work.

If the aggregate of the sprint planning, backlog refinement, retro and dailies is more than 10% of the total time (eg 1 full day out of a 10 day sprint) for most of the team then something bizarre is going on. If the everyone is losing 50% of their time to agile things then your process is impressively broken.

Re: Scrum Sucks

#50

Post by cylinder714 »

Zigurd wrote: post #20
Scubabear68 wrote: post #10

One comment - the article mentions that Waterfall was basically the only approach used prior to agile. This is false. In some industries waterfall was used, but in others software was designed and driven incrementally just as with core agile. The work I did in fixed income brokerages in the early 90s was largely ad hoc agile.

Scrum is just one offshoot of Agile. It has become laden with jargon, Scrum-specific job titles, and rapidly trained Scrum Masters. This obscures the fact that a competent team can start with traditional jobs and roles and use The Manifesto for Agile Software Development as their guide, with some modifications for a remote, Slack/Zoom world. Don't be afraid to dump Scrum.

It seems like scrum is the very antithesis of "Individuals and interactions over processes and tools."
Post reply on HN