Live data from Hacker News

Why Scrum is stressing you out

rethinkingsoftware.substack.com

71–80 of 462 posts

Re: Why Scrum is stressing you out

#71
post #32
post #28

Earlier quoted context omitted.

Some things that come to mind: - burn-down / velocity charts - retrospectives - poker sessions - daily stand-ups - user stories and related tickets (eg in JIRA) There’s probably more ... Perhaps these things are not necessarily meant to make managers happy, though managers do seem to like this stuff. As a dev, I prefer a more fluid approach without all the rituals. In the start-up I joined a couple of months ago, we…

I've been a dev, and I've been an EM. The only thing on that list I've ever liked is the velocity charts. And the only reason I liked them is that it helped me give a slightly less made up date to my own bosses to explain when something might ship. Over the years I've found that devs have been the one who like retros. Or at least a certain subset of them. When I've been an EM I would try to get rid of them, only to h…

Retros all too often focus on the last thing that happened and risk turning into a complaint session.

I've told my team anyone is welcome to ask for a retro whenever for any reason, but we don't make them recurring meetings because there is too much of a temptation to find something wrong to fill the time.

Re: Why Scrum is stressing you out

#72
Out of the 8 companies I've worked at as a product engineer, the most successful framework to deliver tangible results has been Basecamp's Shape Up approach. Engineering managers always ask "how many days" of effort when the real question they should be asking is "how much appetite"/"how long do we want to spend" on the particular product/feature we want to build? The Shape Up framework was the only time I didn't feel constantly stressed and it actually provided time to cooldown between the six week cycles. And the fact is it actually led to very successful product deliveries consistently. For those interested here's a link to it https://basecamp.com/shapeup/0.3-chapter-01.

Re: Why Scrum is stressing you out

#73

are there places today that don't do some variation of scrum today? Waterfall is pretty much non-existent.

Many engineering orgs just give lip service to scrum, which is as good as not doing it, which is good and works better. Meaning, in my experience: You work in a priority queue, that priority queue is re-synced with stakeholders (at least) once every two weeks, retros may be there as an opportunity to get other business verticals into the room to see what engineering finished recently, and the concept of "a ticket going over to the next sprint" doesn't raise blood pressure, because the system is designed for this and sprints aren't deadlines. Features might have deadlines, absolutely, but that's independent of the sprint.

I've worked at ~three places that operated similar to this; "minimum viable scrum" is a good name, or even better, "emergent scrum" because it isn't a process that's designed, its the process that emerges when someone toggles the "agile/scrum" button in Jira, but no one really cares one way or the other. Its a good process.

I've worked in one environment that was hard scrum, had scrum masters, extremely strict. To be honest: I felt almost no stress, but the company also delivered very little. There was a lot of "we can't get to swapping the color on that button until Sprint 18 in three months, but we'll schedule it for then". Missing a sprint was life or death, so every estimate got padded like crazy. When you took vacation, it was common knowledge that you needed to leave halfway through a sprint and come back halfway through another, sprint planning would basically forget about you. That (public tech) company doesn't exist anymore, and it radicalized me against agile/scrum: The entropic end-state of perfectly executed agile/scrum is an extremely well-lubricated machine that actually does very little.

Re: Why Scrum is stressing you out

#74

I’ve been building software applications for 40 years. No matter how you slice up the work, we all have to demonstrate progress and goal achievement. Agile, Scrum, Kanban, Method 1, or whatever are all meant to measure success. In a lot of cases there is a client or a customer that requires regular progress reports. Management uses reports to measure team performance. I’m not sure what planet the OP is from, but this…

Progress is important. That's why you plan for large milestones. There is no need for micro-ticket-story level updates, tracking, and overhead.

Tell that to a large PM organization. They love tracking minutia.

Re: Why Scrum is stressing you out

#75
post #12

Earlier quoted context omitted.

How do you handle QA and automated testing?

Be like Microsoft. Fire all your QA. QA is now done by developers and end users. If a multibillion dollar corporation can do this, so can you!

Or Boeing. Works great there.

Re: Why Scrum is stressing you out

#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 any other "process".

Re: Why Scrum is stressing you out

#77

This article hit really hard. I’m super stressed with my team’s cadence right now. I often think about what’s pathological in modern-corporate-scaled-agile-abominations and this really hits the nail on the head, but I think for me the main complaint is that if you can only see two weeks into the future, planning can become very difficult. I also often think of how our scrum process makes me feel like I’m back in grad…

does your team not follow any sort of higher-level roadmap?

Re: Why Scrum is stressing you out

#78

We have a woman at my company whose job is to update Jira ticket statuses. Instead of allowing the developers to update the statuses themselves, she will often prematurely update statuses from "In Development" to "Ready for QA" before any code is merged. Or she'll update a ticket that isn't yet being worked on to "In Development". It repeatedly causes a lot of confusion. I think she feels the need to be so hands on w…

That job definitely shouldn't exist. I'm not seeing where the gender of the person added much value to the story tho

Re: Why Scrum is stressing you out

#79
post #60

Earlier quoted context omitted.

And sprints! When I started at my current job, I naively looked at the bugs and tasks assigned to me, and started picking and fixing the highest priority tickets. Then I was informed, "Oh no, that's not how we do things here. Don't look at the priority, just work on what is assigned to you in the current sprint." I had never heard of sprints before. More recently, I had a conversation with my manager and asked, "Do w…

That's normal nowadays, even in the most ridiculous of situations. I once found that a system was getting a little expensive. As, AWS was billing us a million a month expensive. I figured this out, and came up with a plan that would cut it down to 80 thousand by spending 4 days: You know, a mild, 11 million a year of savings. Management insisted that the work had to go through scheduling, and intake, a process that w…

What was the opportunity cost of potentially deprioritizing other work?

Re: Why Scrum is stressing you out

#80
post #19

Earlier quoted context omitted.

Well you are a manager, can you at least change how things are done for your team?

ex manager here. managers are in an even worse wheel. biz demands managers show up to even _dumber_, less organized meetings than devs think they have to deal with. eng to eng meetings tend to be fine, but the rest of company culture at BigCorp weren’t trained in structured problem solving. it’s negotiating with goldfish half of the time (generally friendly goldfish), and no one actually practices any formalisms or l…

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?) projects fail and are simply abandoned.

The moment the check writer is not the direct manager of the development you have an intractable problem. The person in-between (quite literally middle management), is often not technical. But he has to convince the bean-counters that this project is "on time and on budget".

He can't help but feel sometimes that he's herding cats. He's an irritant to those who are "doing the work" so they treat interactions with him as a waste of time. Inevitably he starts trying to measure things. (And we all know what that means.)

His job is hard. He's stuck between developers who don't want anything to do with him and higher-ups who want reassurance, bit don't really trust what he's saying.

The miracle is not that this process sometimes fails. The miracle is that it ever works at all.

And sure, you may not like your meetings, but at least understanding the game might help you understand why his job is the crappiest of all of them.

Post reply on HN