Hacker News Reader

Comment by dijit | Hacker News Reader

There's an interesting phenomenon that Agile (capital A) has exposed me to, and once I saw it due to Agile I've seen parallels elsewhere.

In that: if it fails, it is only considered evidence that you were not doing it enough.

The solution can never be at fault, it's your execution, or your devotion to the process (in this case) that was faulty.

It's also true for Cloud providers; that they're not suited for certain tasks is no longer considered an engineering trade-off, it's that you architected your solution wrong, and the answer is to buy even more into how the platform works.

If your microservices become slow or difficult to debug, it's never that fatter services could have been preferable, it's that we didn't go hard-enough into microservices.

If Austerity is not working as an economic model; the answer isn't to invest in growth, it's to cut even more corners.

I feel like I see it all the time.

View on HN

My favorite Agile-ism is when Agile is defined as “the process that works for the team”.

If a team adopts agile (in any variation) and doesn’t like it, the Agile defenders will appear and argue that the team wasn’t actually doing agile. Agile is defined as the process that works, so if it didn’t work it couldn’t have been agile. If only you read The Agile Manifesto you would understand!

Another way of phrasing this though, is that it's in the team's power to determine process (or the lack thereof).

Regardless of success or failure you can say to what degree this is true, and to me this is really that only part of "agile" that is worth locking in.

In the team's power to determine a working process but in the scrum master's responsibility.

If you use scrum, and if you have a scrum master. You categorically don't need to do either of those things though.

> Another way of phrasing this though, is that it's in the team's power to determine process (or the lack thereof).

Which they almost never have.

My definition of agile is that process is a knob that you can turn. You don't like how the process is working out for your team? Adjust the process. Find the sweet spot for your team. As your team changes size and/or members, keep adjusting.

"We're going to do agile by following this rigid process" is an oxymoron.

The problem is that "just do what works" doesn't justify a whole agile industry and not even two days of training.

The real claim of the agile industry is that they know what can work and that you can find it using agile. That also has real value - if true.

Wow I guess we were actually agile all along, by virtue of being a team that defines our own processes. Yet I don’t think we’ve ever used the word agile once in any of our meetings.

That's true, but most people / teams can't actually adjust the process.

> My favorite Agile-ism is when Agile is defined as “the process that works for the team”.

What compels you to believe it isn't?

I mean, read the Agile Manifesto. All it does is basically define a set of values and principles. Things like "customer comes first" or "we welcome changes in requirements" or "software must be delivered frequently".

What leads you to believe Agile implies a fixed set of precise, rigid rules?

The problem is a disconnect between management and those who build.

My thoughts when PE forced Agile on my employer were dismissed as "you're the technical expert, we're the process experts".

As someone without decision power, you read words of empowerment but your reality is a different one, and you're left resolving that dissonance on your own (quietly, otherwise you get pushed aside).

This is the problem with 'Agile', and why people refer to it as "Capital-A Agile".

As always, the problem isn't the process, the problem is the people. There's whole industries out there set up to sell A Process, so they come in and try to force something like this on you. They want to stay in business, so they need to make sure they have something to sell.

That's the dysfunction - a company that is forcing this laborious process on you, rather than giving teams the autonomy to figure out how they best work.

Agile works best as a toolbox of practices you can adopt, mix, and match to solve whatever problems you have. Do you need to work to a fixed schedule, or provide delivery estimates? You should probably have a way to regularly estimate your work. Are you struggling to actually ship and do things? Maybe it would be useful to plan things on a smaller, more frequent cadence.

> As always, the problem isn't the process, the problem is the people. There's whole industries out there set up to sell A Process, so they come in and try to force something like this on you.

I would go as far as to claim the problem is middle management types, who feel pressured to adopt buzzwords and want to micromanage things to cultivate an image of control and progress to justify their role.

It's the same type that brags about scrum but don't even bother to show in standup meetings.

> The problem is a disconnect between management and those who build.

That would clearly be a problem that falls well inside the domain "you are not doing enough Agile".

A key principle of Agile is literally "Business people and developers must work together daily throughout the project."

