Live data from Hacker News

Why Scrum is stressing you out

rethinkingsoftware.substack.com

451–460 of 462 posts

Re: Why Scrum is stressing you out

#451
Scrum can be stressful but as the graph rightly shows peak stress for Waterfall is way higher. I've been working more than a decade with Scrum. Every time I don't it shows, lower productivity, even higher stress, bogus tasks. If people want to do Waterfall fine, but then please also have proper project management with Gantt charts. Otherwise it's just Cowboy development

Re: Why Scrum is stressing you out

#452
post #374

Scrum is useless. it's just another method of demanding results. Where there isn't anything to tell, you shouldn't be forced to do so. All this imbecility does is to create competition, and weed out the ones that don't comply. I've worked in teams where we were forced to have something to report even when nothing was to report. This made the team create "things" to match their daily scrums, because the truth might ge…

> All this imbecility does is to create competition, and weed out the ones that don't comply. This ten million times. It's about control, and it's about showing you that the only way to be considered to be doing your job, is if you abandon all dignity, and allow yourself to be treated as a child. The adults (POs and managerial folk) are making your planning, your regime, you constantly report to them them what you ar…

[dead]

Re: Why Scrum is stressing you out

#453
post #186

Earlier quoted context omitted.

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

Scrum (or agile) done wrong is a unimaginable nightmare (I actually do have first-hand experience with that). But, overwhelmingly, my experience with scrum has been nothing but sweetness and light. When it is done right, all the stress melts away. Seriously. Just an absolute joy. Are those who have toxic experiences with scrum actually a majority, or are they just a vocal minority? I'm curious if there's any data on…

> Scrum (or agile) done wrong is a unimaginable nightmare

I agree. The issue is that I have literally never seen it done "right". It doesn't practically matter what agile is theoretically supposed to be, it matters what it actually is.

Re: Why Scrum is stressing you out

#454
post #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.

Sounds like you mix up management with product people.

Product people are not management at least not where I worked.

I see how it might be a problem if your manager is talking to the customers.

Product people are or should be equal to dev, engineering. They should indicate priorities but should not in any way evaluate engineers especially if they have no technical expertise.

Re: Why Scrum is stressing you out

#455
post #446

Earlier quoted context omitted.

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?

For any tasks that depend on it. If I need you to do something and I can’t start until you’re done, it’s useful to know if you think you’ll be done tomorrow or next week. That lets me plan my upcoming days.

Re: Why Scrum is stressing you out

#456
This is a problem.

I don't mean Scrum, I mean that people believe the this is Scrum.

Sprints DO have a break. The morning of the first day is just about figuring out what threat will look like. The afternoon of the last day is everyone talking about what they did during the Sprint. That is a full day of doing no coding and just talking with each other about the work. Every two weeks. If someone is forcing you to work in different way, then that's not Scrum.

The dev team is supposed to be encouraged by the scrum master to only take on the work that they can finish during the upcoming Sprint. If they take on too much work the answer is not to insist that they finish it but to ask what they need to understand better about their work. If someone is insisting that the Sprint backlog absolutely must be finished every Sprint, they aren't doing Scrum. As a corollary I hope no one is trying to insist that you do a release that coincides with the Sprint schedule. That's not scrum either.

Scrum is based on principles developed in the Toyota way. There are two pillars in the Toyota way, continuous improvement and respect for people. I'm sorry it sounds like you not lived with either of those pillars. I hope you find a scrum master who understands and can encourage this type of development.

By the way, I am a scrum master myself and this is how I treat my teams. I choose to trust them every time. And I encourage them to make good healthy decisions for themselves.

Re: Why Scrum is stressing you out

#458
post #446

Earlier quoted context omitted.

> understanding whether something is one day of work or 10 is a big difference. A big difference for what?

For any tasks that depend on it. If I need you to do something and I can’t start until you’re done, it’s useful to know if you think you’ll be done tomorrow or next week. That lets me plan my upcoming days.

Would you feel it fair, when you require an estimate, to have to say what decision you'll make with it?

Usually, when someone insists on getting estimates, that's my way to make sure that they really need it. besides, it also helps making an estimate that won't be useless in the context of the decision to be made.

The lesson I learned from asking that is 1) many people ask for estimates without a clue about what they'll do with the info, and 2) when a decision actually needs to be made, the actual question is never "will it take 1 or 10 days", but rather "will that project be done by regulatory limit", or "will it cost 50k or 5 millions". And for the 2nd point, sizing every small task and adding up usually compounds uncertainty in unpredictable ways.

Re: Why Scrum is stressing you out

#459
post #209

Earlier quoted context omitted.

>two parental figures (the PO and Scrum master) Another great point. The overhead is insane. 2 people that don't directly contribute work output per team.

Could it possible be that.... you're not doing it right. lol It is another great point. But it is another great point about how the process in your organization could be improved. Nothing says you have to have two parental figures. And why on earth would you have a dedicated scrum master?! It's just not a job that should be requiring that much labor. Just have one part-time scrum master in the entire company who peri…

> And why on earth would you have a dedicated scrum master?! It's just not a job that should be requiring that much labor.

At most places I worked, having a dedicated Scrum Master on the project was the norm.

Yet another case of "it's not Scrum's fault everyone is doing it wrong".

Re: Why Scrum is stressing you out

#460
post #458

Earlier quoted context omitted.

For any tasks that depend on it. If I need you to do something and I can’t start until you’re done, it’s useful to know if you think you’ll be done tomorrow or next week. That lets me plan my upcoming days.

Would you feel it fair, when you require an estimate, to have to say what decision you'll make with it? Usually, when someone insists on getting estimates, that's my way to make sure that they really need it. besides, it also helps making an estimate that won't be useless in the context of the decision to be made. The lesson I learned from asking that is 1) many people ask for estimates without a clue about what they…

I’m talking about particular user stories, not the overall estimate.

For projects it’s almost always a budget issue “how much money and time does it need?” And that’s important because, like money is hard to get and $1 is different than $2M. I think the time is usually related to money due to revenue and costs and whatnot.

My example was about estimating “how long to add a revert button to 5 pages” and that requires “db crud to revert stuff” so how long the latter takes affects when the former can start and if they can both make it into the same sprint. Etc etc

Post reply on HN