Live data from Hacker News

Why Scrum is stressing you out

rethinkingsoftware.substack.com

411–420 of 462 posts

Re: Why Scrum is stressing you out

#411

Earlier quoted context omitted.

There are agile processes other than Scrum. Scrum has gotten all the press for some reason, but there are other options. I personally prefer Kanban. The sprint is not a useful deadline for me so I want to ignore it.

Agreed. But Kanban also often incorporates some of the processes from Scrum like daily standups that aren't prescribed anywhere in Agile. Personally I find it more useful to organize things around useful product milestones that are actually usable and demo-able. Those might take a week, or three weeks, but probably not two months because that's a long time to go without a demo and getting feedback. Sticking to a rigi…

Agile is not against processes when needed. Agile is against too much process.

Re: Why Scrum is stressing you out

#412

I'm not a engineer but I can't believe engineers took the scrum/agile workstyle and adopted it like that. Why didn't they vote with their feet? It's almost inhumane; sprints are those 10-20 seconds you run in a 100m 200m dash. Marathon is how you run faster. So, forcing people to do repeated sprints is for me, bad for your health, without exaggerating.

>I can't believe engineers took the scrum/agile workstyle and adopted it like that. Why didn't they vote with their feet?

They didn't. Execs were charmed by people who took a 2 day training class on scrum and told them it would streamline their development process and would save money. Since execs are incentivized by P&L, saving money gets them bigger bonuses. These execs typically have no idea if their dev team is good or not. I'm sure there are exceptions, but all the ones I've talked to seem pretty clueless; and they are the ones making major decisions.

>Why didn't they vote with their feet?

Since tech is a cargo cult; people who make these decisions have no idea what they're doing with dev, for the most part, they just ape other companies. The result is you can vote with your feet, but you'll just walk into another scrum environment.

Scrum works best when all your developers are mediocre and would stare at the ceiling all day if you didn't task them with something. It's probably not a coincidence that scrum came about when hiring cheap offshore labor was really building up steam.

Re: Why Scrum is stressing you out

#413

Earlier quoted context omitted.

We use Agile at our company and let me tell you, it sucks. Maybe straight up scrum would be worse, but honestly agile is invasive and just feels like you’re being babysat and forcing people to give BS updates at standups because they’re afraid of sounding unproductive.

The stand-up is an opportunity to call out things that are blocking you, not for giving status updates. I got Scrum certified for resume padding, and thought it was gonna be easy, but I was blown away by the things I "knew had to be part of Scrum" that actually weren't. This is all there is to Scrum, if it's not here it's not part of it: https://scrumguides.org/scrum-guide.html It's like calling the electoral college…

> The stand-up is an opportunity to call out things that are blocking you, not for giving status updates.

I find it very useful for allowing everyone on the team to have a general idea what everyone else is working on. You can call out to ask for help at any time [1]. But having a 15 minute meeting each day to make sure everyone has a view of all the pieces in movement is handy.

[1] Though the standup does give a place for people that aren't comfortable calling out when they're having issues.. to do so because it's expected there.

Re: Why Scrum is stressing you out

#414
post #392

Earlier quoted context omitted.

I think estimates are wrong but useful and necessary. I don’t think it’s a strawman argument at all. For simple activities you can get by with no estimates but with dependencies estimates become more and more necessary.

I never understood this point of view. It's impossible to predict the future, and it's impossible to predict the complexity of something you've never done before. Given that, estimates can not be useful, other than as a tool for political post hoc justification. I have personally only ever had success with estimates that were "is this a project, or is this a task that belongs to a project". Perhaps stretching to t-sh…

> It's impossible to predict the future, and it's impossible to predict the complexity of something you've never done before. Given that, estimates can not be useful, other than as a tool for political post hoc justification.

It is, however, possible to provide more information than "whatever" about how long it will take to achieve a goal. I have had goals I've worked on that were summarized with things like

- Could take anywhere between 2 days and 2 weeks, depending on factors

- Has an external dependency on X, and we don't have any insight into when X will be available

- May have other external dependencies, but we won't know until we're a few days into the work

- Not sure yet what the complexity of using is, so we'll need to check back in with more information once we have some time to experiment with it

- Expectation is about 5 days, on this, but it could be as short as 1.5, and could be as long as 3 weeks, depending on some factors

All of those things are more information than you had before, and allow the people that make decisions (which may be you and your team, or may be someone higher up the chain) to make _better_ decisions (or at least, better informed decisions)

And if you're working on something that you literally have no information on what's required for it, what the complexities might be, what the unknowns might be, etc... then perhaps the task you should be working on is "Identifying the work required to achieve ", not "".

Re: Why Scrum is stressing you out

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

As someone who works in a hard-tech startup, where daily standups in production manufacturing teams are part of the daily culture. 1) Anything longer than 15 minutes is insane 2) What do you even talk about for an hour? 3) Why do you even do standups for design work? What "blockers" could you possibly have that require daily, 15 minute tagups with the entire crew?

One of the projects I'm on has a standup every day, and it generally lasts less than 15 minutes. Sometimes, a topic comes up that needs more discuss and it's tabled until the end of the call. At the end, anyone that doesn't need (or want, sometimes it's useful to just listen in) to be part of the additional discussion drops off and it turns from standup to technical discussion. It works pretty well.