If a team suffers from that disconnect, it's failing Agile.

More to the point, whatever they are doing is not working, and Agile would fix it.

It isnt but the fact it ultra vague and hand wavey means anybody can claim anything they do is agile including things that the exact opposite.

I actually think OP's criticisms apply mostly to Scrum. Scrum is well defined but its adherents' wont hear a critical word said about it. "You just werent doing it right" even when you were doing it precisely as described.

> It isnt but the fact it ultra vague and hand wavey means anybody can claim anything they do is agile including things that the exact opposite.

I don't really agree. The set of principles are quite straight forward. It's things like delivering software frequently, accommodating new requirements, continuously looking into improving processes, business types and developers working together, etc.

Then you have concrete executions like scrum vs kanban. Agile doesn't specify one or the other. Retrospective meetings are popular, but aren't specified by Agile per se.

> What leads you to believe Agile implies a fixed set of precise, rigid rules?

How it's been implemented at every company. They are always a fixed set of precise, rigid rules.

The fact that you spell agile with a capital "A" says all I need to know.

> Agile is defined as the process that works

Can you show a reference of where it is defined like this?

    At regular intervals, the team reflects on how
    to become more effective, then tunes and adjusts
    its behavior accordingly.

https://agilemanifesto.org/principles.html

I think the confusion comes from considering Agile as a process instead of a set of values and principles. The Agile Manifesto only talks about values and principles(https://agilemanifesto.org/). Values are not right or wrong, they are just values you agree to or don't.

The problem mostly arises when processes are shoe-horned under the guise of 'Agile' in setups where they might not be the best fit by so-called process experts under pressure from management which does not know any better. The authors of Agile Manifesto have frequently said the concept of Agile has been badly twisted.

I think it’s long past the time where we can pretend that The Agile Manifesto is representative of what the word “Agile” means in tech companies.

The manifesto is a minimal set of principles but every real world Agile shop I’ve interacted with has subscribed to a set of processes that everyone in tech would recognize as “Agile”.

The manifesto has become a safe retreat that agile fans bring out whenever someone has criticisms about real-world agile; Whenever someone has a complaint about Agile as implemented in the real world, someone will show up and try to defend it by pointing out that The Agile Manifesto doesn’t contain the specific thing they dislike.

The Agile industry moved beyond The Agile Manifesto almost as soon as it was popularized. We can’t keep returning to it as some safe home base that shields Agile from any criticism.

Industrial Agile is mostly Agile Manifesto with the negation of the first principle (Processes and tools over individuals and interactions).

"Industrial" cannot rely on any one individual. You have to be able to scale your process (or whatever), duplicate your process, have your process survive multiple people leaving, and so on.

Which means that any true agile cannot be industrial. And therefore any industrial agile cannot be true to the principles of the Agile Manifesto.

At this point I equate the Agile Manifesto to the Communist Manifesto. Sounds nice when you read it; in practice it is an absurd endless source of suffering.

>The Agile industry moved beyond The Agile Manifesto almost as soon as it was popularized.

Yeah, spending the amount of words in this thread trying to diagnose or complain about this simple problem in abstract strokes seems silly and frankly confounds me when considering the amount of time people wish to waste discussing the problem.

As with political parties, bad gentrification in cities, and all the rest, once money and consultants turn things into an industry you're pretty much fucked.

People should just immediately stop taking people with conflicting interests at face value when they talk. Stick to concrete details when you talk about stuff, avoid industry terms, don't let them turn things into abstract and general discussions. It only feeds the trolls (consultants) when you even complain generally about it.

Fight it with your day-to-day actions, not so much with your words. And then let it die in silence, it will die faster (I'm referring to any tech topic captured by consultants and monied interests).

I suspect there might not be love for this angle here, but there's something else that follows this format: God. Spirituality. Religion.

I'm not religious is any traditional sense, but I'd argue that it's not always the hallmark of a bad dynamic when a system always asks of you to do inner work when failures happen in contact with the real world. Sometimes that's a healthier mode than the alternative -- externalizing the blame, and blaming the system (or the god).

I suspect there a very abstract game theoretic conversation that could be had about this :)

> I suspect there might not be love for this angle here, but there's something else that follows this format: God. Spirituality. Religion.

Yes, and that's because God, spirituality and religion make fuzzy truth claims and can be used to argue for and justify anything. God can be used as the excuse to start a genocide and the inspiration to stop it, spirituality can be the way for wounded people to work with their trauma and the vehicle for people without scruples to sell horoscopes or some shit, religion (the same religion) was used to justify and uphold slavery and to fight for its end.

They are containers for our politics, our lifestyle, for who we are and for who we hope to be.

The Agile manifesto is a series of statements in the form "we like X more than Y." It doesn't say anything. To make it mean anything you have to project onto it a framework of interpretation that exists independently of the "sacred text" itself.

So yeah, they are similar, and that's because Agile, sociologically, works like a religion.

when it comes to some diets, some only work if you follow them wholeheartedly, like meat only diet, one speck of peppar might be enough to cause an inflammation. But generally you can't take a process that worked well for another person or company and apply it on you or your company. Like for example a training program, you can't just take a training program from a professional athlete and reuse it on your kid and expect him/her to become as good as the pro. Programs and processes are very individual tailored.

I'm pretty sure a religiously followed meat only diet can't succeed at anything other than achieving scurvy.

Meat have all vitamins. But if you plan to stay on the diet forever you should eat all parts, not just the steak.

Ah, fair enough.

I still doubt that your average person would see any real health benefits from eating only meat, even if they ate enough organ meats to actually get all their vitamins and minerals (the lack of fiber is a particular concern) but I guess you're right that there's a version of an "all meat died" that doesn't promptly kill you through malnutrition, you got me there.

It's really a hard-core diet and not for the average joe, the health benefits however are great: Fat loss, especially around your belly (because belly fat act as a protective barrier, and will go away if you don't eat carbs) and the inflammatory processes in the body will go down a lot. You will look more healthy and feel stronger. Just make sure you get enough calories, so you need to eat a lot of meat. You have to spend hours every day just eating.

