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

391–400 of 462 posts

Re: Why Scrum is stressing you out

#391

Post by rerdavies »

marcosdumay wrote: post #254
Lutger wrote: post #229

Earlier quoted context omitted.

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 ages old "you are doing Agile wrong". When nobody manages to do the thing right, then the thing isn't good. It doesn't matter what platonic ideal you hold for it.

But people DO do the thing right. As a loose guideline, I think you can reasonably infer that anyone who is telling "you are doing Agile wrong" has first-hand experience with an agile process that is working reasonably well. So take that as a starting point.

And the reason they are telling you that: because an agile process that is working well is like night and day to all the crazy processes that preceded it. When it works, it is amazing!

Re: Why Scrum is stressing you out

#392

Post by socksy »

prepend wrote: post #356
pyrale wrote: post #308

Earlier quoted context omitted.

> I had a conversation with a young devTM who was arguing that estimating is hard and always inaccurate so we shouldn’t estimate. Plenty of learned people have made defenses for having no estimates. If you want to make the opposite claim, you don't need to use a junior dev as a strawman.

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-shirt sizing of S, M and L. Anything beyond that, say, comparing two projects to be able to prioritize and see the opportunity cost etc etc is a fool's errand.

From The Black Swan by Nassim Taleb:

[Critics say that] the maps we had were better than having no maps. [...] This is the strangest of errors.

I know few people who would board a plane heading for La Guardia airport in New York City with a pilot who was using a map of Atlanta’s airport “because there is nothing else.”

Re: Why Scrum is stressing you out

#393

Post by scotty79 »

wild_egg wrote: post #39
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…

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

Right. So in one team I worked in, the team leader had to take notes during stand-ups of what everyone is doing to deliver them to managers so they can browse at their leisure.

Re: Why Scrum is stressing you out

#394

Post by hinkley »

Pet_Ant wrote: post #294
replwoacause wrote: post #257

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…

It’s an opportunity to call out things four business hours after they happened. We have Slack now. Or Teams. If you’re stuck, tell people. Don’t wait until tomorrow morning.

Re: Why Scrum is stressing you out

#395

Post by hinkley »

prepend wrote: post #356
pyrale wrote: post #308

Earlier quoted context omitted.

> I had a conversation with a young devTM who was arguing that estimating is hard and always inaccurate so we shouldn’t estimate. Plenty of learned people have made defenses for having no estimates. If you want to make the opposite claim, you don't need to use a junior dev as a strawman.

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.

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

Re: Why Scrum is stressing you out

#396

Post by rerdavies »

dartos wrote: post #230
LeFantome wrote: post #18

Earlier quoted context omitted.

What in Scrum is about keeping managers happy?

Burn down charts, team velocity, and story points. They all exist to give software development the illusion of predictability, but saying that a project should take “x sprints” is just setting a deadline with extra steps.

Right. So you don't do that. No development process ever has provided bulletproof predictability. Your job as a project manager is not to provide bullet-proof predictions; it's to manage risk, and expectations, and make sure that development work is correctly prioritized. And of course to keep your development team protected from external insanity, because happy, stress free development teams are productive development teams. (But that's a separate issue).

Here's the feature list; here is where on the list we'll definitely get to, here's where on the list we definitely won't get to, and everything else is some shade of inbetween. Now, would you like to adjust the priorities of any of those features, or would you like to change the deadline?

Re: Why Scrum is stressing you out

#397

Post by rerdavies »

PaulHoule wrote: post #241
dartos wrote: post #230

Earlier quoted context omitted.

Burn down charts, team velocity, and story points. They all exist to give software development the illusion of predictability, but saying that a project should take “x sprints” is just setting a deadline with extra steps.

There is nothing wrong with burndown charts but story points and team velocity are poison. The way you get good at estimating is looking at your database of experience. “I did a task similar to this in 8 days”. Calendar time is real and punchclock time is real, either can be measured. Story points are not real and not measurable and they leave you lost at sea thinking that estimation is impossible, a scam, etc. See a…

Agreed. Team velocity is a poison number. But entirely necessary in order to provide a data-driven approach to converting story points into time predictions (with appropriate disclaimer of risk) that people outside the team need. Data driven! How could that possibly be a bad thing?

Maybe best to just treat it as a classified secret that nobody actually needs to know. People inside the team just need to know that their stories are arranged in correct order of priority. People outside the team actually do need time axes on their burndown chart. But they don't need to actually know the toxic voodoo that was performed to produce the conversion.

:-P

But actually seriously. Nobody needs to know that number.

Re: Why Scrum is stressing you out

#399

Post by knallfrosch »

siva7 wrote: post #131
bamboozled wrote: post #70

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…

The sprint goal is a team target. If you're sick that shouldn't endanger the sprint goal because anyone in the team can pick up any work. Of course in mediocre or low-performing teams that's almost never the case but still not the fault of a product framework

If you planned correctly and then have an unforeseen sickness, you'll miss the goal. That's independent of any framework.

Re: Why Scrum is stressing you out

#400

Post by aidenn0 »

tcgv wrote: post #348

A lot of the criticism here comes from people who had bad experiences with poor managers, leading them to reject the idea of work processes altogether. The few defending Scrum are doing so based on positive experiences with great teams and strong leadership. In my view, high-performance teams don’t just appear by "hiring good people and letting them do their thing." Good people naturally communicate, take initiative,…

I think the issue with formal processes is that, while they are created to serve a goal, they very quickly become the goal.

When everybody in a room agrees that deviating from the process will improve the chances of success, but nobody in the room is empowered to approve the deviation, morale will drop quickly.

Post reply on HN