Live data from Hacker News

Why Scrum is stressing you out

rethinkingsoftware.substack.com

121–130 of 462 posts

Re: Why Scrum is stressing you out

#122
post #112

People like to forget a thing: Kanban, which is the scrum "ancestor", was designed for FACTORY MASS PRODUCTION of already designed parts, not for designing new ones, on other words it's a system that works only if what you do is pre-defined, does not demand much intellectual, creative activities and anything it's well known in advance. Applying it to creative activities is a classic application of a religion to a soc…

Continuous delivery IS mass production.

Re: Why Scrum is stressing you out

#123
post #31

Earlier quoted context omitted.

What in Scrum is about keeping managers happy?

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…

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

Re: Why Scrum is stressing you out

#125
Agile/Scrum and all forms of project management is a scam you should work in layers serving layer above, have wbs and tasks assigned out of it in your layer, justifying urgency by impact on business/users, reward people who accept and close most tasks by appreciation and break. And fire anyone who misbehaves.

Re: Why Scrum is stressing you out

#127
post #81

Earlier quoted context omitted.

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.

Surely you're exaggerating about a one hour standup?

I wich

while it's not quite as bad for us 30min are the norm and it spilling to 40 min not rare and that is with us trying to cut it short

but too many other things are conflicting with short dailies, mainly sure to company structure/size

Re: Why Scrum is stressing you out

#128
post #92

I think back to the early 2000's, and there are other factors in play as well. Back then, I worked with a team of engineers that stayed together for over 4 years. In that time, we did not have Project Managers telling us to do daily standups. We met as an engineering team. We often would go days without having a formal meeting. But, software was different then as well. Everything is interconnected now. One team dropp…

> Nothing against CI/CD and continuous delivery, but the hamster wheel has gotten to a point where we have to release all the time. Corners are cut on everything, and testing is given lip service. Just to call it out: Having CI/CD doesn't mean you have to do all these things, or do scrum. It's imho just good engineering practice. I have it in my side projects, and I've had it at work on a Kanban-driven team (as well…

> When something breaks, having only 1 or 3 changes makes it really easy to figure out why. Recovering after a big release with 40 PRs in it is absolutely painful.

This is, by far, the most important reason to practice continuous deployment. I've been part of enough of these fire fighting sessions following big releases to see that it's not a sustainable way to deploy software. And yet, I've never been able to convince any boss I've ever had to adopt CD because they're worried it'll introduce more regressions into production.

Re: Why Scrum is stressing you out

#129
post #65

I’ve been building software applications for 40 years. No matter how you slice up the work, we all have to demonstrate progress and goal achievement. Agile, Scrum, Kanban, Method 1, or whatever are all meant to measure success. In a lot of cases there is a client or a customer that requires regular progress reports. Management uses reports to measure team performance. I’m not sure what planet the OP is from, but this…

The post is fundamentally about all the performance of making stories, assigning points, allocating work and doing standups all the time. None of that is required to actually create software. If people are judgemental around what stories are left uncompleted or points / week then the situation can become stressful for no benefit to anyone.

Scrum/Agile is basically an answer for things that went wrong in the past. Building software has a long history of delays, running over time, running out of budgets, etc. As a stakeholder/customer, you need certainties up front: how long is it going to take, what is it going to cost? And if you think this isn't reasonable, just consider, would you hire a contractor to work on your house that can't tell you up front cost and duration?

Anybody doing work needs to be able to estimate duration, progress, risk of delays, etc. Other people's work depends on your deadlines. Go/no go of a project depends on cost and duration.

Insight and tracking is required. None of this was done any better before agile.

Re: Why Scrum is stressing you out

#130
post #28

Earlier quoted context omitted.

Some things that come to mind: - burn-down / velocity charts - retrospectives - poker sessions - daily stand-ups - user stories and related tickets (eg in JIRA) There’s probably more ... Perhaps these things are not necessarily meant to make managers happy, though managers do seem to like this stuff. As a dev, I prefer a more fluid approach without all the rituals. In the start-up I joined a couple of months ago, we…

And sprints! When I started at my current job, I naively looked at the bugs and tasks assigned to me, and started picking and fixing the highest priority tickets. Then I was informed, "Oh no, that's not how we do things here. Don't look at the priority, just work on what is assigned to you in the current sprint." I had never heard of sprints before. More recently, I had a conversation with my manager and asked, "Do w…

The reply was "But if we didn't have sprints, how could we possibly measure the team's productivity and individual productivity?"

"Do you really need to measure that, or perhaps something else is more important?"

Post reply on HN