Live data from Hacker News

Why Scrum is stressing you out

rethinkingsoftware.substack.com

91–100 of 462 posts

Re: Why Scrum is stressing you out

#91

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…

In the nearly 30 years of doing this, I’ve had more success delivering good quality software that meets business requirements under waterfall than any of the SCRUM implementations I’ve worked with, and I am saying that without disagreeing that waterfall has its problems. In the agile space, kanban is the only one I’ve felt is productive, but it has trouble scaling to multiple teams.

Re: Why Scrum is stressing you out

#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 as on scrum).

It removes disputes over build process (eg, nobody can ever say "well, it complies on my machine"). It is a form of build/deploy documentation. It removes bottlenecks ("only Tom knows how to deploy that service, but he's on vacation") and stupid mistakes ("whoever deployed this last did it wrong and left a bunch of old files around").

I also have found deploying regularly is stress-reducing. For one, with CD the development environment is running the same steps, and we know it works because we do it dozens of times a week. The longer it's been since last prod deploy, the less confident we can be it'll go smoothly, whereas when it gets deployed every few days it becomes a non-event.

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.

None of this means you have to release everything on a regular schedule (like a sprint). You can still do long running branches or feature-flag things off, Just try not to go too long without deploying something.

Re: Why Scrum is stressing you out

#93

What I dislike about SCRUM specifically is that if you're having a rough week at home, recovering from illness or you just have things to do outside of work, you can't really just have an easy week and make up for it later on. It's a kind of constant grind and we always have a way of "filling up" our sprint. If we don't meet our target, it always feels like a fail. I know it shouldn't feel like that but it's human na…

I just completely ignore sprints, or sprint/standup meetings. Somehow it works well enough that nobody has called me out on it yet.

If they all want to waste 2 hours a day, more power to them.

Re: Why Scrum is stressing you out

#94
post #58

One hill I will utterly die on: Many people (including some in these comments) are fully able and happy to go their entire career mistaking high performing individuals with a high performing work framework.

Because for high performing individuals the framework doesn’t really matter? Most people aren’t high performing, so they’re designed to get the best out of the mediocre ones.

Re: Why Scrum is stressing you out

#95
post #90

Earlier quoted context omitted.

>> None of that is required to actually create software. Agreed. (Assuming you mean "create" as in write, as distinct from create as in get funded.) >> If people are judgemental around what stories are left uncompleted or points / week then the situation can become stressful for no benefit to anyone. Clearly no stress is better. But these things create stress in the other direction too. Slower than expected progress,…

> Agreed. (Assuming you mean "create" as in write, as distinct from create as in get funded.) You are essentially saying “Shit is bad, give up on it ever improving.”

Not at all. Quite the opposite. To improve the situation you first need to understand it.

It seems to me that most devs don't understand the root problem, so they both don't understand, and don't constructively improve the current solution.

Improvement is not "leave me alone". Improvement is finding efficient ways to remove stress from higher-ups. Because stress rolls downhill.

Re: Why Scrum is stressing you out

#96
post #2

We moved from sprints back to work queues for exactly this reason. Output is exactly the same but no one is cutting corners to "finish" the sprint. We still use a kanban and do estimation the same exact way, but rather than arbitrary deadlines, devs are trained and encouraged to communicate on their velocity in a way that is far more effective than a daily standup. Scrum was an idea that had its time, but after like.…

The main value of stressing about sprint goals and what's "in" a sprint and finishing it is the very specific situation of there being a bunch of people who want to feed in a large amount of work to a team (usually bugs/support requests/operational work) and it results in constant prioritization issues. If you don't have that situation, you probably don't need to be really careful about what's in a sprint.

Kanban lets you prioritize exactly the same way, except it doesn't have to fit into a sprint schedule. You also have to make good stories, which are independent, have a meaningful thing that gets delivered and are of a reasonable size. Then important bugs can get moved to the top of the to-do column, and get done quickly as possible without interrupting any in-progress work.

Re: Why Scrum is stressing you out

#97
post #60

Earlier quoted context omitted.

That's normal nowadays, even in the most ridiculous of situations. I once found that a system was getting a little expensive. As, AWS was billing us a million a month expensive. I figured this out, and came up with a plan that would cut it down to 80 thousand by spending 4 days: You know, a mild, 11 million a year of savings. Management insisted that the work had to go through scheduling, and intake, a process that w…

What was the opportunity cost of potentially deprioritizing other work?

^ nothing the team was working on came even remotely close to that ROI.

I read it as that the opportunity cost would be lower.

Re: Why Scrum is stressing you out

#98
post #81

Earlier quoted context omitted.

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

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?

Re: Why Scrum is stressing you out

#100
post #81

Earlier quoted context omitted.

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

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.

You never had a SCRUM meeting.
Post reply on HN