Live data from Hacker News

Agile Is for Losers (2020)

hypermatic.com

11–20 of 22 posts

Re: Agile Is for Losers (2020)

#11
post #3

For me, Agile is a good idea implemented badly and subverted by the "business people" to hell and back. Without going into details, I find its core methodology cool. - You meet with the client, get an overview of the project - Cobble together something in the given time - Show the product-in-development, get the feedback from the client - Rinse repeat until the product and the client needs are aligned But from my exp…

>Agile is a good idea implemented badly

Where I work, they should hand out tee shirts with this phrase on it to all developers.

The only thing Agile is used for is to track points, nothing else. Across teams, points have the same meaning, points are rolled up by group to the VP. Plus each team is tasked to increase their points per iteration by 10%.

The teams are judged on points, not quality.

A big waste.

Re: Agile Is for Losers (2020)

#12
I agree with the skepticism of capital-A agile, but I have to wonder about that first example of the failed project.

Would using any other method have helped? It seems leadership/management was simply oblivious to any problems or feedback by the team members. The team surfaced problems and mentioned that "nothing went well" and "everything went wrong" and nobody did anything about it.

I must ask, which project management style would have worked in this scenario where clearly nobody was listening?

Re: Agile Is for Losers (2020)

#13
post #3

For me, Agile is a good idea implemented badly and subverted by the "business people" to hell and back. Without going into details, I find its core methodology cool. - You meet with the client, get an overview of the project - Cobble together something in the given time - Show the product-in-development, get the feedback from the client - Rinse repeat until the product and the client needs are aligned But from my exp…

> But from my experience the real-world implementation is meetings. More and more meetings.

And worse, no accountability. If deadlines are slipped or progress is not made well or fast enough, it's noted but nothing real done about it (except, maybe, more meetings).

Re: Agile Is for Losers (2020)

#14

Whenever I read about why Agile is bad and then the inevitable comments about how "no, Agile is good, it's just [company/business people/project managers/etc.] implemented it wrong," I'm struck with the similarity of "no, Communism isn't bad it's just that no one has really done it yet."

And it fails for pretty much the same reason Marx's ideas failed: it may sound like a harmonious utopia on paper, but in practice the whole thing is inherently brittle and unstable and immediately collapses into a maximally malevolent perversion of itself upon contact with humans' tendency to behave like humans, like the sociological equivalent of a prion disease.

> And it fails for pretty much the same reason Marx's ideas failed

It should be noted that Marx's ideas didn't fail, insomuch as most of his work is a (debatable, but not non-sensical) description of capitalism and its problems.

Maybe you meant some of his predictions, or the future society implementations of other people calling themselves Marxists?

Agile, regrettably, mostly did fail to live up to its promises.

Re: Agile Is for Losers (2020)

#15
post #4

> bastardizing Agile Sensationalist headline followed by lots of examples of people doing Agile incorrectly and the author seemingly being surprised by the outcome and blaming Agile. Garbage in, garbage out applies to all sorts of things, and processes and frameworks are certainly in that set. If you willfully ignore the principles of Agile and do "waterfall in sprints" don't be surprised when it ends up being a mess…

Agreed, but at some point, if nobody can follow a set of guidelines right, and projects following said guidelines tend to fail just as frequently as those which don't, could we say there is a problem with the guidelines as well?

A set of principles that nobody seems to be able to follow correctly surely has a fundamental problem?

Re: Agile Is for Losers (2020)

#16
post #12

I agree with the skepticism of capital-A agile, but I have to wonder about that first example of the failed project. Would using any other method have helped? It seems leadership/management was simply oblivious to any problems or feedback by the team members. The team surfaced problems and mentioned that "nothing went well" and "everything went wrong" and nobody did anything about it. I must ask, which project manage…

Answer: None of them. Because no matter what project management style you pick, the same managers would be running it. They would still be not listening to anything, still be not fixing anything, still be watching it go off the cliff without any intervention.

In fact, I assert that a good methodology can't save bad managers.

But bad managers sense that they're floundering, so they reach for the panacea du jour, hoping that it will magically rescue them. It won't. It might work in the hands of competent managers, especially if it's genuinely appropriate for the project, but in the hands of bad managers, all you get is disaster no matter what the methodology is.