Re: Why Scrum is stressing you out

#416
post #377

Earlier quoted context omitted.

As someone who works in a hard-tech startup, where daily standups in production manufacturing teams are part of the daily culture. 1) Anything longer than 15 minutes is insane 2) What do you even talk about for an hour? 3) Why do you even do standups for design work? What "blockers" could you possibly have that require daily, 15 minute tagups with the entire crew?

>What do you even talk about for an hour? We once had 1 hour long standups. The reasons were: 1) large team 2) many devs loved to go into detail about their work, and no one stopped them 3) the expectation was that a standup must be about describing what you did yesterday, in detail What we did: 1) split the team into subteams where each team has their own standup (down to 5-15 min) 2) the standup's facilitator now s…

> 2) the standup's facilitator now stops devs from going into too much detail, "you guys can discuss it further after the standup"

I said this in another comment, but a standup I'm part of tables these until the end of the call; and then anyone not involved in that conversation can drop off. It seems like a reasonable compromise to balance the need to get people together to discuss something against the need to not keep people tied up. It helps mitigate the issue of people not wanting to plan a meeting to just "talk about" something (when that's actually what is needed).

Re: Why Scrum is stressing you out

#417
post #120
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.

> It may be explicitly stated, but I’ve never had a scrum meeting without all managers and project managers. This, this, this and a thousand times this. It's always the same with Scrum. Every time you point out something clearly wrong, the response is always "well that's not really scrum, you're doing it wrong". It's like when discussing communism with some diehard fans - when you point out the flaws, the response is…

> Well to both of those camps I say: if most attempts ended up implementing it "incorrectly" in the end, it's not a very useful framework to begin with then, is it?

If your process to trim the hedges is much faster than normal, but also involves juggling chainsaws at the same time; it's possible your process is bad, because most people will fail to do it the way you've laid out.

(I'm agreeing with you, if that wasn't obvious... it's a pretty bad analogy, to be fair)

Re: Why Scrum is stressing you out

#418
post #120

Earlier quoted context omitted.

> It may be explicitly stated, but I’ve never had a scrum meeting without all managers and project managers. This, this, this and a thousand times this. It's always the same with Scrum. Every time you point out something clearly wrong, the response is always "well that's not really scrum, you're doing it wrong". It's like when discussing communism with some diehard fans - when you point out the flaws, the response is…

> It's always the same with Scrum. Every time you point out something clearly wrong, the response is always "well that's not really scrum, you're doing it wrong". Scrum is a victim of semantic drift. The vast majority of people "doing scrum" have never read the guide and are just doing things that other people have told them is Scrum. It's not Scrum's fault that people have hijacked its name for something completely…

> People using the wrong word for something doesn't mean the original definition of the word is invalid.

Yeah, it's literally the worse thing you can do. I mean, not for the original definition of literally, but the new definition of literally, which is literally not literally, and actually literally in the dictionary with the definition of "not literally".

Just saying, at some point, the definition everyone uses becomes _the_ definition. And yes, I'm not a fan either.

Re: Why Scrum is stressing you out

#419

Earlier quoted context omitted.

> Did communist utopians realize it doesn't work so now they're adding "post scarcity" to it to make it work? Did TV fanatics realize that Star Trek doesn't work? What does this even mean? Communism isn't something real, it is a work of science fiction that details an imagined world after post-scarcity. Always has been, probably always will be. Hell, even if we actually do reach post-scarcity some day, the chances of…

https://www.msn.com/en-us/news/world/cuba-said-to-reduce-bre... I suppose in your modern communism they'll blame the "AI".

Are you struggling to say that Cuba will blame AI for allowing the USA to beat them to their post-scarcity goals? Perhaps. American innovation is unquestionably leading the way to communism right now.

If communism ever is realized as more than science fiction, it will almost certainly be because of the USA's efforts. There is no chance Cuba will get us there. Of course, their official claim of seeking post-scarcity is only for pretend to keep up political appearances. The USA, in contrast, is actually trying. You might say ironically, but I'd say that Marx just got it wrong and that capitalism, not socialism, is the most likely path to communism.

Re: Why Scrum is stressing you out

#420

Earlier quoted context omitted.

Stories = Requirements Engineering Assigning Points = Roughly estimating how long it takes you to implement it Allocating Work = Well... allocating work Standups = Talking with your colleagues about the current work and clearing problems Reviews = Showing your results None of that seems unreasonable. The only thing that kinda sucks are the rigid sprints, because they just cause artificial stress by setting unnecessar…

They’re not unreasonable in themselves. What sucks is the process around them, because it impedes progress. Why because each tasks varies, and often it morphs while you’re working on it. So whenever a metric is fixed or something interrupts you repeatedly, it just sucks.

Or worse than impeding progress, everyone adjusts their expectations to only that which can comfortably fit into a sprint. Big gnarly bugs, meaty technical problems, or innovative solutions - too risky. Better just take a few random tickets off the board and keep plodding along.

The direct effect is organizations start systematically ignoring the forest and start obsessing over the trees, simply because trees are easier to measure. And then inevitably wondering aloud "why is velocity AND quality tanking?". Anyone with half a brain can see why - disincentivizing innovation destroys innovation.

Post reply on HN