Scrum disempowers developers • Hacker News Board

Re: Scrum disempowers developers

#191

Post by Robin_Message » Wed, May 30, 2018, 3:13 PM UTC

bartmcpherson wrote: post #30

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".

To quote one last bit of minutiae: "Scrum’s roles, events, artifacts, and rules are immutable and although implementing only parts of Scrum is possible, the result is not Scrum."

I agree with what you're saying, but Scrum says not to modify it. That's one of my problems with it.

Re: Scrum disempowers developers

#192

Post by mlthoughts2018 » Wed, May 30, 2018, 3:14 PM UTC

conatus wrote: post #156

mlthoughts2018 wrote: post #141

Earlier quoted context omitted.

Quoting from my parent comment, > "And Scrum is misapplied so often that this clearly applies ..." It's not about always being misapplied. Just that it's misapplied so often that in the larger scale decision making, it's a problem with Scrum. I don't deny there are isolated examples in which Scrum is applied well and works well. I also don't care, unless those examples represent the majority of cases in most average…

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 without Scrum.

The reason I think it's fair that Scrum has the burden of proof is that it is so far-reaching and overbearing in its degree of prescripting exactly the manner of working.

Scrum as a system is responsible for micromanaged enforcement of exactly one set of meetings, exactly one cadence of work, special new positions with Scrum-specific job duties, constraints on team structure, like cross-functionality and minimizing specialization, that there must be some form of aggregateable workload estimation, etc., all which are part and parcel with every Scrum implementation I've heard of (meaning that whether all these prescriptions are explicitly listed in some Scrum manifesto or not, they are absolutely a part of Scrum).

Given all this costly overhead and one-size-fits-all prescription, I think it's very fair to say, "prove it." If I know that my team works really well in our own ad hoc way that is tailored to our specializations, our current workload, our preferences, the way we jell as a team, etc., then why should I agree this other way is definitely, empirically going to be better?

I'm not saying any other team should use the custom methods my team has found to be productive. But why would we need to give them up for a system nobody has proven to be better, and many people have argued to be worse?

Re: Scrum disempowers developers

#193

Post by funkymike » Wed, May 30, 2018, 3:18 PM UTC

nickelcitymario wrote: post #170

mraison wrote: post #163

Earlier quoted context omitted.

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

That's... actually pretty accurate? Dang.

So it becomes this?

* Get feedback often from the business owners

* Get feedback often from the developers

* Get feedback often from the users

Re: Scrum disempowers developers

#194

Post by vannevar » Wed, May 30, 2018, 3:23 PM UTC

betenoire wrote: post #182

vannevar wrote: post #168

Earlier quoted context omitted.

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.

Sure, but the PM is there for a reason and the PM has roles. There is overlap with what developers can be doing, but we are trained/encouraged to punt to the PM for such decisions, questions, and suggestions. I get it, but it's now how I do my best work, proxying questions and discussions through a gatekeeper.

We do agile, but also use Slack and email, and walking across the room. If your organization is actively discouraging communication within the team unless it goes through the PM, that's bizarre. On the other hand, if the PM is acting as a gatekeeper with customers, that's not unusual. The reality is that you can't have everyone on the team talking directly to the customer, for a whole host of good reasons.

Regarding decision-making, that can be a problem---some PMs and product owners are micromanagers, hamstringing their team. But they would be micro managers with or without agile.

Re: Scrum disempowers developers

#195

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

geezerjay wrote: post #188

specialist wrote: post #78

Earlier quoted context omitted.

You're describing having a well defined goal, setting a critical path, and then regularly updating your progress. What we gray beards used to call "project management".

> You're describing having a well defined goal, setting a critical path, and then regularly updating your progress. What we gray beards used to call "project management". That's not true at all. The whole point of organizing projects around scrums is precisely that there is no well defined goal nor can one exist. What exists are the client's needs, and those needs do and will change frequently and radically as projec…

"...there is no well defined goal nor can one exist."

Consulting is the pejorative we gray beards used for that activity.

You reminded me of another pithy throwaway line:

Agile didn't improve outcomes, it just reduced the cost of failure, allowing teams to fail many more times with the same budget.

Re: Scrum disempowers developers

#196

Post by vannevar » Wed, May 30, 2018, 3:26 PM UTC

Retric wrote: post #169

vannevar wrote: post #166

Earlier quoted context omitted.

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

They also regularly "recruit good people and leave them alone" and they fail. And then we look on those people as "bad" people. Which was my original point above.

Re: Scrum disempowers developers

#197

Post by Robin_Message » Wed, May 30, 2018, 3:28 PM UTC

pigleg wrote: post #172

I wouldn't fault it for lack of technical craft, that's not a specific statement in the original manifesto, except loosely maybe "working software". Largely forgotten now since more than a decade has passed, but even the poor implementation of Scrum has helped shut down the RUP hyper-documentation madness, massive unshippable releases with hundreds of bugs, etc. When trying to explain "Why agile?" to new devs out of…

In part one of this series (https://www.lambdacambridge.com/blog/2018-05-how-scrum-destr...) I explain how technical craft was key in all the agile methodologies, except Scrum. So I think that was part of the thinking in the original manifesto, but not expressed at the time (fish don't perceive water?)

I suppose you're right that Scrum is better than waterfall deathmarches, but I hope we can do even better.

Re: Scrum disempowers developers

#198

Post by OnlyRepliesToBS » Wed, May 30, 2018, 3:30 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…

Scrum intentionally takes away power from the developers and puts it in the hands of a new manager class.

It makes moving paperclip more important than making them.

And that's evil.

Re: Scrum disempowers developers

#199

Post by virgilp » Wed, May 30, 2018, 3:32 PM UTC

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" :)

I argue that's actually a misconception of many scrum practitioners. It's not really "get feedback often", it's "get feedback early". "Often" is just a bad approximation of that. The difference is most obvious with retrospectives - if you just do them often they feel like a burden. What you want is to get early opportunities to improve .... but that's not necessarily through a very frequent retrospective! You have to let things crystallize a bit, so that people can observe the effect of process changes & give accurate+reasonable feedback on it.

Re: Scrum disempowers developers

#200

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

specialist wrote: post #135

wpietri wrote: post #91

Earlier quoted context omitted.

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…

Thanks for your misc comments in this thread. This particular comment, the "UML Distilled" reminder, triggered a few hindsight notions. Much like XML and J2EE tainted Java, I'm now having trouble distinguishing between UML and OOAD. Though I preferred Fusion to UML, I'm now wondering if any OOAD based methodology had a chance. "...thinking that the main value of UML was in having a consistent language..." Guilty. For…

I don't think the gist of successfully developing software has changed that much since the early 90s, at least in consultancy: You work in iterations where the team and client develop, refine and prioritize the features of the system until the system is good enough to be considered finished. There is an initial vision and strategy that needs to be developed in the first iterations. The UP implementations describe ways on how to do this, though the agile community has come up with more creative frameworks: design sprint, product vision box, customer service map, etc. The strategy is reviewed each iteration with the re-priorization of the features. For this it's important to have revisions on the documents created on the first iterations.

The challenge as I see it is that clients usually don't buy into this and they believe that developing software is like making sandwiches or turning buttons on and off when in fact is a discovery process of abstract things. They then demand a fixed budget, fixed time and fixed milestones for a fixed scope ("You are the expert, you should know how much time this takes."). To sell the project the salespeople from software companies deliver this, those who don't are considered incompetent. In this conditions agile methodologies are prone to fail but not for the methodology, but because most of the time those sold promises are done with incomplete information or tailored to be optimistic to sell the project. Metrics from agile methodologies show from the beginning that the project won't meet the expectations and then chaos ensues: they stop collaborating with the client to hide the reality of the project, "managers" pressure the team to do more in each iteration, they stop doing the disciplines altogether, iteration and daily reviews are treated as long meetings where people commiting errors are shamed and scolded and frictions start to emerge between all persons involved. This is where I believe the whole notion of "agile sucks" comes from.