Live data from Hacker News

Why Scrum is stressing you out

rethinkingsoftware.substack.com

441–450 of 462 posts

Re: Why Scrum is stressing you out

#441
post #90

Earlier quoted context omitted.

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

Hmm, while I get what you are saying, I feel like dealing with that is _literally_ their job.

It'd be nice if we could remove stress from leadership, but I don't think that's a thing that should be my responsibility as a dev. Of course it'd actually improve the life of everyone if did, so it feel like something you should do regardless.

But then I'm taking the managers job in addition to being the developer, and then what's the point of the manager in the first place?

Re: Why Scrum is stressing you out

#442
post #141
post #87

Earlier quoted context omitted.

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?

You can have a demo of 'current state' every two weeks, and leave off the 'we didn't finish everything we planned for these two weeks' part.

Re: Why Scrum is stressing you out

#443

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.

There isn't anything here about having to do daily standups: https://agilemanifesto.org https://agilemanifesto.org/principles.html It's common in corporate implementations of Agile (tm) but it isn't actually some commandment or prescribed feature of Agile itself. It's actually prescribed by Scrum: https://scrumguides.org/scrum-guide.html#daily-scrum

It's been a long time since I last read it, and it's interesting how times changed.

On daily standups, from he manifesto:

> Business people and developers must work together daily throughout the project.

> The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

The "standup" theatrical part isn't in it, but that begs for daily meetings in the same physical place really.

Also...no. Verbal communication isn't effective or efficient. It's fast and natural, and perhaps comfortable to many.

In our current corporate environment, effectiveness (providing the right info in the right form) and efficiency (minimizing back and forth) will probably be better achieved with documents and open chat with all the parties involved, even if (in particular if?) it means slower throughput and more deliberate communication.

Re: Why Scrum is stressing you out

#444
Ill say that for me and my team, implementing SCRUM has worked well and overall reduced stress.

We have a lot of control about what we pull in and the issues in out backlog, and if we need to designate prep work, we put it in as a spike.

The only time i really have work stress is when we have to many interrupts, but SCRUM has a process for buffering for that and I find that very effective for telling the story when that happens.

So it sounds like I am a SCRUM fan, and I am, but i would def be open to hear about other systems that teams use who have tried SCRUM and prefer their new solution.

Re: Why Scrum is stressing you out

#445

Earlier quoted context omitted.

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

So I think one thing that seems to pop up in people’s anecdotes is “well someone wanted to just talk about what they did yesterday.” Which I suspect comes from the manager/PM going “so what’d you do yesterday?” I’ve been taught, and I teach others, that in the standup you drive the questions. Usually along this framework: 1) I assigned you Task A yesterday. Did you finish Task A? 2) If yes, awesome. I have Task B for…

> If you’re going to treat the software development like a factory, you must assign and manage work like a factory.

What you described above is more like kindergarten, which is why any sufficiently seasoned developer hates Scrum with all the passion they have. It is mostly belittling, humiliating, and not even very productive at the end.

Interestingly, Scrum almost always ends up like being in the kindergarten, instead of addressing the real pain points, as it should be (eg. involve the business in the development process). But that takes real effort, which is hard, and therefore no PM or manager is interested in.

Re: Why Scrum is stressing you out

#446

Earlier quoted context omitted.

You need to break work up into tasks that take less than two weeks. Beyond that, you’re metagaming and that is going to end up either not being worth the energy invested or a net negative. I say energy not time because there are only so many niggling arguments you can have with coworkers before they push you into traffic. Each petty little argument that could have been about something more important just runs down th…

I disagree as when you have a team of 8 people understanding whether something is one day of work or 10 is a big difference. I don’t think you need precise estimation down to the hour, but knowing if someone can do 4 things in a sprint or just 1 is really important because people have interdependencies. I don’t think I’ve ever had arguments about estimates and it’s usually a really quick exercise of “I think this is…

> understanding whether something is one day of work or 10 is a big difference.

A big difference for what?

Re: Why Scrum is stressing you out

#447
post #423
post #392

Earlier quoted context omitted.

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…

There is very little chance that what you are working on has never been done before. Most likely, you are writing simple code to do simple things. These things can be broken down into simple tasks, and these simple tasks can be estimated. Unless you are working on ChatGPT-6, i assure you, you can definitely estimate how long things will take. your estimates will not be perfect, but they will be good approximations fo…

