Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Scrum disempowers developers

lambdacambridge.com

Post reply on HN
Print view View original

61–70 of 382 posts

Re: Scrum disempowers developers

#61

Post by tomtimtall »

nickelcitymario wrote: post #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 e…

The scrum manifesto is not overly verbose. It explains the value and concepts in a manor that does not lend itself to misrepresentation.

There is definatly a lot of companies peddling hype around scrum but it has a very lean and strong core which is in no way pulling in that direction.

Re: Scrum disempowers developers

#62

Post by lmm »

js8 wrote: 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…

I don't think there was anything like the kind of consensus you're portraying about what these things were called. Different shops used their own terms for things; "architect" meant radically different things from one pre-scrum shop to another, "engineer" even more so. "PM" would be used interchangeably; different people from the same company would tell you it was "product" or "project".

I don't like renaming things for no reason, but if you want a term to have a precise meaning and not carry any baggage from previous similar-but-subtly-different usages, it's probably best to coin a novel term.

Re: Scrum disempowers developers

#64

Post by dasmoth »

MichaelMoser123 wrote: post #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.

A slightly different take on why scrum becomes micromanagement, which has always seemed revealing to me: https://www.mountaingoatsoftware.com/blog/ssssh....agile-is-...

Re: Scrum disempowers developers

#65

Post by jrs95 »

watwut wrote: post #28
smackay wrote: post #12

Earlier quoted context omitted.

But the essential difference is that process applied to manufacturing is about repeatability, quality, reliability etc. where process in software is more about communication. Eventually, maybe, a software process will be more like a manufacturing one but the variation in technologies, techniques and general fashion make that hard - even in limited areas such as CRUD web apps. I think you'd get the same outcomes with…

Awesome software development process that is not about communication: testing by testers. Also code and documentation review. Also, keeping tasks in tracker and having version controll. Etc.

Code review definitely is about communication. That’s arguably it’s biggest benefit. The author could test something himself, but code review facilitates a conversation and keeps people on the same page.

Re: Scrum disempowers developers

#66

Post by addicted »

tootie wrote: post #58

Our weekly "why scrum sucks" post that's really a "why my company does scrum wrong and I don't know how to fix it". Product owners push customer value. Of course. You should too. Code quality and refactors have business value. Reduced maintenance cost, fewer bugs, faster future dev. If you can't explain that to your product owner then maybe it's not worth doing. I think your big missing piece is the collective owners…

Who is the “you” here? Who is supposed to explain to the product owner that code quality and refractors are worth doing?

The real issue the article brings up is that Scrum has an individual who takes ownership and responsibility for the product backlog, it has an individual who takes ownership and responsibility for the project management, but it has no individual who takes ownership and responsibility for the non visible technical aspects of the product.

In an ideal world, this responsibility would be taken up by the scrum master, who would have technical expertise, but as the article points out, (a) scrum never states this, and in fact, hints in the opposite direction, and (b) this is rarely the case in the real world. The scrum masters are usually as non-technical as you can get.

Re: Scrum disempowers developers

#67

Post by jarl-ragnar »

Scrum is just a simplified process for applying some of the principles behind lean manufacturing to software engineering. One of the core principles of lean is - minimize work in progress (WIP). Sprint's are just a way of minimizing WIP.

Why minimize WIP? Because WIP holds the risk that you're building the wrong thing. In manufacturing this might be using flawed parts that won't get tested until later in the process or it might be building inventory that you ultimately can't sell because the market demand has changed. In software WIP risk could be a misaligned understanding of the requirements; a flawed view of what minimum viable product looks like to the target market or a technology stack decision that represents a performance dead-end. In all of these examples you want to find out if you've made an error as soon as possible because if you're wrong then all of the WIP may need to be discarded.

A smart team holding to the core lean principles should feel empowered. Arguably Scrum, in it's dis-empowering form, is just another process to help manage mediocre teams.

Re: Scrum disempowers developers

#68

Post by Uberphallus »

nickelcitymario wrote: post #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 e…

> This does not sell books and consulting, so it evolved into a field of its own.

It's funny how it turned into UML

Re: Scrum disempowers developers

#69

Post by lmm »

mattbrewsbytes wrote: post #25

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…

> Two ways to tackle technical debt in projects:

Disagree with tackling it as a separate activity at all - that's a way to get useless churn as you move towards an architecture you think is better rather than one that meets your actual needs. Do continuous improvement instead: improve the part of the codebase you're working on in a way that also contributes to your immediate, customer-facing task. "Make change easy, then make the easy change".

> An example of a guideline is estimation with planning poker. We completely ditched estimation activities. The estimates were usually off and not good predictors of completion. The team has a cadence of ticket completion and the 'sizes' of the tickets vary some but you don't need to waste time estimating.

You need to give enough of an estimate to let the business prioritise, and to realise when a task is too big for a single ticket. You shouldn't spend a lot of time on estimation (frankly I struggle to imagine how your planning poker ended up taking long enough to matter) except when developers radically disagree, as that's a warning flag for a story that isn't clearly scoped.

> Developers (humans) are horrible at estimating. Having a good PM/PO set expectations with the business helps.

You don't want to rely on one person getting it right. Developers, like most workers, understand their own job better than anyone else; they're the people who should be giving their estimates.

Re: Scrum disempowers developers

#70

Post by mlthoughts2018 »

mindcrime wrote: post #57
mlthoughts2018 wrote: post #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 eve…

Oxygen is also present everywhere these problems occur, so clearly oxygen is at fault...

Someone proposes a mechanism by which Scrum is problematic.

“In Scrum, product owners ought to empower the team to advocate for technical quality, but in many Scrums, this does not happen, and short-term, quality-ignorant changes to the timeline rule instead.”

This is a claim about the mechanism of Scrum’s failure. And in response someone offers a non-falsifiable defense, like, “whenever that occurs, it’s always the company’s pre-existing badness to blame. Never Scrum.”

Can you really not see how this is completely different from an unqualified claim that correlation implies causation?

Your comment comes off like you think it has some rhetorical punch, but I invite you to reconsider that you migh have completely missed the entire point.

Post reply on HN