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

141–150 of 462 posts

Re: Why Scrum is stressing you out

#141

Post by gklitz »

Aeolun wrote: post #87
benfortuna wrote: post #42

Earlier quoted context omitted.

But what does it mean to "empower devs". Do you give them requirements and say I'll check in on deadline day in 6 months? Presumably you would still use iterations to track progress, Epics/Features to break down requirements, some kind of estimation to track if you're ahead/behind schedule? I certainly wouldn't go back to Waterfall days, but I suspect many current devs never experienced that.

You can have a two week cadence without connecting tasks to sprints.

I’m confused. That is literally all sprints are a regular cadence that tasks and events are connected to?

Re: Why Scrum is stressing you out

#142

Post by senko »

oneshtein wrote: post #122
kkfx wrote: 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.

If a factory is producing N widgets, every widget is the same. If a software teams are producing deliverables, each is different.

Kanban (originally) is an method of sending purchase orders (ie requests to make widgets of specific type in some quantity) from the team(s) who need them to the teams who make them.

In software, quantity is always 1 and while the “widgets” have notionally been designed (specced out in the ticket), they have never been built before, unlike in the factory where every widget at least had a test run before.

That is, Kanban in software development is a cargo cult from Toyota in which an essential difference (time to reconfigure the assembly line for another widget, vs time to design, prototype and test the widget) has been lost.

And it STILL works better than Scrum.

Re: Why Scrum is stressing you out

#143

Post by Leherenn »

jghn wrote: post #103
rpcope1 wrote: post #49

Earlier quoted context omitted.

As a developer, I find retros most useful when EMs (and probably PMs, depends on how things are configured organizationally) aren't present, as it should give a chance to talk freely about challenges you or the team face, which often are organizational in nature and may involve one's management chain. My current role doesn't adhere to this, and it makes retro often really painful.

I would agree with you. I never want my manager there. As an EM, I never want to be there. And yet, as the years go by, when I have an EM role I find my presence is requested. Again, who knew?

I don't know, at least for my current team a lot of the stuff we complain about in the retro is beyond the team level: coordination between teams, infrastructure issues, ... The intra team issues are usually talked about before (e.g. during standup, or just asynchronously).

If the EM is not there, those are not actionable. What we try to do is: do the retro by ourselves, and invite the EM at the end of there is stuff for them. Usually they are not available though...

Re: Why Scrum is stressing you out

#144

Post by usea »

rolisz wrote: post #123
twunde wrote: post #31

Earlier quoted context omitted.

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)

I interviewed at a place whose sprint planning took a full week and was reportedly incredibly stressful. Customers participated. Their product was a website that agile teams used to track their process.

Re: Why Scrum is stressing you out

#145

Post by oneshtein »

senko wrote: post #142
oneshtein wrote: post #122

Earlier quoted context omitted.

Continuous delivery IS mass production.

If a factory is producing N widgets, every widget is the same. If a software teams are producing deliverables, each is different. Kanban (originally) is an method of sending purchase orders (ie requests to make widgets of specific type in some quantity) from the team(s) who need them to the teams who make them. In software, quantity is always 1 and while the “widgets” have notionally been designed (specced out in the…

Kanban was invented for Just-In-Time factories, where each product item is customized to meet demand, so fewer things can be predicted in advance, thus making Waterfall unsuitable. Kanban allows to achieve both the flexibility of customization and cost effectiveness of mass production.

In software development, incoming requests are broken down into small manageable tasks, which are familiar enough for developers to estimate reliably. Then this continuous stream of small tickets is executed continuously (Kanban) or in sprints (SCRUM).

For example, request to add feature X can be broken down into «Make UI for feature X» and «Make backend for feature X». If they are still large, they can be broken further, for example «Make a CRUD for feature X.y», «Make a SQL table for X.y with migration script», and so on.

Re: Why Scrum is stressing you out

#146

Post by cassianoleal »

ern wrote: post #115
luckydata wrote: post #30

nobody has ever done "waterfall", it's a strawman created to explain why traditional project management doesn't work in software development. The fact that the article starts with "in the good old days of waterfall" takes away every expectation that I'll read anything intelligent in the article, I believe this post doesn't deserve your time and definitely doesn't deserve mine.

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 generations" kept using it.

This is making observations, coming up with a model that fits the observations, giving it a name, and arguing against it.

This is definitely not a strawman as GP or the author of the post you linked seem to think, which is why it's being downvoted (I didn't btw).