A process that fails when you slightly diverge is process that fails. Because all human orgs diverge from stated process here or there. Including army which puts huge amounts of resources into making people comply with everything.

It's usually because your company doesn't fundamentally want it. You cannot have roadmaps with lists of features that you advertise to customers AND have the flexibility to decide to ignore things that turn out to be useless or disporportionately time consuming.

If someone handed you a plan for making a jet engine and you messed around with the instructions ... why would you expect it to work? If you have a bug because there are not enough tests ... you write more tests don't you? Why would a method be forgiving when compilers and reality itself aren't?

But that isn't evidence that the method works. If you're a native tribe, that has an ancient traditional rain dance, it is invoked whenever there is a drought. Sometimes it rains shortly after the dance is performed. But if it doesn't rain, it's not proof that you danced poorly, it's evidence that you didn't understand the situation fully or properly. The instructions or "wisdom" you relied on, didn't actually capture something useful.

My evidence is that I was on a team that was not overly controlled by management and had clever people in it without any instant attitudes of rejection so they adapted to it. We produced updates bi-weekly and we had a huge backlog of stupid features which we were never going to get round to - we were able to get the important things done and it was one of the best feelings I've ever had about work.

Since then I've been on teams with any number of pathologies. From developers it is sometimes the desired to be special - those ones who want to work on their bit of the code and not let anyone else touch it. From managers it's things like forcing the way stories are split so that they're always too large and can never fit into a sprint - because they think that everything must be a "user visible change". Management types also sit in retrospectives and use them to crap on everyone. Product managers demand features which they don't know will really interest customers and are inflexible about them - they want "everything" just in case and that delays the work and deletes any chance of a feedback loop.

The good agile feeling came from being able to have control and be successful. When it's messed up, you're out of control and cannot avert disasters. Whatever method you want to call it, I think we need to feel we're in control enough to succeed.

What is the chance that you've perfectly captured every aspect of the situation that led to success? Versus, what is the chance that you were lucky enough to be in situations where a multitude of factors, both appreciated and unappreciated, combined to lead to success?

