Agile Is for Losers (2020)
hypermatic.com
hypermatic.com
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.
Heck, if you ask an Agile coach when another agile methodology like Kanban or Shape Up! or Lean-CMMI might be preferable to Scrum, they'll act like a Free Evangelist preacher who just heard a member of their congregation say something nice about Methodists.
We're busy building when others are busy convincing the deciders they need Agile Scrum or Lean Agile or whatever flavor is cool in <year>. It's like Baskin Robbins - 31 flavors and each will make you fat and sick with enough exposure!
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"
We could have told you why before any of this: tasks get dropped on us and we’re told to work on them without yet having the necessary access, context, a firm explanation of what actually needs to be done, often no idea who it’s for or who knows can answer the questions we have, et c. So we lose 1-2 two-week sprints figuring out a bunch of crap that the right people could have put together in a day or three, then get to actually start the development work. Getting that right should be table stakes before starting with all the ceremonies and shit.
Fixing that is everything and doesn’t require “agile”. Do that and everything will work great. Agile will get the credit if we do ever fix that, but has nothing to do with it.
[edit] oh and of course they’re paying external agile consultants for all this, further increasing waste.
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.
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).
> 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.
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.
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?
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.
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.
A set of principles that nobody seems to be able to follow correctly surely has a fundamental problem?
... 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.
If management ends up interfering, and since Agile is supposed to be "about people", and management is people, Agile seems to be just as prone to mismanagement as other practices/principles, right?
I didn't mean that within a small team it doesn't work. I think there is merit to lowercase-a agile. But if capital-A Agile -- which is supposedly all about communication* -- fails to communicate with upper management, then where does that leave us?
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.
All "Agile" means at this time is you're not likely to be doing Waterfall, though I'm an old fart and remember Waterfall and I can tell you there are teams saying they're "Agile" and they're actually doing Waterfall. "Agile" is a meaningless word.
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.