Re: Why Scrum is stressing you out

#147

Post by senko »

oneshtein wrote: post #145
senko wrote: post #142

Earlier quoted context omitted.

If a factory is producing N widgets, every widget is the same. If a software teams are producing deliverables, each is different. Kanban (originally) is an method of sending purchase orders (ie requests to make widgets of specific type in some quantity) from the team(s) who need them to the teams who make them. In software, quantity is always 1 and while the “widgets” have notionally been designed (specced out in the…

Kanban was invented for Just-In-Time factories, where each product item is customized to meet demand, so fewer things can be predicted in advance, thus making Waterfall unsuitable. Kanban allows to achieve both the flexibility of customization and cost effectiveness of mass production. In software development, incoming requests are broken down into small manageable tasks, which are familiar enough for developers to e…

> each product item is customized to meet demand

No, each product run is customized. Products are already known and fixed (they have been built before, with the same specs), the demand is unknown (in advance). There is a subtle difference between this and your “make CRUD for xyz”, where XYZ is always something different (if it wasn’t, we’d just reuse the thing we wrote the last time).

I would encourage everyone to read a book about TPS (The Toyota Way is a good one), and compare/contrast that with Kanban as an agile software methodology.

Re: Why Scrum is stressing you out

#148

Post by magicalhippo »

oneshtein wrote: post #108
magicalhippo wrote: post #29

Earlier quoted context omitted.

We don't do scrum. We release major versions once a month, and bugfixes daily. New features go into the next major version when done, bugfixes gets released as soon as they're done. We use Kanban boards to get an overview and prioritize work. Apart from that devs mostly manage their own work. We're a small shop though, perhaps that's why it works well.

Looks like SCRUM.

But is it? Everything is the same if you squint hard enough.

We do not have anything like a SCRUM master.

We don't do stand-ups, we usually don't have a per-release target for features. For example, for the past three months I've had a target of October 1st for a feature, but no specific sub-deliverables for the realeases before that. This is typical.

We don't have a separate sprint retrospective meeting. We discuss such things during our weekly meeting, even between releases (ie we don't wait).

It doesn't feel like what I've been taught and have read about SCRUM. But sure I'll agree it's closer to SCRUM than to the waterfall method.

Re: Why Scrum is stressing you out

#149

Post by carlmr »

roenxi wrote: post #135
lpapez wrote: 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…

That similarity is superficial. It is observing that no ideology perfectly survives implementation - which is true, but there is no alternative option so it isn't a useful observation. We don't have any successful countries that use communist ideologies because central planning is destructive and the abolishment of private property is catastrophic. Calling for communism is tantamount to wishing for death and destruct…

>So scrum as an ideology seems to be net-successful even if implemented wrong.

How do you get to this conclusion? I haven't seen any implementation of scrum that didn't slow down development speed, due to unnecessary meetings and micromanagement.

This might be that I've only seen 8 or so "implementations". If there's any evidence that scrum is a key net positive I'd like to see it at this point.

Kanban IME can work well if the manager understood the core principle: Limit amount of concurrent work, use daily standup to prioritize work and unblock people hitting the multitasking limit.

Sadly this concept which is the core tenet of Kanban and can be explained in one sentence was still too much to grasp for some managers, but I've at least seen most Kanban implementations be either a net positive, or neutral.

I might be biased by my own experience, but I still need to see a Scrum implementation that doesn't grind productivity to a halt.

Re: Why Scrum is stressing you out

#150

Post by mrsaint »

When challenged why we'd scrum since we were doing better as a whole before (better products, happier devs), mgt replies that they'd need scrum to detail the work we did so that they could write longer bills to the clients.
Post reply on HN