There are a million possible reasons for failure, but here is a very easy one: It doesn't matter how good you feel about the development process, if the company has the wrong objective. You will still end up being frustrated, and failing. Of course this will have all sorts of pathological and uncomfortable ramifications.

So while it is easy to say, "just act this way and you'll have success". You're not actually appreciating all the hidden elements that allow any hope of acting that way. You've been lucky enough to be in situations where it happened to work (ie. the rain dance made rain), but that does not mean it's actually representative, or that the prescription actually captures the critical information needed to ensure success for other people. Instead, you've described a rain dance.

You're right - there isn't one way to do things or one way that always works. There are issues that are outside a team's control, for example, that make it an impossible struggle. If you're rigidly forced to do something and cannot adapt then you're ... not really agile. But you have to understand why you're doing what you're doing and keep adjusting to see what works for you.

#1 IMO is that if the company you're in is non-agile in its general attitude, which is influenced by its own customers, then everything is geared against you.

That isn't to say that something like Kanban might not be usable or better than no plan at all but certainly scrum is not some universal solution.

> It's usually because your company doesn't fundamentally want it.

BINGO. Managers and execs want (or get sold on) "agile" but only want it to affect the structure and processes for the very lowest-level workers. They don't want to change the organization or what they do, and odds are those are really bad and won't let most systems like this, agile or otherwise, function properly.

