Scrum disempowers developers • Hacker News Board

Re: Scrum disempowers developers

#201

Post by specialist » Wed, May 30, 2018, 3:34 PM UTC

nickelcitymario wrote: post #146

specialist wrote: post #101

Earlier quoted context omitted.

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.

> Estimating is my Achilles heel. Always has been. I'm way too optimistic. That's kinda the whole point. Everyone sucks at estimating. Scrum proposes a way to do "what greybeards call project management" in a way that deals with this universal inability.

I'm having trouble articulating this, please forgive:

I didn't explain "the other stuff" for why jelly bean estimating works.

The number doesn't matter. It's the shared hallucination (consensus) for the deadline. It short circuited, resolved the debate about "how long". It secures the team buy-in.

Once we had a deadline, we managed the work to match. Closest analog I can think of is Kickstarter: initial goal and stretch goals. We had the must haves (stuff listed in the draft press release). We also had dozens of nice to haves we'd sneak in, time permitting.

Agile, Scrum, sprint style estimating is too fine grained, the horizon too near, to do effective estimating.

Re: Scrum disempowers developers

#202

Post by termau » Wed, May 30, 2018, 3:37 PM UTC

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…

Sprints are a shit idea and need to die a horrible death. The number of times we've had to break up some functional requirements for no reason other than to meet some stupid concept isn't funny ultimately it's a waste of time in itself

Re: Scrum disempowers developers

#203

Post by jmulho » Wed, May 30, 2018, 3:39 PM UTC

specialist wrote: post #86

HolyHaddock wrote: post #80

Earlier quoted context omitted.

What's the scrum manifesto?

Paraphrasing: The Agile Methodology is to argue about The Agile Methodology. Source: Certified Scrum Master training. Three times. Still have no idea what these charlatans are talking about.

Which is a higher distinction, Scrum Master, Web Master, or Dungeon Master?

Re: Scrum disempowers developers

#204

Post by AllegedAlec » Wed, May 30, 2018, 3:40 PM UTC

nickelcitymario wrote: post #154

walshemj wrote: post #83

Earlier quoted context omitted.

Oh bum I meant ISO9000 BS5750 is the Uk equivalent (and I worked at my first job on a joint project with the BSI on BS5750) But and its a big but some times you need the rigor a properly done waterfall process provides Air traffic control for example. You seriously don't understand the trade offs you make with "agile" vs waterfall? I have done both very successfully.

Nope, don't understand the trade offs if you're suggesting scrum is slower than waterfall. That just doesn't line up with my experience. "Results may vary," though. The issue I've had with every other project management approach is the illusion of structure. I'm not an expert on all or any approach. But my experience is that everyone wants me to be able to project, since absolute certainty, what my team can get done…

> Nope, don't understand the trade offs if you're suggesting scrum is slower than waterfall. That just doesn't line up with my experience. "Results may vary," though.

The idea is that if you have a well defined problem domain and you know exactly what the software is that you have to deliver, you don't need the short cycles, and all the meetings and pokering and whatnot would just be a waste of time. You know what you need to make, so you can just continue working.

Re: Scrum disempowers developers

#205

Post by lispm » Wed, May 30, 2018, 3:40 PM UTC

mlthoughts2018 wrote: post #190

lispm wrote: post #152

Earlier quoted context omitted.

> What? I don't assume Scrum should or can fix bad management practices. What? Scrum fixes all bad management practices? > I'm saying adding Scrum to already-bad management practices is like throwing gas on the fire. There we need evidence that it is actually so. Haven't seen any convincing data for that. > Scrum doesn't help. The sentence before claimed something else: Scrum makes it worse, quickly. > Also, if Scrum…

> What? Scrum fixes all bad management practices? What are you saying here? I was questioning your original statement that I mistakenly thought Scrum should fix bad management practices. I do not think that, and no part of that is a criticism of Scrum. The criticisms are other things. Your follow-up just seems confused about your own parent comment. > "There we need evidence that it is actually so. Haven't seen any c…

> I've seen a lot of that evidence, in threads like this, in the original post, and also empirical evidence in my own work experience with Scrum as both a developer and a manager across several organizations of various ages and sizes.

'evidence' found in Hackernews posts?

> I'm confident the evidence shows zero efficacy

this will surely help with selecting evidence, given that you know already the findings.

> This is pedantic to the point of making me suspect you're just trolling to argue with anyone who doesn't like Scrum. Yes, indeed, two different sentences claimed two separate but compatible and related things. Shocking!