Re: Agile Is for Losers (2020)

#17

Whenever I read about why Agile is bad and then the inevitable comments about how "no, Agile is good, it's just [company/business people/project managers/etc.] implemented it wrong," I'm struck with the similarity of "no, Communism isn't bad it's just that no one has really done it yet."

And it fails for pretty much the same reason Marx's ideas failed: it may sound like a harmonious utopia on paper, but in practice the whole thing is inherently brittle and unstable and immediately collapses into a maximally malevolent perversion of itself upon contact with humans' tendency to behave like humans, like the sociological equivalent of a prion disease.

Agile tends to fail because all-too-often the team's attention turns to the pomp and ceremony of "Agile" over getting the work done. I've met teams that believe they can wave their magic Agile wand and make the work go away. They tend to get a bit upset when I point out doing that work is your job.

Re: Agile Is for Losers (2020)

#18
post #15
post #4

> bastardizing Agile Sensationalist headline followed by lots of examples of people doing Agile incorrectly and the author seemingly being surprised by the outcome and blaming Agile. Garbage in, garbage out applies to all sorts of things, and processes and frameworks are certainly in that set. If you willfully ignore the principles of Agile and do "waterfall in sprints" don't be surprised when it ends up being a mess…

Agreed, but at some point, if nobody can follow a set of guidelines right, and projects following said guidelines tend to fail just as frequently as those which don't, could we say there is a problem with the guidelines as well? A set of principles that nobody seems to be able to follow correctly surely has a fundamental problem?

I've actually been on a team that did agile well. (XP, which is a subset.) It worked just like it was supposed to...

... until an upper manager couldn't understand our progress without documents the way he was used to. He also insisted on a large increase of scope without a change of schedule. And that was that.

It wasn't that we were failing to deliver. It was that upper management couldn't handle the lack of their normal process.

It also put too much pressure on the person playing the "customer" role - perhaps because we were a very large XP team (30 people).

It worked well as long as management let it, though. We delivered some releases, with solid, maintainable code, on time.

Re: Agile Is for Losers (2020)

#19
post #15
post #4

> bastardizing Agile Sensationalist headline followed by lots of examples of people doing Agile incorrectly and the author seemingly being surprised by the outcome and blaming Agile. Garbage in, garbage out applies to all sorts of things, and processes and frameworks are certainly in that set. If you willfully ignore the principles of Agile and do "waterfall in sprints" don't be surprised when it ends up being a mess…

Agreed, but at some point, if nobody can follow a set of guidelines right, and projects following said guidelines tend to fail just as frequently as those which don't, could we say there is a problem with the guidelines as well? A set of principles that nobody seems to be able to follow correctly surely has a fundamental problem?

There are plenty of people who do follow it correctly, and have done so in the past. I've been on some of those projects, and I've even ran some (although I'll admit I'm biased there; the devs might tell another story). Hell, I've heard prospective devs during the hiring process say that they would have walked if we didn't use Agile. The fact that Agile became popular should attest to the fact that it can work, but with that popularity comes the people like this article mentions that just read a 1 page synopsis of an Agile framework and then try to use it with no further training.

The primary reason IMHO for why Agile fails isn't due to the principles of Agile or any of the frameworks. The reason is that Agile shifts the balance of power and gives much of it to the devs. It requires trust in the people you work with and who report to you. Many people can't seem to give power up, or they come up with excuses for why they can't trust their people and must continue to "manage" them. This sabotages the entire process.

Moving to Agile is not a process change. It's a culture change, and those are hard.

Re: Agile Is for Losers (2020)

#20
Similar-ish to a recent submission,

> Software innovation just isn't what it used to be, and Moxie Marlinspike blames Agile

https://www.theregister.com/2024/08/09/marlinspike/ https://news.ycombinator.com/item?id=41208627

84 points, 4 days ago, 105 comments

The build-up in this article didn't do a ton for me (so so anecodes in marginal cases), but it's assessments felt pretty accurate. Lack of long term or lateral or wide thinking/insufficient Hammock Driven Development, especially across teams, bounds the level of possible success, keeps you from doing the core agile thing of building on what makes future changes easier.

Post reply on HN