(The big secret is there's no framework like this that "works" for fixing broken organizations; there are [rare!] well-led well-managed organizations where damn near any halfway-reasonable system they choose will work, so if they decide to do Scrum or whatever in places like that it'll work just fine—and then there's everyone else)

This is a great point! Reminds me of Agentic software development. When it doesn't work out it's only evidence that you could have used more agents.

You can never use enough tokens.

Which also conveniently makes you spend more money on tokens.

With agile, at least no one was charging you for it. Like sure, there’s a cost to the process. But there wasn’t direct agile.com profiting from you.

Meanwhile agentic workflows every solution to the problem is giving more money to the ai companies.

Model is bad? Made more expensive model. Still bad? Here’s an infrastructure that reads huge text files again and again making you consume tokens. Still bad? Here’s a way to easily spin up multiple agents at once so you can delegate work. Still bad? Here’s a new service that will automatically review code. Still bad? Maybe a biggger more expensive model will help.

>> With agile, at least no one was charging you for it.

Depends. There are companies [1] making loads of money out of it. Charging for certification and imposing the idea that either you are certified, or you are going to fail. They are even eating the lunch of PMI, as PMI (PMBoK) is turning into an Agile manual. Where I work is being expended literally millions per year in Agile.

[1] https://scaledagile.com/what-is-safe/

> With agile, at least no one was charging you for it.

Charging people for Agile via his company ThoughtWorks (which sold for 785M) is how Neville Roy Singham made the money to fund far left groups in the US from his base in China.

> This is a great point! Reminds me of Agentic software development. When it doesn't work out it's only evidence that you could have used more agents.

A concept older than agentic software development is bad workmen blaming his tools.

I mean, if you can't possibly hammer a nail then is it reasonable to blame the hammer?

If it's an internet-required smarthammer without a handle that instead hits out on voice prompt, sometimes without enough or with too much force, sometimes knocks the nail out of the way and punches a hole, and sometimes hits you in the face, then yeah

> If it's an internet-required smarthammer without a handle that (...)

A suitable comparison would be to be faced with a nailgun and proceeding to criticize it on the grounds it doesn't have a handle, it doesn't pull nails, and it requires electricity to run.

While you complain about those detailed those using nailguns are an order of magnitude more productive at the same task, and can still carry a hammer in their toolbelt.

I originally was writing the post using a nailgun, but decided someone would criticize it for straying too far away from a hammer. Alas.

> I originally was writing the post using a nailgun, but decided someone would criticize it for straying too far away from a hammer. Alas.

The point is still unaddressed, isn't it?

Well, no, the examples are basically the same. A wifi nailgun that sometimes shoots a nail straight through the board, doesn't shoot one at all, shoots it randomly to the side, shoots you with it, etc.

Clearly they didn't use enough hammer. Screws always require the most hammer. Common knowledge to any certified practitioner of Hammer™[1].

- [1] Get 20% off your Hammer Master™ certificate with referral code THUMBPAIN

You can use brick as hammer. Doesn't mean brick makes a good hammer or that person who tells that brick is a bad hammer and doesn't work from them is bad workman.

> if it fails, it is only considered evidence that you were not doing it enough.

Or not doing it properly. And I understand the suspicion, I really do; but in hindsight, if you honestly tried to review how an organisation was operating, would you sincerely be able to say that it was adhering to a certain agile methodology/framework/mindset/strategy/whatever?

I have so far not see an organisation that would be following scrum, as it is described in the scrum guide; or kanban, as it is described in the kanban guide. I have seen or heard about various organisations that use these words, but they have little resemblance to what was actually proposed. So I can't really say if agile (or any of its particular variants) work or not. I have not seen honest experiments properly run.

> I have so far not see an organisation that would be following scrum, as it is described in the scrum guide; or kanban, as it is described in the kanban guide. I have seen or heard about various organisations that use these words, but they have little resemblance to what was actually proposed.

If that's true, wouldn't it point at the process being impossible to implement?

It is a myth. There exists a version of Agile that could be implemented, and it would be the true Agile. The pure, honest experiment that would just work, because Agile cannot fail, you can only fail to Agile.

It signals to me that the process doesn't work in reality. You are better off doing something else.

It doesn't really fail any worse than other inflexible top-down process mandates from management.

That's where it becomes "impossible to implement"—you can't impose it as a cookie-cutter solution driven and controlled by management, and get much good out of it, yet that's the usual way it manifests in the wild. But that's not so different from anything else management might push in its place.

> There exists a version of Agile that could be implemented, and it would be the true Agile. The pure, honest experiment that would just work, because Agile cannot fail, you can only fail to Agile.

"Agile" is a very vague and shapeless idea which is hard to design an experiment for; but I would settle for clean experiments with well-defined methodologies/frameworks/strategies/whatever. Specifically, for scrum or kanban. Whenever people talk about these two, they seem to misunderstand them more often than not.

>It signals to me that the process doesn't work in reality. You are better off doing something else.

Whatever you do instead, you will also cargo-cult to some degree and fail equally as badly at.

For all the "You're doing it wrong!" I've seen in industry with respect to agile, I've also felt that every team I've been part of that did some version of it, seemed to function OK. I always found the "Agile Manifesto" a completely silly nothing-burger, but always understood the core tenet of 'agile' to be "employ tighter feedback loops", which... is sort of mostly how it plays out in practice??

I've belonged to numerous teams that followed some form of agile, to varying degrees of success (or failure).

The shape of what Agile meant in each of those teams was very different from one another. It would be disingenuous to say "the ones that succeeded were truer to Agile".

If Agile can be summarized as "employ tighter feedback loops", the whole Agile thing was beyond useless. A single sentence, as useful a tenet as it may be, does not a philosophy make. And this idea was not even new by the time the Agile manifesto came out (as explained in the linked blog post).

> If Agile can be summarized as "employ tighter feedback loops", the whole Agile thing was beyond useless.

Not just that, Royce's original paper that coined the term "waterfall" in 1970[1] can be summarized as "employ tighter feedback loops" compared to top-down design (figures 2-4 in the paper).

[1] https://www.praxisframework.org/files/royce1970.pdf

Useless as it might seem, I really do think it is actually that basic. Is it useless? Hardly. Take out feedback loops and see what happens.

The tenet was not useless. But it was not bought forth by Agile. It already existed.

And if this tenet is all Agile is, then it contained zero new ideas or contributions.

It seems to have successfully popularized it though.

> In that: if it fails, it is only considered evidence that you were not doing it enough.

I think you are purposely omitting the fact that those failures have root causes that come from violating key Agile principles.

Things like "we started a project without a big design upfront and we accepted all of the product owner's suggestions, but whe were overworked and ran out of time, and the product owner refused to accommodate requests, and when we finally released the product owner complained the deliverable failed to meet the requirements and expectations".

This scenario is very mundane and showcases a set of failures that are clearly "not doing enough Agile" because it violates basically half of them.

> The solution can never be at fault, it's your execution, or your devotion to the process (in this case) that was faulty.

Agile is a set of principles focused on the process and its execution. What compels you to talk about Agile and pretend that processes and execution are anything other than the core topic?

If your stakeholders change requirements but don't change allocated resources and fail to stay up to date in the daily affairs to monitor and adapt, how is this anything other than glaring failures to adhere to basic Agile principles?

https://en.wikipedia.org/wiki/No_true_Scotsman seems pertinent here.

Yes, but on the other hand, there's https://www.reddit.com/r/ididnthaveeggs/, which collects cases of home cooks making inadvisable recipe substitutions and then complaining to the recipe creators that the resulting dish tasted bad. Sometimes there are essential ingredients and skipping them or replacing them with something else makes success impossible.

An appealing analogy but recipes have defined testable outcomes. You know what a Victoria sponge is supposed to look like (there's probably even a picture of one in the book). You can perfectly evaluate when a substitute has ruined it.

Agile doesn't have that, there is no functional equivelant of "the cake should be moist and rise evenly". What does "Agile" adoption look like? Faster delivery? Happier Developers? More revenue? Fewer bugs? This is never defined up front and they shift depending on the person being asked. This means you can never actually determine if someone "left out an essential ingredient".

The irony is that Agiles own favoured development practice (TDD) cannot be applied to Agile itself. There is no acceptance test for the process, you can't iterate on something that isn't measured and has no defined outcome.

/r/ididnthaveeggs works because everyone agrees on what the dish should have been.

> Agile doesn't have that, there is no functional equivelant of "the cake should be moist and rise evenly".

That's not true for the way I understand agile. The way I understand it, the testable outcome is whether the principles of the agile manifesto are satisfied

For example, is your highest priority to satisfy the customer through early and continuous delivery of valuable software? If not then you're not agile.

https://agilemanifesto.org/principles.html

There is one and only one essential ingredient of agile, and it's feedback loops. That's all agile really is. The employment of feedback loops.

I mean, Switzerland and North Korea both call themselves democracies but the specifics matter. The specifics matter!

These discussions are always fascinating in a sort of baffling way to me because I've only had great experiences with what I call agile. Like, you bring it into the team and within months everyone is gushing about how much better life is now. Yet threads like this one are full of people reporting awful experiences.

Apparently whatever it is they're doing involves a lot of meetings and little actual flexibility? The deeply unexpected thing about that, to me, is, if they hate some parts of the process, why are they keeping them? Every team and every business is different and you have to iterate to arrive at whatever will work best for you. That's possibly the one most important point, IMO. Dropping the things that don't work is a key part of that!

Eric Brechner of Microsoft (of all possible places...) gives a great talk on his team's approach, and I've had good experiences using it as a starting point: https://www.youtube.com/watch?v=CD0y-aU1sXo

But again, every team is different. Even the greatest possible theoretical approach is only a starting point.

And like with Switzerland vs North Korea, I guess the key thing is how much ownership of the process those subjected to it have?

> The deeply unexpected thing about that, to me, is, if they hate some parts of the process, why are they keeping them?

Why are you assuming that they are given a choice? In my experience, whenever a team is trying "agile" in some way but hate it AND are given the choice, they drop it ASAP and are 100% convinced that they are better off without it. Those that hate it and don't stop doing it, are doing so because they are forced to.

> Why are you assuming that they are given a choice?

Because self-determination was the defining component of every agile deployment I've ever been involved in or personally driven. I don't think I can really picture what something calling itself agile yet lacking this component would even look like, honestly -- hoping you will forgive me this failure of imagination.

> whenever a team is trying "agile" in some way but hate it AND are given the choice, they drop it ASAP

Isnt that in itself "agile"? And I specifically dont mean following a religous ceremony plan etc but recognizing that a part of their process isnt working and then changing it. To me thats the entire point of actual agile. You try a process, it doesnt work, you analyze, and adapt.

Ideologues are everywhere.

If it isn’t presented as a theory that might be proven wrong, or an idea that might not work, that’s when my alarm starts going off.

Another signal: trying stuff we already tried that didn’t work, usually with an unconvincing reason why it’s different this time.

In many contexts "already tried" does not apply under "this and this conditions" though.

You can try the same thing under different contexts and it will probably yield different results (at least in any context that is organizational / social)

But is it wrong? If you're in a plane and it's on the ground and it starts moving but it doesn't take off, the answer really is to move faster. If you press a button and it doesn't activate, the answer might just be to press harder. If you're running away from a bear but it's catching up to you, the answer really is run faster. If you don't, you're dead.

So the problem with that is that it's an oversimplification in an attempt to sound smart and insightful and can't be used as a general principle to reason as to whether or not you need to double down to see results.

all of those examples have a known causal mechanism and a measurable outcome.

I know, right? If only the rest of life was that easy!

>I feel like I see it all the time.

Sometimes its justified. Like "This is only satisfied when x, y and z are correct"

But then you get

"We will do x and y as a compromise but not z"

And then you have to explain that, the compromise is actually worse.

> "We will do x and y as a compromise but not z"

This reminds a lot of this: "I'm going to try this extremely difficult pastry recipe at home, but I'll use margarin insted of butter because <idiot reason> and a teasponn of stevia instead of the prescribed 200 g of sugar for <another idiot reason>."

> In that: if it fails, it is only considered evidence that you were not doing it enough.

Seen this multiple times

The problem is agile as in the original manifesto was an ethos, not a process.

Everything since the manifesto, called agile, has tried to wrap an ethos up as a process, playing lip service forgetting the ethos.

High performing teams are already doing agile, following the ethos without attempting to be agile. High performing teams made to do agile become average teams and low performing teams made to do agile can become average teams.

> High performing teams made to do agile become average teams and low performing teams made to do agile can become average teams.

This is also my observation. I compare it to McDonalds vs a star restaurant. Put the top chef of a star restaurant in McDonalds and he will perform average. Put a McDonalds member in the star restaurant and he will perform badly.

The amount of process needs to be tweaked to your team. Ideally, you can give your star players more freedom.

> In that: if it fails, it is only considered evidence that you were not doing it enough.

> The solution can never be at fault, it's your execution, or your devotion to the process (in this case) that was faulty.

This isn't some religious premise, it's the lesson of bitter experience. It's like how when two trains crash into each other the inspectors start by looking for which one went through a danger signal, rather than questioning whether signalling systems work.

Isn't this type of reasoning okay to an extent until you (or in more humbling cases, someone else) points out it's no longer working?

Sure. Occasionally there really is a problem in your signalling system. Even more rarely there's a fundamental design flaw.

If and when I see actually-doing-agile fail, I'll change my mind. But so far I've seen a direct correlation between the extent to which an organisation was actually-doing-agile and the effectiveness of that organisation, across a wide range of industries/environments/countries.

If AI fails, you wrote the prompt wrong.

I feel like Agile is just a tool. You adopt it, or parts of it and see if it works. If it does for your org awesome, if not for your org, try something else.

Organizations are all different IMO (even if slightly), and you gotta try things and move on.

Is it the fault of Agile if it doesn't work? I don't know, I'm more interested in finding what works.

That's why you need to evaluate things by their outcomes. It's the same as weightlifting, if you get injured, "you didn't have good technique".

If your thing sometimes harms people, for whatever reason, your thing isn't safe enough, or easy enough to understand how to do safely.

> In that: if it fails, it is only considered evidence that you were not doing it enough.

In my experience, when it fails there's always someone to tell you that you were just doing Agile wrong and they've got a different brand of Agile and a training course to sell you

reminds me of the impossible fight for when someone forces themselves into a project and prescribes "industry standard" off-the-shelf solutions, to a problem that requires an engineered custom solution.

And when the final product isn't fit for purpose, what do they say when their decision becomes visible?

the off-the-shelf solution is never at fault. It's your execution. You architect your solution wrong. You didn't configure it right. You just didn't adopt it fully enough. The answer is always to dig deeper into the solution and leverage more of its features.

The problem is that the off-the-shelf solution doesn't even have the right feature set needed for the job in the first place.

"If you failed it is only evidence that you were not doing enough." is the core principle the whole self-help, self-improvement and large parts of weight loss and health industries always have been based on.

> If Austerity is not working as an economic model; the answer isn't to invest in growth, it's to cut even more corners.

The do-more-with-less cancer that is infecting so many companies, where the tumor is Continuous Growth.

I've seen similar effect with Montesori, Waldorf, Kumon methods. If something is wrong, is because it was misunderstood, or not properly done.

This applies to everything. If your coding agent has problems with non-trivial programs, it's your fault, too.

I actually agree with you but I love that the response was just a long version of "you're not doing it right!"

If brute force is not working, you are not using enough.

Aren't these just examples of sunk cost fallacy?

Yup. Agile definitely suffers from the "nobody ever tried Communism correctly" argument. As far as I'm concerned Agile is: A) nearly impossible to get right, and B) not particularly helpful at unfucking poorly run projects.

It's definitely not a magic bullet and I suppose the only reason it's had the staying power it has had is because unlike other project management philosophies, it has an extremely profitable "Agile Seminary" ecosystem.

> I feel like I see it all the time.

That’s because it’s a common trait in ideologies. It predates Agile by a couple of millennia. We could add to your examples things like "if it failed, it means you are not pious enough; make more sacrifices", or "if the offensive fails, it means that you are not committed enough; bring more men and more artillery", or "if <whatever totalitarian idea> fails, that’s because people don’t believe enough; purge them". There are many, many examples in History.

This is the horseshoe theory of Agile. If you do Agile hard enough you end up at SAFe which is basically waterfall.

Waterfall disguised with other names and extrem expensive certification.

> if it fails, it is only considered evidence that you were not doing it enough.

20 years ago, this was the meme about XML.

More seriously, this was also the answer about Communism.

Communism comes to mind.

It's led to misery every time - but it's always because they just "did it wrong"

> In that: if it fails, it is only considered evidence that you were not doing it enough.

This is a cult tactic, for what it's worth

> In that: if it fails, it is only considered evidence that you were not doing it enough.

Good way to ensure devotion to a process rather than devotion to a desirable outcome. Seems distinctly cult-like.

It's basicy gas lighting at this point

Isn’t Communism the original here? It’s often claimed that all historic attempts to establish Communism don’t work cause it wasn’t done in the right way.

In all seriousness, this pattern is probably hard to avoid in any reasonably complex entity/environment. If any such situation would be solved in a global solution (aka silver bullet), it would be used by everyone. As this seems not possible, any framework like Agile, Communism, … can only be a guidance to be applied locally, and broken internally and by external factors in many ways

Religion. Your life isn't better because of {not devout enough, didn't self-flagellate enough, didn't donate enough to the religious leaders/church/god, committed some other sins, belief is lacking}

Dude, this mode of ex post facto rationalization is waaaay older than communism. It's basically one of the main "retention warnings" of most religions.

Strategic Bombing - the idea wars can be won from the air alone - is the absolute worst of these. It's a religion that might well someday kill us all, or a great many of us. In the quest to dot it "enough" . . .

On a lighter note . .

The world of overly-complex CCS (component content systems) like DITA has made this "Agile flavor of treadmill[1]" into the entire business, greased with liberal squirts of FOMO and "Industry Standards".

It rhymes with capital A Agile in many ways, although in the case of DITA specifically I'd posit that the underlying assumption of the spec is a vast category error: that natural language has formal types.

[1] i.e., "you aren't doing it properly" . . . and with every change in technology the DITA / XML priesthood claimed to hold the keys to unlock it. SEO? Information Typing. Web Content? XML/XAL pipelines. Big Data? Content granularity. LLMs? Information typing and schema will "help" llms and not just be an unholy clog in the guts of vector embedding operations. And yet, the years go by, and all of it has worked and continues to work fine without switching the world to DITA (and a writing universe of strict validation based on speculative assumptions).

Reply on news.ycombinator.com