Agile Is for Losers (2020)
hypermatic.com> "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.
This is probably the most damning thing about capital-A Agile. If you try to talk to a certified Agile practitioner about what kinds of projects aren't appropriate for an Agile process, you might get dismissiveness, you might get hostility, but you'll never get a frank and engaged conversation.
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.
Very true, but the agency does benefit from the current state of affairs: You can load up an engagement with more people...whom are there to help facilitate the process. These people add to the bottom line engagement revenue. When all your competitors are doing the same then the buyers of your services have no choice but to pony up. As someone who builds and enjoys building, it saddens me. We can do better, but how do we convince the deciders of this?
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!
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"
I’m at a place that’s implementing it backwards: “let’s train everyone doing the actual work on all the ceremonies and how to waste a bunch of time dicking around in issue trackers… wait you’re missing every sprint goal badly, why? We better figure that out!”
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.
> 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).
>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.
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?
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.
> 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.
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.
But that's shows the problem, right?
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?
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."
I've worked for several different companies and several different teams since "Agile" was developed. What I can say is "Agile" doesn't exist: I haven't even seen two teams within the same company doing Agile the same way and referring to the same thing when they say they're doing "Agile."
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.
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.
> 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.