Live data from Hacker News

Why Scrum is stressing you out

rethinkingsoftware.substack.com

181–190 of 462 posts

Re: Why Scrum is stressing you out

#181
post #53

Earlier quoted context omitted.

Good points, and eye-rolling stuff for teams thaqt don't understand the intricacies. For instance: - burn-down / velocity charts: Teams use this at standups to make sure their sprint isn't drifting. That's why a burn-down should be tracked in hours and not points. With points, the data isn't actionable in a reasonable amount of time. The the team sees a problem, they might make use of a pre-determined emergency proce…

> That's why a burn-down should be tracked in hours and not points. With points, the data isn't actionable in a reasonable amount of time. I don’t follow this? The arguments against estimates in hours are well known as this point.

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 meant to be an answer. It was just meant to kick off discovery. And that's a great way to start because humans tend to be exceptionally good at quickly comparing things for difficulty and complexity. It's an instinctive survival skill.

Ultimately, well after estimating this scrum team will do an implementation (tasking) plan in hours if needed during sprint planning. They will compare that plan against their team capacity plan in hours. If the implementation plan blows out the cap plan by say, 30% then that's a warning sign and they'll tell the PO they need to drop a story for the upcoming sprint. If the cap plan compared against the imp plan shows a 30% surplus, then they will pull in a stretch story and bump their velocity, or won't tell the PO and maybe go play golf at the end of the sprint.

So the story pointing exercise just gets the team some data that helps them get to the next day (survival speak). There's still a lot of story refinement to be done, before they will tell their PO a story is ready to be pulled into one of their sprints.

When teams pull in stories to their sprint backlog, the team is committing to get that story done, so they need immediately actionable data on what's going on at every standup. If the burndown was done in points, the graph ends up looking like a straight line for days with sudden dropoffs toward the end of the sprint - that hides problems. So a sharp team will use task hours instead. Makes the plot a lot more actionable from day to day.

Here's a popular presentation I do on estimating, and why we tend to misunderstand its usefulness. "How to do estimating while being chased by a rhinoceros:" https://github.com/jamesksmithiii/Presentations/blob/main/Th...

Also maybe useful: Drawings for what to cover in scrum ceremonies: https://github.com/jamesksmithiii/Presentations/blob/main/Ce...

Re: Why Scrum is stressing you out

#182

There are several flaws in this article's arguments, but the central one is easily revealed when you ask this question: why is there a big spike in stress for the "waterfall" project? The answer is that as the deadline nears, the team realizes that they have not made enough progress to meet the deadline. They must work longer hours, start cutting corners, and toss out features at the last minute. All of this is extre…

Why do you assume that its devs who are slacking in waterfall? Devs enjoy deving, usually there are either discoveries during execution or change of mind of client or pms figure out that their guestimation for year ahead was not exact. Surprise, surprise and who is going to have crunch time? Devs of course.

Re: Why Scrum is stressing you out

#183

Earlier quoted context omitted.

Be that as it may, if the scrum guide explicitly says they shouldn't then it isn't really fair to blame scrum for that. Honestly, the recurring complaints with scrum, agile, etc basically boil down to this: shitty organizations can make any system miserable. People generally are blaming the intermediate cause (how we do scrum sucks) rather than the root cause (our company sucks and nothing would work).

Oh, the good old "the user is doing it wrong, the product is fine" with scrum being the product. Can anybody (not PM/leader) give 1 example of a company where they saw scrum being done "correctly"? crickets I guess scrum is fine and people just don't know how to do it properly.

Man, I agree with your specific criticism of the "No True Scotsman" refrain and with the larger criticisms of scrum, but this is an example of scrum prescribing X and companies doing !X, the literal opposite.

How could scrum, the product, possibly be to blame for that even if it sucks? Or, at what point is it reasonable to blame the PM/leader for actively and knowingly practicing !$scrum while pretending it's $scrum?

