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

Why Scrum is stressing you out

rethinkingsoftware.substack.com

Post reply on HN
Print view View original

171–180 of 462 posts

Re: Why Scrum is stressing you out

#171

Post by bdangubic »

AnarchismIsCool wrote: post #3

I've learned to hate software process. If you have team sizes set sanely and empower devs to do what they need to do in order to accomplish the goal, they'll be fine without the management overhead of arbitrarily imposed productivity flow. Agile et al, along with 99% of the features in ticketing systems, exist to make managers feel like they are justifying their paycheck. If you are a manager and this makes you angry…

After 26 years in the industry this is the only process that actually works - hire the right people and get the F out of the way

Re: Why Scrum is stressing you out

#172

Post by binary132 »

swergi0 wrote: post #77
binary132 wrote: post #44

This article hit really hard. I’m super stressed with my team’s cadence right now. I often think about what’s pathological in modern-corporate-scaled-agile-abominations and this really hits the nail on the head, but I think for me the main complaint is that if you can only see two weeks into the future, planning can become very difficult. I also often think of how our scrum process makes me feel like I’m back in grad…

does your team not follow any sort of higher-level roadmap?

people invested in scrum all think it’s great

people who have to do the actual work don’t.

you should pay attention to that

Re: Why Scrum is stressing you out

#173

Post by shade »

meowfly wrote: post #71
jghn wrote: post #32

Earlier quoted context omitted.

I've been a dev, and I've been an EM. The only thing on that list I've ever liked is the velocity charts. And the only reason I liked them is that it helped me give a slightly less made up date to my own bosses to explain when something might ship. Over the years I've found that devs have been the one who like retros. Or at least a certain subset of them. When I've been an EM I would try to get rid of them, only to h…

Retros all too often focus on the last thing that happened and risk turning into a complaint session. I've told my team anyone is welcome to ask for a retro whenever for any reason, but we don't make them recurring meetings because there is too much of a temptation to find something wrong to fill the time.

Best retro I ever had, on a small team of seniors: we all sat down, looked at each other, agreed that a sprint happened and we couldn't think of anything that was good or bad about it. Then we called in our manager, who also acted as scrum master, so we could do planning for our next sprint. I thought this was reasonable enough - ostensibly we'd do retro and then planning back to back, and none of us minded the chance to take a few minutes and reflect if we had anything we should discuss.

By contrast, I've worked with scrum masters who were strict about the process and insisted _every_ retro needed to have at least one improvmenet or action item out of it, preferably more. I found this pointless and I've rarely seen them actually followed up on.

Re: Why Scrum is stressing you out

#174

Post by cdaringe »

bruce511 wrote: post #80
cdaringe wrote: post #27

Earlier quoted context omitted.

ex manager here. managers are in an even worse wheel. biz demands managers show up to even _dumber_, less organized meetings than devs think they have to deal with. eng to eng meetings tend to be fine, but the rest of company culture at BigCorp weren’t trained in structured problem solving. it’s negotiating with goldfish half of the time (generally friendly goldfish), and no one actually practices any formalisms or l…

With software you have a situation with two problems. First is the "gap" between those doing the work, and those writing the checks. (When it's the same person, this problem disappears.) The guy editing the checks likes to understand progress is being made, and that the project both has an end and will be successfully completed. The second problem is that by it's nature software "never ends" and many (dare I say most…

Trust and rapport are gained in time, often in short order. Small artifacts of evidence should generally prove to the bean counter that they are cutting checks for something!

Re: Why Scrum is stressing you out

#175

Post by jakub_g »

The forever-sprinting approach indeed is unmanageable long term.

In my prev job we used to have a cycle of 2-3 sprints followed by 1-2 weeks of rest (to handle tech debt etc.)

In other companies it could be named "innovation week" or something similar.

I still didn't love this, precisely due to always wanting tangible deliverables within 1-2 weeks, while sometimes you just need more time to think clearly about some problem.

We partially mitigated it though by explicitly stating whether a giving story is "delivery" or "discovery", the latter being used to better understand the scope of the problem, current status quo, validate assumptions etc.

Re: Why Scrum is stressing you out

#176

Post by 2-3-7-43-1807 »

jrs235 wrote: post #163
2-3-7-43-1807 wrote: post #159

Earlier quoted context omitted.

1) scrum is even more democratized than agile 2) no matter what "agile" was supposed to mean - managers anyway interpret it as devs having to be very agile for them all the time ...

And by "devs having to be agile" you mean "devs having to be interruptible during managers hours and flexible in doing their work after all the bs office hours are over".

exactly ... i mean even without hindsight "agile" is a rather poor choice as the label. it just evokes the wrong ideas too easily.

Re: Why Scrum is stressing you out

#177

Post by luckydata »

cassianoleal wrote: post #146
ern wrote: post #115

Earlier quoted context omitted.

I’m not sure why the above comment is being downvoted: I was reading The Practice of Cloud System Administration: Designing and Operating Large Distributed Systems, and I came across this quote: Royce’s 1970 paper, which is credited with “inventing” the model, actually identifies it so Royce can criticize it and suggest improvements. He wrote it is “risky and invites failure” because “design iterations are never conf…

Probably because of exactly that. > Royce’s 1970 paper, which is credited with “inventing” the model, actually identifies it so Royce can criticize it and suggest improvements. That means people were doing waterfall then, just maybe not calling it so. > Sadly, multiple generations of software developers have had to suffer through waterfall projects That means even after it being given the name "waterfall", "multiple…

You should try actually reading the paper.

Re: Why Scrum is stressing you out

#178

Post by scott_w »

RussianCow wrote: post #128
gregmac wrote: post #92

Earlier quoted context omitted.

> 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 convin…

The way I’ve explained this before is “would you rather small issues that we can fix one by one until anyone really notices or would you rather we hit all those issues in one big go?” Your mileage may vary.

Re: Why Scrum is stressing you out

#179

Post by jksmith »

20240915 wrote: post #139
jksmith wrote: post #63

Earlier quoted context omitted.

Evolution of a manager and scrum team achieving high-performance together: Team: "We are having trouble with Bob." Manager: "Ok I'll talk to him." Team:"We are having trouble with Bob." Manager: "Don't come to me, you guys need to deal with that in your retro." Team: "We voted Bob off the island." Manager: 'Ok, I'll forward to HR." Autonomous teams get more done because they have eliminated management as a wait state…

What if the board hires engineers, who then hire (and can fire) their manager. What if the entire company is inverted.

Sure, maybe optimize further. Why have managers? The CD pipeline goes throughout the whole value stream, not just at delivery. Just like delivery automation (eliminate intervention of humans), there's also human automation (helping people get out of their own way). So I could see a use case where managers are just eliminated. You need people who can eliminate the noise and replace with enough signal that delivery teams can execute. POs and stakeholders can do that; managers not needed.

I think what you bring up though is an interesting point: maybe managers needs to transition to business engineering roles.

This all will play out in the 21st century. 20th century management is a legacy artifact at this point. Best example is F500s, which are generally mediocre in their execution. If a SpaceX type org (14k employees, private) gets into their space, they're screwed. Even with politicians in their pockets, I don't see how rock swallowing dinosaurs like Boeing (170k employees, public) will make it. Just the energy they have to expend to get anything done compared to SpaceX is massive, due in part to their giant management bureaucracy.

Post reply on HN