How about deciding what you want to say: a) scrum makes it worse or b) scrum does not help?

> This is abject nonsense.

Really? Before we have worked with RUP and Agile RUP. Compared to that Scrum is tiny.

> like mandating that all teams should be cross-functional, which is totally disconnected from business realities in many cases, especially for teams whose sole business value is highly specialized domain area.

The team should be cross-functional based on the product the team develops.

> This presumes that there always exists some "reproducible way"

This actually presumes that I identify successful practices which can be applied in many projects. We did.

> You're just denying the premise that customized, situation-specific or team-specific workflows could be the right way.

No, I'm not denying it, but when my team had success with Continuous Integration, I probably would use that in the next project - when applicable. It would also be a surprise if in a new project I would need to start from scratch to completely redesign workflows and team communication, without any prior knowledge/practices applicable.

I've worked for a few decades in software projects and in software consulting - often I was responsible for project and team setups. Often developing new stuff. I can easily imagine that other domains work differently.

Re: Scrum disempowers developers

#206

Post by knoq » Wed, May 30, 2018, 3:41 PM UTC

alistairSH wrote: post #110

barrkel wrote: post #75

Earlier quoted context omitted.

I recognize the disfunction. What happens is that the owner of the backlog becomes the controller of how much time gets spent on what. With feature pressure, it's all new features all the time, with no scope to address debt.

IMO, this is where a good leader (SM, tech lead, whoever - I don't mean a literal manager) advocates for sanity on behalf of the rest of the team. Mostly, this just requires somebody to say "No." every so often in the face of ridiculous demands. As SM, it's my job to ensure that not only will the PO listen to concerns from the team, but the team feels empowered to provide that criticism. If neither of those happens,…

Thank you for being the kind of owner I want.

I recently quit a job because I was the only one on the team "capable" (or that felt confident/comfortable) saying "No."

As a "devops" (loosely defined on our team) I felt my focus was uptime and error rates which sometimes is counter to new features (what managers want)...

Re: Scrum disempowers developers

#207

Post by nradov » Wed, May 30, 2018, 3:41 PM UTC

mlthoughts2018 wrote: post #192

conatus wrote: post #156

Earlier quoted context omitted.

Seems you are shakey ground, without empirical justification, to say that in the majority of cases when applied scrum goes badly. We are probably at the point of trading ancedotes, but I'd say in the majority of cases where I have seen it applied it has worked more than it has not. Even a poor implementation has yielded some benefits. And those pieces that have not worked there are reasons why.

I agree we might be at the point of trading anecdotes. I would suggest though that there could be the problem that a team works hard to produce good outputs in spite of Scrum, rather than because of it . My feeling, as I have mentioned elsewhere is that this burden of proof is on Scrum and Scrum proponents to back up the claim that it facilitates better business outcomes than would otherwise have been obtained withou…

There is no particular burden of proof. No one cares whether you approve of Scrum or not.

But what are you comparing Scrum to? Define your specific objections and propose an alternative.

Re: Scrum disempowers developers

#208

Post by rwmj » Wed, May 30, 2018, 3:41 PM UTC

mmusson wrote: post #74

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 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 experience is that a good team does a good job. A bad team doesn’t.

My experience is that sprints interrupt my workflow to such an extent that I can no longer get anything done. In other words, they make a good team bad.

Re: Scrum disempowers developers

#209

Post by pjbster » Wed, May 30, 2018, 3:42 PM UTC

Sometimes - heck, perhaps most times - when Scrum is involved, some organisations are just too fscked to save. Over time, the "leadership" have reacted to market forces by imposing variations on processes, cuts, reorgs and redundancies. The result is a workforce who, even if they were given total autonomy and unlimited resources, would be unable to turn things around.

Not that these execs would see it like that. Instead, they hear this Scrum thing has worked wonders elsewhere so they wheel it in and, if it fails this time, it's clearly the crappy workers who are to blame. "Management was right about that all along."

I take other commenters' point about strong leadership making a difference. Fully agree with that. But some situations are simply unrecoverable no matter how great the team.

Re: Scrum disempowers developers

#210

Post by srtjstjsj » Wed, May 30, 2018, 3:42 PM UTC

termau wrote: post #202

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…

Sprints are a shit idea and need to die a horrible death. The number of times we've had to break up some functional requirements for no reason other than to meet some stupid concept isn't funny ultimately it's a waste of time in itself

Are you saying you have projects that show 0 progress of any kind after 1 month, but still succeed later? What is happening in that first month?