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

91–100 of 382 posts

Re: Scrum disempowers developers

#91

Post by wpietri »

Uberphallus wrote: post #68
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

UML comes out of a different culture of development, that of the Rational software crew. They had their own much more heavyweight process than the Agile folks: RUP, or the Rational Unified Process: https://en.wikipedia.org/wiki/Rational_Software#UML_and_RUP

There was a little overlap; in particular, Martin Fowler wrote an intentionally thin book called "UML Distilled". But the UML world was generally heavy on both up-front architecture and formal, heavyweight design process. The Agile world at the time was energetically opposed to that, thinking that the main value of UML was in having a consistent language for us to all sketch on whiteboards together.

Re: Scrum disempowers developers

#92

Post by jillesvangurp »

Pretending to do agile seems to be widespread thing in our industry. There are literally no companies out there not claiming to be agile. So, the word has become meaningless. Scrum is the lowest common denominator in our industry when it comes to that.

Agile implies getting things done and getting things to market. If scrum helps you do that great. If not, ditch it. In my experience, Kanban is a step up on the evolutionary ladder. Both have issues with not prioritizing essential activities related to research, refactoring, etc. that you need to guard against. There's a difference between agile and firefighting.

One worry with scrum is the roles of product manager and scrum master. In my experience these things end up being formal job titles in bigger organizations. This is bad because they are typically on the very low end of the scale. That means you end up with the least experienced people filling these roles and a lot of corporate politics. I've seen more than a few organizations that were hiring accordingly.

Re: Scrum disempowers developers

#93

Post by gerbilly »

From what I could tell, most workplaces use scrums to enforce a minimum starting time for all their developers.

They would typically schedule an early in person scrum meeting to defeat all the devs that like to work late or remotely.

Re: Scrum disempowers developers

#94

Post by dasmoth »

MichaelMoser123 wrote: post #76
dasmoth wrote: post #64

Earlier quoted context omitted.

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

I don't know about continuous integration; version control + automatic builds really helps to prevent the mess that you have without it. I still remember the nightmare of copying sources from and to a central directory.

That’s something I’d probably put on the “good servant but bad master” category. Agree with what you’ve said, but have also seen it start to get oppressive.

(One pain point is when it is used to hide build/deployment complexity to the point when it’s no longer practical to build the thing on your own workstation...)

Re: Scrum disempowers developers

#95

Post by salty_biscuits »

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…

My mental model was that ideally it is a greedy algorithm for job shop scheduling (dev time) with dt = two weeks and a horizon as long as your backlog. The biggest and most common failure mode I saw was having a bad product owner (it can be a single point of failure, devs have a team to help them out).

Re: Scrum disempowers developers

#96

Post by nradov »

addicted wrote: post #66
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 vi…

The agile team members are supposed to write refactoring user stories and explain their value to the product owner. If the team members aren't doing that then they aren't doing their jobs and need to be trained.

Going beyond Scrum, Scaled Agile Framework (SAFe) has some specific guidance on refactoring.

https://www.scaledagileframework.com/refactoring/

Re: Scrum disempowers developers

#97

Post by regularfry »

ordinaryperson wrote: post #4

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.

You might be thinking of Reed Hastings: "The more talent density you have, the less process you need."

Re: Scrum disempowers developers

#98

Post by mwilliamson »

I think the value I get out of Scrum, or XP, or any other methodology, is two-fold.

Firstly, it gives you a set of tools to use -- sprints, TDD, product owners, and so on -- that should work well together. To use them well, I think you both need an understanding of how each of those tools supports some idea or principle that the methodology promotes, and whether or not you think that principle is important for your team.

Secondly, a methodology gives you a starting point of how to run a development team. It's easier, although not necessarily better, to start from a pre-existing cohesive set of practices than to build a process from scratch. Especially if a team isn't experienced with many of the ideas, this is not an unreasonable place to start.

I think the key is:

1) knowing what principles your team thinks is important (low defect rate? frequency of releases? developer happiness? empowerment?). This is often hard to articulate. As time goes by, you might discover principles that were previously implicit, or you might find that the principles that are important to you change.

2) knowing how each part of your process maps back to one or more of those principles

3) having a mechanism that allows you to tweak your process over time (for instance, retrospectives), whether that's adding, changing or removing parts of your process

Scrum can be a sensible starting point so long as you're willing to introspect and consider which bits are and aren't working for you, and you're empowered to do something about it.

Re: Scrum disempowers developers

#99

Post by nwhatt »

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…

Great job distilling the essence of scrum into three bullet points, I wouldn't disagree with those.

Here's the common pitfalls as I see them:

1. Sprints offer flexibility but unless you educate the whole company waterfall + gantt charts are what the business side wants

2. Unless you educate all members of a scrum team on what the retrospective is, and let the developers drive it, you won't be effectively improving processes

3. I've always felt conflicted about the agile "working software over comprehensive documentation value". To me it implies that documentation is easier when the product is working and/or the product might change based on feedback, so you don't want to re-write the docs. To people who don't learn scrum/agile it means "don't write documentation"

Re: Scrum disempowers developers

#100

Post by jameshart »

addicted wrote: post #66
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 vi…

This is utterly backwards.

The team owns it all - the process, the product, the technical artifacts, the code quality. If the team is looking to the PO or the Scrum Master to take responsibility for things, then they are going to fail.

The product owner is there to help the team understand what value they can deliver. The scrum master is there to help the team optimize the process. The team hopefully has developers on it who are there to help the team make well engineered pieces of code Maybe there are designers to to help the team make great user experiences. The team has specialists, but the team works collectively to deliver results.

If your scrum team has a bunch of engineers on it wondering how to get their voice heard over the product owner, you don’t have a scrum team building your software, you have a PO acting as a tech lead running a waterfall project.

Post reply on HN