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

221–230 of 462 posts

Re: Why Scrum is stressing you out

#221

Post by everdrive »

LeFantome wrote: post #18
loloquwowndueo wrote: post #8

Earlier quoted context omitted.

Just keep in mind that a lot of people equate Agile with Scrum, which is incorrect. Agile is about exactly what you said: empowering devs to get shit done. None of the extra “keep managers happy” crap that Scrum introduces is in any way covered by the Agile manifesto.

What in Scrum is about keeping managers happy?

Without a lot of the project reports, the manager would honestly just have no idea what's going on. I recently moved into management, and one of the challenges I'm trying to balance is how to be aware of my team's progress without wasting their time or being a bottleneck for them. It's a legitimate problem which is often tackled poorly.

Re: Why Scrum is stressing you out

#222

Post by spacecadet »

Ive mainly work at startups and as a consultant/sub-contractor and have encountered many implementations of agile and waterfall. One place I consult for, and this is not a defense of agile just an observation of some good in what this shop is trying to do, well this place handles sprints as "multi-week" (defined by the team up front, weighing factors like; are we blocked by client, complexity, etc). The projects are still more or less waterfall with a client deadline at the end (They are mostly fixed scope/budget after all), and the only sprint deadlines are periodic client demos that have no expectations (progress check ins, see what we did, yay). The teams here only seem stressed in the old sense, right before the end. They often joke and call it agilefall, with the agile part intended to force teams to share progress and collect progressive feedback. As well as hold other internal meetings like sprint plannings (really just team checkins, are we blocked? should we start this vs that, have we learned something, etc) and retros (also just checkins, how we feeling? are people butting heads, etc). My biggest gripe with them is that no one takes responsibility for any form of ticket management and it can be chaotic knowing who is actually doing what day to day, requiring too many stand-ups and slack messages. They try to map tickets to scope up front but no one moves them along and they usually just follow the estimate document... since all the subs are global and remote it would be awesome to just check a board each day and dive into work instead of everyone needing and hour at the ass crack of dawn, during dinner, or at bed time, their local time...

Again, not saying this is my recommendation, but its definitely not some feature-mill, even tho we are literally a feature-mill as a fixed scope/fixes budget consulting shop, lol... not the most interesting work, but pays well, low stress, and if I heads down and get it done, I get tons of free time to do my own thing.

Re: Why Scrum is stressing you out

#223

Post by fireflash38 »

maximumgeek wrote: post #9

I think back to the early 2000's, and there are other factors in play as well. Back then, I worked with a team of engineers that stayed together for over 4 years. In that time, we did not have Project Managers telling us to do daily standups. We met as an engineering team. We often would go days without having a formal meeting. But, software was different then as well. Everything is interconnected now. One team dropp…

> and testing is given lip service.

It's one reason I'm really thankful to work in a certified/regulated industry. It's mandated to effectively prove your work to get the sign off. And since you can't really sell too well in the area without that cert, it's a big part of development.

But holy hell is it still hard to get specific people to test their work. They just don't even think about it.

Re: Why Scrum is stressing you out

#224

Post by Lutger »

AnarchismIsCool wrote: post #3

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…

I've heard a lot of push back against all kinds of process on this forum, and it always surprises me.

But reading the article made something click: it is not about the specific process, the (lack of) autonomy is what really matters. I guess I got lucky to work a lot in teams where we largely controlled our own process, so even if we used bits and pieces of scrum, kanban or other methodologies, it was always of our collective choosing and when it didn't work, we changed it.

I did like to have rules, principles and process. A simple playbook for a daily meeting that made us not forget important things and sped up the meeting. Making things in small increments meant that I didn't have to review thousands of lines of code. Having a visual overview of work neatly spelled out means I don't have to re-think every time I pick up a new item to work on. This also prevents useless work because one of your teammates decides to work on the same thing as you without telling it. All these things make me happier and more productive working together on some big thing.

The key is that the team should be in control of the process, not some manager who isn't part of the team and affected by the process. You need to have a stake in it. The only other factor that undermines this is 'process for the sake of process'. Every part of the process needs to earn the inevitable cost its implementation is bringing. Some people seem to be happy paying the pricing without getting the value.

Re: Why Scrum is stressing you out

#225

Post by skydhash »

everdrive wrote: post #221
LeFantome wrote: post #18

Earlier quoted context omitted.

What in Scrum is about keeping managers happy?

