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

161–170 of 382 posts

Re: Scrum disempowers developers

#161

Post by consp »

specialist wrote: post #101
rch wrote: post #90

Earlier quoted context omitted.

But you have to include 'estimates', which ruins everything (in non-trivial cases, yadda, yadda).

Estimating is my Achilles heel. Always has been. I'm way too optimistic. My workaround was to do jelly bean estimating. Get guesses from everyone, then use the average. Worked surprisingly well. We did other things to meet that target date, honor that estimate, of course. But that's a longer story.

What I've learned in engineering (any form, including software) is take the estimate (acquired in any decent enough way like averaging) and multiply by PI (or 3 if that suits you) to get a reasonable amount. In practice it works more accurately for larger sums than smaller ones so your mileage may vary. I guess it is easier for everyone to guess smaller workloads more accurately.

In my practical experience, I multiply the amount gathered from the previous statement by two to have sufficient negotiation space for people 'higher up the chain' who have no idea about anything of this and simply pull estimates out of thin air or their rear without any proper experience except "previous time it was xxx so it should be the same" (which it almost always is not).

edit: I prefer to have some time left on larger projects to avoid overrunning, even though that might be common practice. Usually though time is cut short due to delivery constraints or selling a product before asking the development and you get the 'wasn't it done yet?' speech.

Re: Scrum disempowers developers

#162

Post by gregmac »

some_account wrote: post #112
mmusson wrote: post #74

Earlier quoted context omitted.

My experience is that a good team does a good job. A bad team doesn’t. I think the focus on methodologies is to get a good result from an uneven team. Companies desperately want to treat programmers like standardized workers that can be mixed and matched as needed. The siren song of the methodology is that maybe it can achieve that goal. I have never seen this work in practice. There are no quick fixes. People can im…

I really dislike agile. A product owner asked me once if I get some benefit from them...and no, I don't. Thry get a lot of benefit from me sharing what I'm doing because they can then keep track of it and communicate it to other people, but I don't get any benefit personally. I want to be the guy who talks to the rest of the employees, implements things and get direct feedback from them. I dont want anyone in the mid…

I want to be the guy who talks to the rest of the employees, implements things and get direct feedback from them. I dont want anyone in the middle of that.

Part of little-a agile is making changes and adapting -- it's literally in the name. If you have a process in place that prevents you talking to the people you need to talk to, change or delete the process.

Re: Scrum disempowers developers

#163

Post by mraison »

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…

I'm probably oversimplifying, but this looks like 3 different ways of saying "get feedback often" :)

Re: Scrum disempowers developers

#164

Post by dagw »

kevstev wrote: post #148
mmusson wrote: post #74

Earlier quoted context omitted.

My experience is that a good team does a good job. A bad team doesn’t. I think the focus on methodologies is to get a good result from an uneven team. Companies desperately want to treat programmers like standardized workers that can be mixed and matched as needed. The siren song of the methodology is that maybe it can achieve that goal. I have never seen this work in practice. There are no quick fixes. People can im…

My quip on scrum/agile is that it "ensures mediocre results from mediocre teams." Its just a methodology in the end. It can help keep those that tend to have wandering minds focused, but for high performing teams the overhead slows them down. The assumption of a standard programmer is just never a reality as well. I actually saw a startup try to go full religious agile and only hire "full stack" developers to try to…

My quip on scrum/agile is that it "ensures mediocre results from mediocre teams."

And honestly that is all that most companies actually want/need. Most teams are mediocre and most projects only need a mediocre result. Getting something as good as a mediocre results out of your mediocre teams would be a massive improvement for a lot of place.

Re: Scrum disempowers developers

#165

Post by blat001 »

jarl-ragnar wrote: post #67

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…

I think that this is a critical point to understand and it highlights why Scrum has been so successful. We know from research in the 80's, and 90's 90% of Software projects failed, due to things like poor estimates or wrong requirements or delays.

Agile/Scrum has addressed a significant portion of those concerns by introducing lean processes. This visibility has enabled the business to understands what is happening in the SDLC quickly and can reprioritize and redirect if things are no longer matching expectations.

Where Scrum tends to fail (IMHO) is that it doesn't integrate well with other business units. I think the industry needs to focus on release management (predicting outcomes) as a process to help marketing teams, sales teams, etc... if they need to know what is happening in the next quarter, etc...

