Live data from Hacker News

Scrum disempowers developers

lambdacambridge.com

31–40 of 382 posts

Re: Scrum disempowers developers

#31

The teams I've been on that just 'jive' usually start with some process framework but then evolve to just work well together. There are strong philosophies in Scrum and Agile that should be kept as guidelines. The key is being agile (lower case 'a') so you can adapt to changing priorities. Continuous Integration/Continuous Delivery go a long way towards empowering developers. Two ways to tackle technical debt in proj…

I would say that estimation isn't so much about predicting completion as understanding hidden assumptions in the team.

We sometimes find that engineers have entirely different concepts of how a particular feature or change needs to be implemented. Estimation – planning poker in particular – is a great way to reveal that and start exploring what the reasons are.

Re: Scrum disempowers developers

#32
It’s often impossible to talk productively about this because of all the No True Scotsman fallacies uses to defend Scrum, e.g.:

“No true Scrum master would do X.”

“A product owner who doesn’t Z is just a bad product owner. Not Scrum’s fault.”

“If X is disempowering people then X is not Scrum.”

These are not valid defenses, and they just distract us from the elephant in the room, which is Scrum’s constant presence everywhere these problems occur.

At some point if the tool cannot do its basic job without requiring perfectly scrupulous product managers and “real” Scrum masters, etc., then it’s Scrum’s fault, and we need to think of less prescriptive, less inflexible models that cannot be so easily subverted politically to merely pay lip service to technical quality, while bastardizing reasonable principles to serve quarterly JIRA datamining expeditions and Dilbert-style management practices.

Re: Scrum disempowers developers

#33
post #17

Earlier quoted context omitted.

"no-one with the authority to balance the product owner and advocate for developing with higher quality" In a functional scrum team everyone on the team should be empowered to advocate this. In turn the product owner should be receptive to technical improvement because it is in the interest ultimately of the overall project success.

These types of replies always strike me as No True Scotsman fallacies, which are rife in Agile & Scrum. “No true Scrum team would do X.” “No functional team would disempower people...” At some point though, Agile & Scrum cannot be propped up like that. When the same failures happen again and again all across the industry, it’s time to admit that the tool facilitates that failure. The tool (Agile & Scrum) is the corre…

A poor organization will find out how to fail in many processes. The problems are much deeper than at the scrum level.

Re: Scrum disempowers developers

#34
I think the article confuses what Scrum is and what some (probably most) companies make out of it. I agree that there are scary things happening in practice and I've seen a lot of scrumBut and scrumAnd that really endangers a lot of projects.

My experience is that this is often caused by a lack of understanding of the methodology and how it can be applied and integrated into existing structures.

Also existing structures need to be integrated with Scrum to make it work. That is, they need to be transformed to match agile workflows.

The latter is not easy. Especially not in larger companies. I am not surprised that most do not even try to tackle this.

Re: Scrum disempowers developers

#35
post #17

Earlier quoted context omitted.

"no-one with the authority to balance the product owner and advocate for developing with higher quality" In a functional scrum team everyone on the team should be empowered to advocate this. In turn the product owner should be receptive to technical improvement because it is in the interest ultimately of the overall project success.

These types of replies always strike me as No True Scotsman fallacies, which are rife in Agile & Scrum. “No true Scrum team would do X.” “No functional team would disempower people...” At some point though, Agile & Scrum cannot be propped up like that. When the same failures happen again and again all across the industry, it’s time to admit that the tool facilitates that failure. The tool (Agile & Scrum) is the corre…

Well, sure it stumbles into this fallacy but so does the roll out of any process involving humans that has a set of normative criteria with a given critique in hand. I always feel this fallacy is a weak response as norms can always be applied well or less well. This is what makes them norms.

I've seen it work very well. I've seen it work badly. Where it has worked badly it was because the process was not fully understood, badly implemented and not iterated upon. For reasons I can detail on reflection. These are explicable and fixable reasons that given the right company ecosystem and desire to honestly reflect upon them and fix them could have been fixed. A bad process tout court would never see highly effective result in some cases.

Re: Scrum disempowers developers

#36
Like any and every business theory, Scrum has one or two core ideas that are awesome, but could be explained adequately in a paragraph or two. This does not sell books and consulting, so it evolved into a field of its own.

The fact that there is so much B.S. in Scrum doesn't mean that it has nothing of value to offer, though.

Here's what I get out of it:

1. Sprints are a better way to organize than Waterfalls. I've experienced this over and over again personally, so I'm sold on this.

2. It's important to stop what you're doing on a regular basis to evaluate progress and problems. This always seems like a waste in the moment, but failure to do so leads to regret down the line.

3. Ship functional products as frequently as possible. This is better than waiting until everything is done, because you can get feedback early and often from the end user.

Okay, so that's 3 ideas. It's better than most.

Re: Scrum disempowers developers

#37
post #33

Earlier quoted context omitted.

These types of replies always strike me as No True Scotsman fallacies, which are rife in Agile & Scrum. “No true Scrum team would do X.” “No functional team would disempower people...” At some point though, Agile & Scrum cannot be propped up like that. When the same failures happen again and again all across the industry, it’s time to admit that the tool facilitates that failure. The tool (Agile & Scrum) is the corre…

A poor organization will find out how to fail in many processes. The problems are much deeper than at the scrum level.

Basically this.

If the ecosystem in which scrum (or any process) is embedded is hostile then it will fail. But so will everything else, in time.

Re: Scrum disempowers developers

#38
post #6

Earlier quoted context omitted.

> What’s that quote from Elon Musk - process is an excuse for large companies to keep mediocre talent? Isn’t he the same guy who’s been learning that more process is necessary to make cars safely and on-schedule? I’d be reluctant to draw any broad conclusion from one optimistic aphorism.

Maybe he has a problem in finding smart people in sufficient quantity, so he has backtracked to the "process".

I think it’s more that business owners love the idea of hiring half as many workers and paying them 40% more but that doesn’t make it realistic.

Larger teams and process are really about scalability and robustness, because even high achievers have bad days, can only focus on one thing at a time, etc. If you’re running that lean you have limited capacity to handle anything unusual. It’s the same reason why the only way a 10x developer exists is if you compare them to a really unqualified, poorly managed group – almost nobody works on a single well-defined problem in isolation.

Re: Scrum disempowers developers

#39

What’s that quote from Elon Musk - process is an excuse for large companies to keep mediocre talent? Put enough smart people in a room and they’ll figure it out. Scrum isn’t any worse than Kanban or ‘pure’ Agile or Waterfall or Lean — every system has tradeoffs and smart people learn to adjust. No company is perfect. Tell management how the process can be improved. If they ignore you, consider moving on.

Elon Musk is allowed to be slightly arrogant, but most organizations work in the opposite way: process allows them to grow by making mediocre talent productive, instead of remaining small because they are limited by what a handful of very talented people can do without process.

Re: Scrum disempowers developers

#40
I disagree that the scrum master needs to be a technical leader. Technical leadership needs to come from the development team. The scrum master mainly needs to be a good communicator, communicating the value of feature priorities to the dev team, and the value of tech priorities to the product team.

EDIT: If your scrum master isn't a good communicator, here are some tips for doing the communication yourself: https://medium.com/@brlewis/fighting-technical-debt-in-an-ag...

Post reply on HN