Live data from Hacker News

Scrum disempowers developers

lambdacambridge.com

41–50 of 382 posts

Re: Scrum disempowers developers

#41

Why would you let yourself get so stuck in the minutia of SCRUM? Use the parts you need and not the parts that work against you. The value usually listed first in the agile manifesto is "Individuals and interactions over processes and tools".

Agreed. It should be about letting a team figure out the highly customized, team-specific things they need to do.

If that means getting rid of rigid Scrum frameworks, so be it. Maybe you don’t need regularly scheduled planning meetings, for example, because on a given team the planning might happen in a more 1-1 manner, with irregular and specially scheduled sync meetings that just arise organically from whatever the team’s working on.

Maybe you find that estimating story points doesn’t actually correlate with any predictive efficacy for delivery or deadlines, and maybe you find estimating also doesn’t help identify assumptions or potential blockers. So then, just don’t waste time estimating in that particular case.

Any part of the workflow, ranging from what project issue tracker you want to use to what meetings you agree to have, should all be adjustable by the team to customize for what makes that team, in that situation, most productive.

It doesn’t matter if it’s Waterfall, Agile, Scrum, or just some totally made up, off the cuff meeting arrangement with no formal name and no industry of consultants behind it. Whatever works.

Re: Scrum disempowers developers

#42
> Scrum has become the de facto definition of Agile

That is a part of the problem. Scrum is very far from Agile. Scrum introduces processes and tools while the Agile Manifesto [1] clearly states:

> Individuals and interactions over processes and tools

That said, Scrum isn't entirely bad. Its just not what many people think it is. As a tool to change the culture of a company that has been shaped by classical project management methods for decades it is very valuable. But the process shouldn't stop there as Scrum isn't the end, its the start.

So companies which managed to implement Scrum should try to move on to more Agile practices to transform their culture over time.

[1]: http://agilemanifesto.org

Re: Scrum disempowers developers

#43

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

You also missed the trade off's for increased speed compared to traditional wf projects.

One of the problems with the Scrum model is its used for every thing - just like they used to try and do every project with WF and IS9000/BS5750

Re: Scrum disempowers developers

#44

I find this article lacking, because it makes all of the same mistakes typical of these bandwagon anti-Scrum articles. Despite working in a a Scrum team, I recognise literally nothing of the problems that are described. Our product owner works closely with both commercial and development groups to build the backlog. Pressure to build good technical solutions is reasonably balanced with commercial requirements. The de…

> A team using Scrum still needs skilled people who know how to do their jobs effectively – and that includes the scrum master and product owner roles.

That is my key beef with Scrum here. I entirely agree that done well Scrum can be effective. But how it is often done is not well at all (e.g. the two day Scrum master training course.)

I'm criticising Scrum as it's widely implemented and how that is poisoning the groundwater for all agile methodologies.

And definitely I'll get on to how other processes can be better.

Re: Scrum disempowers developers

#45
If you do Scrum like that, you're doing it wrong (I know, no true Sctosman [1], and I know, there are actually dark patterns [2]).

I wrote a whole book about "Agile Anti-Patterns" [3]. Most of the book's content is about things that many companies get wrong when they start with agile or lean software development. Because it is very easy to get those things wrong.

Yes, those problems are extremely common. Not only with Scrum - Organizations also face those problems when they try Kanban or SAFe or whatever. Because, change in a traditional organization is hard. And to really implement Scrum, you'd probably need to change more about the organization than the org was willing to change.

But those problems are not Scrum's fault. If the team has no power, it is also not truly self-organized. And the Scrum Master is not doing their job.

You could start to improve by creating awareness about the problems. Blaming Scrum may or may not be a good idea to do that - Because, some people in your org may be invested in Scrum. Some mentoring or coaching for your Scrum Masters, Product Owners and developers and managers might be a better start.

[1] https://www.davidtanzer.net/david%27s%20blog/2014/03/26/no-t...

[2] https://ronjeffries.com/articles/018-01ff/hills-to-die-on/

[3] https://www.quickglance.at/agile_antipatterns.html

Re: Scrum disempowers developers

#46
post #35

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…

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

But if a given norm is always applied badly, it’s disingenuous to say it’s not the norm’s fault. It obviously is.

Even if it’s a good norm in theory, if it doesn’t survive contact with human sociology in practice, then it’s disingenuous verbal gymnastics to say “but the norm itself is good, it was just misapplied constantly and nobody, despite huge effort, could stop it from being misapplied.”

And Scrum is misapplied so often that this clearly applies, and renders whatever “spirit” of “true” Scrum irrelevant.

Re: Scrum disempowers developers

#47
post #14
post #11

My biggest beef with Scrum (and why I think it's a scam) is that they renamed everything, all the processes. Historically, there are three important sides, and roles, for each project. Product management - takes care what the customer wants to have build. Project management - takes care of what is delivered is on schedule and that there is enough material/personnel to build it. Architect/engineering lead - takes care…

Scrum didn't rename any of them. They added the roles of scrum master and product owner but those are roles that can be assigned to people with traditional titles in addition to their normal roles.

The scrum master and PO should explicitly not also be the PM, there's a huge conflict of interest.

Re: Scrum disempowers developers

#48

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.

It is a good facilitator of that conversation but you don't need to do estimating to have that conversation about implementation details. Once a team arrives at common patterns of implementing things then those conversations really only need to happen for new implementations or integrations with other systems.

Re: Scrum disempowers developers

#49

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

You also missed the trade off's for increased speed compared to traditional wf projects. One of the problems with the Scrum model is its used for every thing - just like they used to try and do every project with WF and IS9000/BS5750

Are you suggesting Waterfall projects are faster? I don't think you are, but that's how I read your sentence.

Also I don't know what IS9000 or BS5750 are but they sound like they had amazing naming committees.

Re: Scrum disempowers developers

#50
https://age-of-product.com/agile-micromanagement/ another interesting observation along this line; when the scrum master is a middle manager then he will micro manage the show - because that's the way he is supposed to function.

Empowering the workers is a good idea, but it is not how most organizations work.

Post reply on HN