Live data from Hacker News

Why Scrum is stressing you out

rethinkingsoftware.substack.com

301–310 of 462 posts

Re: Why Scrum is stressing you out

#301
post #132

This guy has clearly never worked waterfall, the progress bar doesn't look at all like in the graph. Instead, there are even more milestones throughout the project. Granted, they are usually spread out further than every 2 weeks, there is no such thing as just one final deadline where you can slack the first half of the project. Month 1: Specifications need to be frozen, because month 2 all the test plans need to wri…

> This guy has clearly never worked waterfall, the progress bar doesn't look at all like in the graph. Instead, there are even more milestones throughout the project. Granted, they are usually spread out further than every 2 weeks, there is no such thing as just one final deadline where you can slack the first half of the project.

You are misreading the graph and then taking your own bad reading and projecting uncharitably on the author. Nowhere did he say that you can slack the first half of the project. Also, I know the author and I know that he has worked waterfall, so your conclusion isn't even accidentally correct.

Look at the Y-axis. It's measuring stress, not effort/work/slack/etc.

Also, the graph itself refutes your conclusion that it is representing only one single "milestone." Notice the graph falls after achieving the milestone, and then begins again. It's a continuous cycle.

Re: Why Scrum is stressing you out

#302

Earlier quoted context omitted.

Sure, comes from a prevailing view that estimating is bad. But it's only because estimating is treated like the answer, then we just go with that answer. The best scrum teams I've worked with maintain a very important survival notion: We don't know the full minimum survivable solution today, but that's ok because we do know enough to get to tomorrow at least. We survived another day. Point is, estimating was never me…

No, the prevailing view is estimating in hours is bad, hence the push for estimating in t-shirt sizes or other stand-ins for task complexity. The survival terminology is really off-putting. And what’s the obsession with golf? This doesn’t sound like any scrum team I’ve worked with or would want to be a part of.

Well, a rather xor response, but that's ok. Let's go a different route: Someone is using a diet change (fixed), and the elliptical machine to lose weight. This person has no exercise background. The elliptical routine is basic - same program, one hour a day, 8 weeks. BF test is done at the end of each week. Graph the results. What do you think the plot will look like? Why did the subject's weight loss stall out?

Estimations are meant to be exactly that, estimations. Don't try to make them anything else. They offer a grey answer, so use the best tools you have to deliver that grey answer. In this case, it's simply comparing challenges for size, complexity, etc. Don't try to do estimations in a different way just because you want an immediate answer. Estimations are meant to be a starting point to get to a minimum survivable solution. That's how humans use instinctive tools that use the least amount of energy to get to a point that they can survive a challenge. Think about the elliptical example.

In scrum, estimations are the conscious way to get this discovery kicked off; they aren't meant to be an answer, because you don't have enough data yet for a solution. They are meant to be a starting point. Iterate to the solution. When you think you have enough signal for a solution (the sprint), do your final check and balance, which is a tasking plan in hours, during sprint planning.

Another example: The year is 1929, and you're asked to guess the weight of the Empire State Bldg before construction has even begun (1931). What answer delivers more survival information? 180,000 tons, or this: "Well, we know each floor is going to have x concrete, y steel, but not sure about the other construction materials. So it will be something like (x+y+?)*#floors. If your life depended on it, which answer would you go with?

You are looking for a number, and that's why people don't understand what estimating is about. The incorrect approach is like, "Well these estimations are crap, so let's change the estimation methodology." Yeah but it's still and estimation, and you already have a great instinctive tool to make those estimations via relative size comparison, which can be done so quickly, it could literally save your life. Instinctively, we accept that, conscoiusly we don't, so we turn into ill tempered Veruca Salt.

Regarding the golf reference, I'm from Florida. Sorry if the attempt at levity was weak.

Re: Why Scrum is stressing you out

#303

Earlier quoted context omitted.

In my experience, waterfall forces business to think more about the project and plan accordingly. They have to think about how this feature interacts with this other feature. Business also usually has a better understanding of how the software will work because of the planning phase. In my experience, with 2 week sprints, the business doesn't really have to think about anything outside of bite sized chunks or even ho…

> No sense of accomplishment, no letup, working hard just gets you more work. It's like laying bricks one at a time on a wall with unlimited length. Also feeling bad every 2 weeks because planning was really bad and now you need to say you're sorry the task has to roll over the next sprint and your manager has to explain to their manager, etc, etc.

