alt Hacker NewsThere'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.
Replies
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!
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?
> 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 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 :)
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.
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.
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?
> 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.
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.
>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.
> 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.
> 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
If AI fails, you wrote the prompt wrong.
I've seen similar effect with Montesori, Waldorf, Kumon methods. If something is wrong, is because it was misunderstood, or not properly done.
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.
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.
> 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?
If brute force is not working, you are not using enough.
> 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.
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.
> 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.
Communism comes to mind.
It's led to misery every time - but it's always because they just "did it wrong"
[dead]
> 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
It's basicy gas lighting at this point
> 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.
This is the horseshoe theory of Agile. If you do Agile hard enough you end up at SAFe which is basically waterfall.
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
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).
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.