Code is infinitely copyable. If it has been done before it can just be copied, hence the time it takes is 0. If it takes more than 0 then what you are doing is actually something else entirely, like gluing said code to something else for the first time.

If it is not the first time, then you already have the code and hence the time it takes is 0.

There are cases where code is similar to code you've written before or you cannot just copy the old one due to licensing constraints. In this case estimation is easy, somewhere between an hour to a day or two.

Anything larger can be broken down to hour to day or two chunks since it has been done before.

All great, except this last case simply doesn't exist for the type of work that I do. And that is true for many people, software is extremely unpredictable because the stuff you need to build on top of might as well be quicksand.

Re: Why Scrum is stressing you out

#448
post #445

Earlier quoted context omitted.

So I think one thing that seems to pop up in people’s anecdotes is “well someone wanted to just talk about what they did yesterday.” Which I suspect comes from the manager/PM going “so what’d you do yesterday?” I’ve been taught, and I teach others, that in the standup you drive the questions. Usually along this framework: 1) I assigned you Task A yesterday. Did you finish Task A? 2) If yes, awesome. I have Task B for…

> If you’re going to treat the software development like a factory, you must assign and manage work like a factory. What you described above is more like kindergarten, which is why any sufficiently seasoned developer hates Scrum with all the passion they have. It is mostly belittling, humiliating, and not even very productive at the end. Interestingly, Scrum almost always ends up like being in the kindergarten, inste…

>What you described above is more like kindergarten

You ever try organizing and managing the work of multiple skilled tradesmen that feed into a single integrated product on tight deadlines? Do you know what works really well in that kind of environment?

Telling people what to do and then checking in on them to see if they’re doing well.

Is this kindergarten? I don’t remember being a skilled tradesmen working on building components for complex assemblies on tight deadlines in Kindergarten.

I concede that I am unfamiliar with what a normal “scrum” session looks like outside of what is said in the Agile manifesto and the many anecdotes floating around. I do know that Scrum took a lot of cues from TPS/Lean of the 80s and tried to feed it to Software.

And as far as I can see, it’s not working because the profession and the products do not fit this factory model.

What everyone seems to yearn for seems to match more closely to the model followed by magazines and other such publications. Product Management the profession mirrors more the Editor than the Production Manager, SWEs mirror writers/editors-at-large, etc.

Self respecting writers in any newsroom would balk at being subjected to daily scrums that take away from precious research/writing time. And to put some kind of regular pace on progress, metrics, etc. to what really is very bursty, deep focus work is also ridiculous. Whether it takes you 5 hours or 5 days to write the piece, so long as it is of quality and meets the deadline what does it matter. And even if you miss the deadline, you could alway be slotted into the next issue unless the piece was a cornerstone piece to the issue, in which case a good editor would have assigned it with ample time or given it to the best writer on the roster.

Hell I like this analogy. Might spend more time thinking about it and talking to SWE friends about it. Feel free to expand. Maybe this will free everyone from the shackles of Scrum.

Re: Why Scrum is stressing you out

#449
Having read Sapolsky’s stuff (firm recommendation for ‘Why Zebras Don’t Get Ulcers’), I’m under the impression that trying to eliminate chronic stress is of paramount importance for one’s health.

Nowadays I’m an entrepreneur which isn’t stress free, but I feel like the bouts are more acute and chronically I feel quite liberated due to having control over everything.

I know this will vary by person. Some would dread having so many moving parts in their life, but I always found being bossed around to be the most draining part of work.

Re: Why Scrum is stressing you out

#450
post #229
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…

There are a lot of things better than scrum, but mostly these are all wrong ways to implement it. Daily: should average at 10 min, 15 min is really the maximum. Including prep. So 5-15 min. No status updates! The daily is about getting people unstuck with their current tasks and quickly aligning on what to do next. If it is not useful for the team, the implementation is wrong. Doesn't mean it always has to be useful…

> The daily is about getting people unstuck with their current tasks

This I don't understand. Why do people need a daily to "get unstuck"? Are they not talking to each other? If I have a problem, I can proactively work on it, and contact whoever necessary. Unless you are very junior, this should not be a problem.

Post reply on HN