Yep. Somehow scrum leads to more rigid specifications than waterfall.

Re: Why Scrum is stressing you out

#304

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…

It seems we go astray when we start defining and evangelizing things that may have worked for some group of people to push them on others.

Somewhere in all this process stuff, I see maybe what some teams were doing but I doubt it was as rigid and I doubt they indulged in it when it made no sense. Once these teams or people are asked what they're doing right - it eventually gets defined into rules and then evangelized to people made to feel they can't deviate or improvise when the framework makes no sense. "Trust the process."

So people start wasting their time going through the process rather than using the process as a framework/tool for getting things done, they 'do' the process.

Their job is standup, their job is scrum, tickets, and points, and as a result their job is only marginally to do the things that need doing.

Company's might take more issue with this inefficiency if the workforce didn't double as something to manipulate pre and post head/tailwind to make the stock rise.

Re: Why Scrum is stressing you out

#305

Daily standups are horrendous. I don't know how people put up with that level of time wastage and micromanagement.

I didn't mind our daily standups at the last place. They were usually short (10-15) mins. It was all the bullshit and developer grovelling at the end of the sprint, and the lack of allocated time to actually plan future work, that was the problem. I saw people time and time again cutting corners to meet their imaginary deadlines. I'd get sent PR's to review after hours by people in different teams the day before scrum deadlines. It was insane.

The standups themselves were fine and actually I thought they were pretty helpful, especially during covid times.

Re: Why Scrum is stressing you out

#306
post #262
post #40

Unfortunately, we aren't understanding the intricacies of high-performance. I've worked with maybe 150 scrum teams. 99% were mediocre. Remaining 1% understood energy usage, how to limit what they took into a sprint backlog, and how to manage their capacity. When I asked a manager about a particular team, he said "I don't care if they do fight club in the morning, just let them keep doing what they're doing." To refra…

I wonder if this team could have choosen any framework and it would have worked, they just happened to use scrum. With the founder mode discussions recently there was this saying akin to "a successful process is a result of talented people" and not the other way around. It stuck in my head and I feel this is an instance of that. Although you definitely can force a process on a talented team and have their productivit…

Agree. It's just that well understood scrum is a great process for delivering certainty and stability, as proven by lots of teams (provided they did scrum correctly).Just saves energy to thoroughly vet the process before tossing it.

But first principle, this is a physics issue: Whatever way a team comes up with to maximize the amount of work not done to deliver the same or better outcomes, I'm all for it.

Re: Why Scrum is stressing you out

#307

I feel like in a lot places the ultimate purpose of sprints is to let executives think they can see data that represents the amount of work getting done down to a fine level.

Exactly right. I've seen it first-hand. It's all about the data. It's also neatly separated from the real operating context in a way that presents it as highly misleading.

Incidentally, if you criticize the data (such as asking "Where does this data show the effort that people who spent time mentoring/pairing but didn't do the actual 'commit'? Where does the data show the effort spent code reviewing?), you should know that it won't be received well. The emperor really does not want to hear that he's not wearing clothes.

Re: Why Scrum is stressing you out

#308

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.

I find Agile is like democracy. It does suck, but it’s better than everything else. What would you prefer besides agile? I had a conversation with a young devTM who was arguing that estimating is hard and always inaccurate so we shouldn’t estimate. Everyone should just work on things until they are done. He argued this earnestly and didn’t recognize that there are opportunity costs and conflicting priorities and the…

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

Re: Why Scrum is stressing you out

#309
post #76

While I think the part about neglecting support became true at my org, I didn't forget how awesome E V E R Y O N E felt about Scrum when we started. It lasted for 1-2 years. All the devs and everyone loved it. So... then why? Because it brought a kind of order to the game. Story points worked. They became boring so the teams started to twist them. I think Scrum loses its advantage when people get bored - like with an…

I remember that as well, but I think scrum lost it's advantage once it was co-opted as a metrics and management tool, and by people looking to make a career out of "managing." That's the point at which it started shifting to being imposed on the team rather than offered as a tool to the team.

Re: Why Scrum is stressing you out

#310
post #238

Back when Scrum was new I already wondered how it could make sense to make developers be constantly sprinting. I mean it's right there in the word choice. You can't sprint all the time! A sprint is short and fast and then you rest. Making everything in work life be only sprints is madness.

You rest at all the meetings.

I hope this comment is sarcastic. Nothing is more exhausting than having to hear people that have no clue about anything, i.e. managers, speak.
Post reply on HN