> "This project was a fixed cost, fixed scope with a fixed deadline - if we didn't launch this new site in 4 months, the current live site was going to be taken offline by the previous agency, due to their contract and hosting ending."

Author mentions this, but there is really no point to use agile methods for such a project. Agile is not for task tracking.

With that said, if the project has uncertainty about what's wanted, UX is still researching or whatever, I'd still probably have dev-driven increments and demos to pin people down on making decisions. No external mgmt running that though.

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 experience the real-world implementation is meetings. More and more meetings. After a while client loses interest and basically leaves you to do something, which diverges from the real world need and solves an imaginary problem.

This happened so much that, I find my gorge rising whenever someone says "Oh we are using agile methodology"

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.

Whether you like or dislike Agile, this article is extremely biased to an agency context.

Which is interesting because I would argue an agency can never care as much about a product as an in house motivated, customer centric team.

Marty Cagan’s mantra at times is missionaries not mercenaries, and an agency is the exact definition of a mercenary.

Good product development should never be outsourced and I don't think this article is meaningful for engineers and other knowledge workers operating in startups and tech companies.

Clearly a lot of people have been burned by Agile and are not working in agencies, but I just want to highlight the context of the article a bit.

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?

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

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