Either that or everyone needs to wait until engineering is finished before talking about new features (sounds a bit like the tail wagging the dog)

Re: Scrum disempowers developers

#166

Post by vannevar »

PeterisP wrote: post #158
vannevar wrote: post #140

Earlier quoted context omitted.

My experience is that a good team does a good job. A bad team doesn’t. Of course that's your experience. If you judge teams based on outcomes, then you're going to conclude that teams that succeed are good, and teams that don't must be bad. Unfortunately that offers no guidance in how to become a good team. The goal of software management as a practice is to find patterns of positive behavior that make good teams. Ag…

The observation is more about people. You take random people from good teams, mix em up and put them in a very different environment, they're still going to do a good job. What if there is no reasonable and reliable way to become a good team, and the only way to go from a bad team to a good team is to replace most of the team?

How do you know they are coming from "good" teams? And if so, isn't it reasonable to suppose that they might carry over good practices in their new environment?

I don't doubt that there are bad developers---I've definitely encountered them. But software development is a team sport, and it makes no more sense to just "recruit good people and leave them alone" in software than it would to do the same in basketball. Great teams have both talented people and winning strategy.

Re: Scrum disempowers developers

#167

Post by dgreensp »

matthewmacleod wrote: post #21

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…

Having worked at primarily at “informally agile” software companies in Silicon Valley (and I count Google as one), I see an important bit of truth in the article that Scrum ideas have become the embodiment of agile, and ideas from Scrum that may not make sense in isolation have become standard practice in software development and are somehow seen as the alternative to “waterfall” development, even if they have nothing inherently to do with waterfall vs agile development.

For example, it’s never made sense to me to have a powerful product owner while treating the development team as N interchangeable workers who may have “areas of focus” but have no roles, responsibilities, or organization among themselves, smearing out any sort of power or responsibility for technical quality like butter spread on toast. And yet, the fact that Scrum says to do it makes me wonder if that’s why everyone does it. Reading Scrum’s idea of a development team made me facepalm.

I don’t think the article is attacking a straw man that Scrum can turn a bad team into a good one. It may be pointing out that Scrum is regularly used to turn a good team into a bad one. Because everyone wants to be “agile,” even if they never use the word Scrum, they are implementing bad Scrum or cargo-cult Scrum by default.

Re: Scrum disempowers developers

#168

Post by vannevar »

betenoire wrote: post #157
vannevar wrote: post #143

Earlier quoted context omitted.

I want to be the guy who talks to the rest of the employees, implements things and get direct feedback from them. How exactly does agile prevent you from talking to your teammates and getting feedback from them?

If I have a full and well-groomed backlog waiting for me at my desk, what's there to talk about? Sure, you can, but the the whole point of the PM is to take that off your shoulders and the parent is saying he doesn't want that lifted from him.

A well-groomed backlog is not working code. So I don't get how that somehow means there's nothing to talk about. If there's an agile MVP, it's "write some working code, get feedback on it, then repeat until everyone's happy within some tolerance." Scrum is designed to increase feedback, but it's a floor, not a ceiling.

Re: Scrum disempowers developers

#169

Post by Retric »

vannevar wrote: post #166
PeterisP wrote: post #158

Earlier quoted context omitted.

The observation is more about people. You take random people from good teams, mix em up and put them in a very different environment, they're still going to do a good job. What if there is no reasonable and reliable way to become a good team, and the only way to go from a bad team to a good team is to replace most of the team?

How do you know they are coming from "good" teams? And if so, isn't it reasonable to suppose that they might carry over good practices in their new environment? I don't doubt that there are bad developers---I've definitely encountered them. But software development is a team sport, and it makes no more sense to just "recruit good people and leave them alone" in software than it would to do the same in basketball. Gre…

Because people regularly do "recruit good people and leave them alone". At my first job I was the only developer working on the project and I rarely spoke with my boss. He came back from a month long vacation and I had not noticed he was gone.

That's surprisingly common across the field. Most developers work on small teams doing small but often very long lived projects. Code staying in production for 30 years is surprisingly common outside of SV.

Re: Scrum disempowers developers

#170

Post by nickelcitymario »

mraison wrote: post #163
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…

I'm probably oversimplifying, but this looks like 3 different ways of saying "get feedback often" :)

That's... actually pretty accurate? Dang.
Post reply on HN