Without a lot of the project reports, the manager would honestly just have no idea what's going on. I recently moved into management, and one of the challenges I'm trying to balance is how to be aware of my team's progress without wasting their time or being a bottleneck for them. It's a legitimate problem which is often tackled poorly.

You can just talk to them. No need to set a ritual around it. Most professionals know about expectations and the team’s need to deliver.

Re: Why Scrum is stressing you out

#226

Post by lasereyes136 »

Interesting article and I have observed all of the situation described in it.

I would like to point out that when agile, and even Scrum to some degree, was introduced it was a way for people creating software to take back control of a runaway process that prevented team from doing their best work. It was a grassroots movement championed by people invested in finding better ways to create software that were less stressful and more successful.

Most of the issues in the article were coopted in Scrum to take control of software creating back from the teams. Whatever replaces Scrum, and agile, will need to learn from the mistakes and compromises of Scrum or it will suffer the same fate as Scrum and become a tool to force teams into a delivery model that gives managers and executives more control while reducing their accountability.

Re: Why Scrum is stressing you out

#227

Post by laboratorymice »

everdrive wrote: post #221
LeFantome wrote: post #18

Earlier quoted context omitted.

What in Scrum is about keeping managers happy?

Without a lot of the project reports, the manager would honestly just have no idea what's going on. I recently moved into management, and one of the challenges I'm trying to balance is how to be aware of my team's progress without wasting their time or being a bottleneck for them. It's a legitimate problem which is often tackled poorly.

regardless of "process", work items should be tracked (in the problem solving record for our future selves sense, not time keeping sense), so you can follow those. If you're a non-technical manager, then either a) the implementation goes super smoothly and the estimate the dev team initially gave you is all the progress update you need, or b) it doesn't go super-smoothly and you should be involved in any discussions that arise. If you find yourself asking "when is it ready?" you've likely gone astray.

Re: Why Scrum is stressing you out

#228

Post by skydhash »

mrits wrote: post #218
AnarchismIsCool wrote: post #3

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…

The reality is even good devs tend to work hard on the wrong thing. Accountability comes from your peers as much as your manager. If this makes you angry you are one of the bad ones.

Everyone tends to work hard on the wrong thing if it what they like to do most currently. Everyone. A conversation is all that is needed to remind them of the team priority, non need to create a creativity carcan with processes.

Re: Why Scrum is stressing you out

#229

Post by Lutger »

twunde wrote: post #31
LeFantome wrote: post #18

Earlier quoted context omitted.

What in Scrum is about keeping managers happy?

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…

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 and interesting to you, there's a difference. Management stays out of the daily.

Sprint planning: the sprints are the compromise to management so we can have some sense of progress, so this is of course the one meeting that is useless to the team getting work done and can hamper productivity. Just make it quick.

Retro: you should do a retro about if you think the retro is useful and why/why not. If the team doesn't think it is, either change it until it works or make this the very last one. Management stays out of the retro. ("But are you then not doing scrum anymore?" "So what, save the pedantry for writing out the functional and technical requirements please")

Thing is, you do need to understand what you are working on, and it needs to be more or less the same as what your team members think they are working on. If you are 100% efficient at building the wrong thing, your 0% overhead amounts to exactly nothing, and the 80% efficient scrum team is infinitely more efficient. Though these extreme cases are usually a problem from higher up, without any way to align your work you will usually not be efficient. And if you are, then good for you, don't follow scrum like its some cult. But most teams need a little coordination.

Basically if anybody feels a meeting (or anything, really) is a waste of time, there is a problem that needs addressing. And the problem is not the feeling, but what is causing that sense of waste. Take it seriously, it is almost always signaling a flaw in the process. Learn how to talk about this in the retro and get to the bottom of it.

The retro is about debugging anything that isn't working optimal in the team. If you cannot find any bugs and fix them, then you are either perfect or just not good at debugging, and I know which one to bet one to be the most likely. One sure sign a team isn't very capable is when there is a lot of blaming involved. Usually external factors or tools get the blame, but in very dysfunctional teams people blame each other.

If you work in a team that doesn't adequately address these problems and you have no power to change it, then it may be time to look for another job.

Re: Why Scrum is stressing you out

#230

Post by dartos »

LeFantome wrote: post #18
loloquwowndueo wrote: post #8

Earlier quoted context omitted.

Just keep in mind that a lot of people equate Agile with Scrum, which is incorrect. Agile is about exactly what you said: empowering devs to get shit done. None of the extra “keep managers happy” crap that Scrum introduces is in any way covered by the Agile manifesto.

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.

Post reply on HN