Re: Why Scrum is stressing you out

#184

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…

Pizza sized teams that can directly interact with customers don't need management. Management is playing telephone with someone in the middle with their own interpretation of everything which is 99% wrong.

Re: Why Scrum is stressing you out

#185

Earlier quoted context omitted.

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…

Yep, it's typical Agile.

Scrum masters are needed to coach a new team with inexperienced project manager only. Established teams don't need them.

Stand-ups can be easily replaced by a team chat, such as Slack, with even better results.

I saw very few retrospective meetings too. If everything goes smoothly, then retrospective meetings are useless.

Re: Why Scrum is stressing you out

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

It doesn't make the original definition invalid, but words mean what society uses them to mean, which changes over time.

So agile & scrum do in fact today mean constant status meetings, treating professional developers as mindless cogs and keep everyone in line with a constant stream of tickets chosen by someone else.

Perhaps it's not what it meant in some idealistic manifesto lost to history, but it is what it means to developers employed in the industry today.

Re: Why Scrum is stressing you out

#187

Earlier quoted context omitted.

With software you have a situation with two problems. First is the "gap" between those doing the work, and those writing the checks. (When it's the same person, this problem disappears.) The guy editing the checks likes to understand progress is being made, and that the project both has an end and will be successfully completed. The second problem is that by it's nature software "never ends" and many (dare I say most…

This is really interesting. Do you know of any articles/blog post that goes into these ideas further?

No, alas no material to refer to, other than my own experiences at several places in the food chain.

At the moment I'm having fun developing again, but I have had experience of management as well.

Obviously my experience does not speak to all cases, and I'm fortunate that most middle managers I've dealt with are competant.

I am in the fortunate position of being able to "speak truth to power" though, and generally been able to dispassionate translate technobabble into managerspeak, and help all the layers understand each other better.

I've found that when both sides understand (as much as they able) the complex demands being encountered, more realistic expectations and demands are made (and usually achieved.)

But I've been lucky. I've had good dev teams, good middle management, and good product owners. Who have all been pulling together to make projects successful. When one group is pulling the other way, things get tougher.

Re: Why Scrum is stressing you out

#188
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…

I have seen teams actually do the Scrum-according-to-the-textbook, but those are rare. Most companies are just doing whatever their managers think is a good idea, and they call it "Scrum".

Ironically, the last time my team was doing Scrum-according-to-the-textbook, it was a decision of the developers... and then the higher management told us to stop, because the entire company decided to switch to "Scrum" (as in: endless meetings with managers present, no retrospective, but we call it "Scrum" because it sounds like we know what we are doing), so basically we had to abandon Scrum in the name of "Scrum".

My conclusion from this experience is that Scrum-according-to-the-textbook never happens as a top-down decision. The managers have strong ideas about how things are supposed to work, and they are unwilling to change their ideas, although they may agree to rename them to "Scrum".

I actually get the real-communism-has-never-been-tried vibe from people who say "scrum sucks, agile is the good idea". Scrum is simply what happens when Agile meets corporate reality. Make "agile" a popular buzzword among the managers... and soon you will see people complaining that agile in practice means endless meetings etc.

Re: Why Scrum is stressing you out

#189

Earlier quoted context omitted.

> That's why a burn-down should be tracked in hours and not points. With points, the data isn't actionable in a reasonable amount of time. I don’t follow this? The arguments against estimates in hours are well known as this point.

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.

Re: Why Scrum is stressing you out

#190
post #163

Earlier quoted context omitted.

And by "devs having to be agile" you mean "devs having to be interruptible during managers hours and flexible in doing their work after all the bs office hours are over".

exactly ... i mean even without hindsight "agile" is a rather poor choice as the label. it just evokes the wrong ideas too easily.

it's not poor, it's clever. that marketing is what made agile the dominant paradigm nowadays. remember agile was adopted in entreprise despite IBM pushing RUP
Post reply on HN