Hacker News Reader

Comment by Stranger43 | Hacker News Reader

The problem with "The Agile Manifesto" and the cargo cult that arose around it, is that while the manifesto pretty accurately described what a lot of people felt was wrong with the "Civil Engineering" approach to software development it never represented an reliable methodology for how to actually fix those problems.

This is why we keep seeing those "no true scotsman argument" against any real world attempt to "be agile" where no failure can ever be seen as an argument against the usefulness of "The Agile Manifesto", and it's not really a new or surprising process but something that happens to most movements created around a loose manifesto.

What will change things for the better is pragmatism based on observations and currently thats not the way the Agile movement seems to be moving.

View on HN

The other issue is that it was written by contractors, as advice for other contractors. It's not as applicable to long-term work for entire companies. "Customer collaboration over contract negotiation" doesn't apply at all for most engineers; they're not the ones negotiating the contracts!

I have been on teams that were agile in the best way, and on teams that did Agile, in the worst way, though I am sure there is plenty of room on top and on the bottom.

So I strongly reject your implication that it's not really possible to get it right and that all the consistent failures are true-scotsmanned away. Being agile is awesome, and it is not actually hard, with the right people and mindset.

I also don't agree that the manifesto is as loose as you appear to think, as almost all the places where Agile falls down can be shown to be in contradiction to the manifesto. (Looking at you, Scrum, and you, Jira, etc.) However, it is fairly loose where many people would like it to be tight, that is in prescribing certain fixed processes.

For example, nowhere in the manifesto does it say you should have lots of meetings and you should stand during those meetings, but for some reason that is one of the key takeaways people seem to have from Agile. The standups actually come from XP (which is sadly mostly ignored, though it contains most of the real gems), and are not even mandated. The key idea is to eliminate meetings altogether, and to keep the ones that the team finds unavoidable as short as possible by making them somewhat uncomfortable.

Being agile is awesome, and it is not actually hard, with the right people and mindset.

And those with the "wrong" mindset -- i.e. who can't seem to force themselves to mouth all the nonsense and claptrap behind the Agile cult -- are just a bunch of uncooperative dolts, who you wouldn't want on your team anyway.

Ironically, it was exactly the worst teams that mouthed the nonsense and claptrap behind Agile, the Cult™.

The teams that were agile didn't do any of that crap, never mind mouth it. We were busy getting stuff done.

In fact, in one instance we had two of these teams right next to each other. The one that did all the claptrap of The Agile Cult™ right, the standups and whathaveyounot, and got cancelled, because they couldn't deliver (the software was still needed so the effort was rebooted).

The other did no standups, no biweekly sprints, no retrospectives, no planning game, no story points, no epics or whatever. But we did do the technical practices such as TDD, YAGNI, DTSTTCPW etc. And we accomplished something that people, including many on the team, did not consider possible. And with a team that of people that were mostly not considered very good.

And one of the best teams actually predated the Agile Manifesto by quite a number of years, and even XP was only publicised afterwards. When XP came out, there was a lot of recognition, a lot of what we were doing was XP. And there were definitely things we were doing differently, because our situations were not the same.

I get what you're saying. And yeah there are of course legitimate grains of wisdom mixed in with the claptrap and nonsense (as with most dysfunctional belief systems).

But by this stage, that's all beside the point. The "[Aa]gile" meme/cult has become radioactive. I'm personally done with it, and would greatly prefer never having to hear about it ever again.

It's the other way around: the wisdom was always there and is as true and pertinent as ever.

The claptrap and nonsense is the stuff that was added later, as Agile or as we call it Fauxgile. If you look at it in detail, you will notice that it pretty much invariably violates most of the actual agile principles in the manifesto: they set up plans (epics etc.) to be followed in tools (Jira) following rigid processes (Scrum) enforced by "masters" (really?!) with an entire industry behind them.

Now all of that seems completely farcical, so bad that one almost has to assume cynical motives. But when you go into these teams, it at least looks like they're being very earnest and honest in their efforts, even if they're consistently, insistently, doing the opposite of being agile. Teams/orgs will actively resist and route around efforts to help them become more agile, again while honestly (or at least it seems so) professing their desire to become more agile.

One example was the org that had a regularly scheduled weekly pre-meeting to the regularly scheduled weekly meeting on "how can we reduce process in our org". <raises hands> Ummm...I might have an idea.

Another was an org that was following the highly dysfunctional but extremely common process for mobile development: product managers think of new feature, spec it out, hand it to design, design does screens and then throws them over to engineering.

Raise your hands if you're in mobile development and this sounds familiar.

There's so much wrong with this that I don't really know where to start, but one thing it certainly isn't is "agile". Yet they were very sure they were "doing Agile™". I tried to suggest that in order to get feedback loops going, it might be better to involve development a little earlier.

They thought that was a great idea and instituted a new meeting involving design/engineering/product mgt. before the handoff to design.

Khaaaaaaaaaaaaaaaan!!. I mean aaaaaaaaaarrrrrrrrgggggghhh.

The Gitlab CEO Sid Sijbrandij has also written about this. A lot. Though under the label of "iteration" rather than "agile". These are largely identical. To him, good iteration is possibly the most powerful development technique, but he also writes that it is hard. That is where I think the people difference that I mentioned earlier comes in: for some people this is both extremely useful and also natural and easy. For the other group, the techniques are just as valuable (the reasons why they're valuable are not people-dependent), but don't appear to come naturally.

My guess is that most of the signatories of the AM belong to the former group, and so they thought that all that needed to be done was to free people from the shackles of their dysfunctional processes and all would be good. That appears to have been naive, these waterfall-ish style processes seem to be very attractive and comfortable to a lot of people, while being no less dysfunctional.

And so the coaches/scrum-masters etc. stepped in. And gave their customers what they wanted: a prescriptive "process" for achieving Agile. And since their customers were managers, they focused on management ceremonies, hence Scrum. Which IMHO is not just useless, but actively harmful.

But the same can be said about waterfall, every buzzword process have one success story and that one story will then be used to invalidate every failure, which is not really an useful way to look at it.

The problem is that by now more people have failed at agile then succeeded and instead of going back and modifying or challenging the universality of agile they way it happened with waterfall, people keep doubling down on the universality of "The Agile Manifesto" by discounting any failure as "no true agile".

> But the same can be said about waterfall

Not really. Waterfall was never a serious process.

> one success story

It's not "one" success story, but an extremely consistent pattern.

> any failure as "no true agile".

Again not so. If you're burning down Epics specified in Jira from your one year plan while doing daily standup status meetings, but not following any of the technical practices, you simply really aren't being agile at all.

And that seems to be the vast majority.

The technical practices are the meat, and the heart of the matter. Most of the rest is Fauxgile and somewhere between worthless and harmful.

What if there is no methodology to Agile? What if the whole attempt is akin to finding a methodology for becoming a rockstar, or a famous painter?

It kind of seems like the manifesto points out that the best way to create software is to get the right people and don't disturb them. And, if fact, if I try to think of examples of good software, this is usually how it came about, doesn't it? A small, talented, motivated group of people just working passionately on a problem.

Obviously, though, this does not scale at all.

Yeah, I worked with one of the authors and their perspective was that conversations between developers and subject matter experts were what was primary, and methodology was just whatever helped a team enable that. They were quite disappointed with the consulting industry that sprung up and its many variations of "the one true way to do agile."

Reply on news.ycombinator.com