Hacker News Reader

Comment by rebeccaskinner | Hacker News Reader

Agile is a tainted term. For it's proponents, it's become nothing more than a vacuous manifestation of the No True Scottsman fallacy. Anything that works is True Agile, and anything that doesn't is Not True Agile (or would be True Agile if you weren't holding it wrong). The principles that underlie Agile are either entirely self-evident and can't be claimed as a particular benefit of Agile per-se, or they are hopelessly naive about the way people, and companies, actually work. Agile itself has no real original ideas, and offers nothing of value.

At this point, the best thing we can do is let Agile, all of it, die.

View on HN

> Agile itself has no real original ideas

Core to the 12 Principles, and thus Agile by extension, is the idea of no managers. Each of the 12 items exists to get you thinking about what developers (and the business people!) need to do if there is no manager acting as the guiding force.

While no managers is not a novel idea in a vacuum, it isn't something organizations usually think about. It's just the unspoken expectation that there will be managers once you have enough people to form a team.

> hopelessly naive about the way people, and companies, actually work.

Indeed. One of the 12 principles is quite explicit that it will not work with any Random Joe; that you need very specific people who are motivated to make an organization function without management helping them. Much as you want to pretend you are not Random Joe, you are, and it literally tells you that it won't work for you.

The original agile manifesto is silent on the topic of management. Self-organizing teams are a good practice, but once you scale up and have to coordinate the work of many teams across a huge portfolio it generally becomes necessary to have some level of hierarchical management in order to prevent chaos and dysfunction.

https://agilemanifesto.org/principles.html

I don't see how that "no managers" core can be true.

Many of the principles, like "Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale." are valid even for solo developer projects. Agile came out of older practices, like Rapid Development, which definitely could be used by solo developers.

Several of the principles do imply the existence of multiple people - #4 implies business people are distinct from developers - but still apply to a two-person company, like married friends I knew who ran their own software company where the wife handled the business and the husband the development and there was no manager.

If there are no managers, then either everything they do is Agile (because there are no managers) or nothing they do is Agile (because "Agile" can't be applied). If the former, then a solo developer following waterfall is Agile. If the latter then what alternative principles can be applied to solo- and partnership developer projects?

Which is why it shouldn't be no one's surprise that after 20 years we ended up like this.

I have been through multiple ways of doing agile, since the manifesto, and I really only saw it work on tiny startups full of idealistic engineers.

Every term has that property. If there's a thing called T you can say that the good Ts are "real Ts" and the bad Ts are "not real Ts". It means nothing to dismiss an idea because of this. In the No True Scotsman fallacy, the fallacy is not the definition of the word "Scotsman", it's the use of arguments of this form.

AFAICT the "not true scotsman" is motte-and-bailey applied to the definition of a word - the fallacy isn't the original definition of the word "scotsman", the fallacy is re-defining the word to mean something different and more defensible when you're challenged, and then to redefine it back to the original definition later, to re-include all the insufficiently-burly scots.

I've also argued that "agile" means "not waterfall".

It's easy to criticize. What specifically are you proposing as an alternative that will allow software organizations to reliably deliver value to customers?

Agile isn't there to reliably deliver value to customers, it is to reliably deliver status updates to clients.

That's the thing, though. Agile tries to accurately measure the progress as well as predict the time cost of the immediate future. It doesn't propose to predict the full time cost of an entire project.

Lots of methodologies do promise that, but they all seem to end up even worse. I know I don't want to go back to the waterfall days of requirements gathering for weeks, then being held to a schedule that was built entirely on hypotheticals.

What works is to have a competent team that cares and aren't hindered by bureaucracy. Agile is one such obstacle that prevents people from getting things done.

Agile might be a good way to deliver value if you have sub par teams, I'm not sure, but I'm pretty sure it hurts competent teams since now you made it their job to deliver reports rather than improving the product.

> I know I don't want to go back to the waterfall days of requirements gathering for weeks, then being held to a schedule that was built entirely on hypotheticals.

Removing constant scheduled reports and meetings all the time does not necessarily mean waterfall where you frontload all those meetings and reports. You could just have meetings and reports that fits the project as needed instead of forcing a one size fits all solution to everything.

Agile and waterfall are both examples of the same corporate inflexibility.

Okay but that's not really actionable. There are only a small number of highly competent people available in the labor market at any price. Occasionally you can get lucky and hire enough of them to assemble an entire team, and the results can be extraordinary (at least until the ego conflicts destroy it). But since no large organization can rely on that strategy they have to find ways to deliver value using average people who might be incompetent in certain areas. That usually means some kind of agile methodology to provide a level of predictability and prevent things from going totally off the rails.

Clients and other stakeholders often need status updates and estimates to conduct their business. It may even be worth sacrificing some speed and value in order to have better insight into when it is likely to be delivered, so plans and coordination can happen accordingly. This is still hard to do, and perhaps the agile-branded methodologies aren’t the best way to achieve that objective, but that doesn’t mean that predictability is meaningless as a goal and shouldn’t be attempted. ”Hire competent people and when they’re done, they’re done” doesn’t necessarily produce the best outcome for an organization.

Heeeere we go

Are we not allowed to criticise unless we have a superior alternative to provide?

Criticize all you like. But if you want to actually effect positive change then you'll have a lot more success with proposing specific improvements. Otherwise your co-workers will tend to perceive you as a whiner.

There is no single easy answer, and I'm not a management consultant so I have no interested in trying to sell one. You simply have to do the hard work of understanding the constraints you are operating under and exercising good judgement on how to work in that environment.

And, now I eagerly await the dozens of replies I'm going to get telling me that exercising good judgement and common sense could only mean that I am in fact following the True Agile (unless it doesn't work, then it was obviously No True Agile process).

"Object-oriented" is another such example.

Reply on news.ycombinator.com