From "scrum masters" to "planing poker" it's all very silly.
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.
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
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'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 :)
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.
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.
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?
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.
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.
Good way to ensure devotion to a process rather than devotion to a desirable outcome. Seems distinctly cult-like.
You can never use enough 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.
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.
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 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!
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?
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).
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.
This is a cult tactic, for what it's worth
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?
Oh that was it you're right. We have those documents but they are full of lies. Yet everyone can read it and believe it to be true in the way they want it to be.
It was really telling at a smaller company that was trying to behave like a big company. I asked a coworker (who had great metrics) what the secret was for dealing with the middle-management-heavy and quite dysfunctional environment. He told me how he did it. Paraphrased: "It's easy. During each sprint, I work on the next sprint's work. Once it's complete I'll know how to make sure things match the work that's already been done and that way its always a bullseye and on time - because the work is already done.". Agile at that company was a joke to the people who got things done, and was a weapon used against people who didn't realise it in time. It sure generated a lot of metrics and stats though. I used to joke amongst coworkers that the company produced metrics, not products.
So this sprint shows what you delivered 2 sprints ago, next sprint will be the work you just finished.
Put your hand up if you are ever programming with poor specs?
Put your hand up if you have a better idea of what really was wanted after the first cut?
And what I really dislike is those that try to design a Swiss Army knife from day one when they haven’t a clue. Jump immediately into over complexity.
For reference, here's all the Agile you need, it's 4 sentences:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
The real problem is that capital-A Agile is not agile at all, but exactly the opposite: A fat process that enforces following a plan (regular, rigid meeting structure), creating comprehensive documentation (user stories, specs, mocks, task board) and contract negotiation (estimation meetings, planning poker). It's a bastardization of the original idea, born by process first people who tried to copy the methods of successful teams without understanding them.
"Oh, feature no 32 is going to take months and we realised that users can just...."
"No"
I have worked at an org where team members were not allowed to create tickets because that was the scrum master's job and the product owner had to approve all tickets etc. Who can even think that is a good idea??
Not sure what the solution is. There might not be any.
Isn't that the biggest issue here, though? I think all of us can agree on the four sentences you wrote, but this only works in a team of professionals with shared goals (and alignment on them!), each individually competent and motivated.
That is the case for a small founder team and maybe a while after that if you're lucky, but IME the more people join a company, the more the alignment and median expertise lessen. At some point, you need to introduce control mechanisms and additional communication tools to rake in the outliers.
I don't really have a better answer, though…
This is just a confusing and confused article.
Agile just finally embraced that specs are incomplete and can even be wrong because the writer of the spec does not yet really know or understand what they want. So they need working software to show the spec in action and then we can iterate on the results.
We are still doing that and will be doing it in the foreseeable future. Agile is very much alive and here to stay.
It is not something invented by the Agile proponents.
They have proposed a much more specific variant of iterative development, which at least as I have seen it implemented in any company which claimed to implement it, was really bad in comparison with the right ways of organizing development work, which I have seen elsewhere.
Any high quality product must be designed starting from a good written specification. Obviously, almost always the initial specification must pass through one or more update cycles, after experience is gathered through the implementation. This has always been universally used, not just by Agile practitioners.
There have always existed bad managers, who wrongly believed that a development process can always be linear and who did not include in their timelines the necessity for loops, but that was just bad management, so if Agile proponents pointed to such cases, those were just strawmen, not the best existing practices.
Lewis is right that most of these principles were described before the manifesto, but I can vouch for the near-impossibility in many contexts of convincing anyone who wasn't a coder (and a lot of coders too) why these might be sensible defaults.
For every person burned by a subsequent maladaptive formalization of these principles, there was someone horribly scarred before the agile manifesto by being forced to go through a doomed waterfall process.
Ask anyone with 30 years in the industry whether "agile", for all its problems, was a force for good or bad, and the answer will be an emphatic Good!
If nothing else, it gave us ammunition to argue against the impossibility of delivering a fixed thing in a fixed amount of time - which was the universal view from senior stakeholders of what competent software delivery looked like.
The tagline from the handbook: "Agile started with a manifesto. It ended with Jira."
Handbook: https://agile.flights/docs/introduction/why-flights/
Engineering (even in computing) has a formal basis and practice. Project management does not. Systems thinking and industrial organizational psychology does, but rarely do you see it applied like bullshit such as agile (and in environments that do - it works spectacularly).
Out with the voodoo, and in with the scientific method, I say.
Hell, half the devices in your life probably run some hacked together crap that was built by people who barely knew how to program and eschewed version control for USB sticks.
I really hate discussions of "software" as if the software in an F-35, the software presenting data on a webpage, and the software making a child's toy blink and speak are all the same thing. Only in a very abstract sense are they similar.
For 20 years, I have seen it working and not working, and the reasons are a lot. It can be affected of level of expertise, quality of documentation, pressure from management, engagement of the clients, etc.
Simple example of failing, and how one of my team overcome it. There is no specification. Option 1: team complains that the specification is bad, and this makes the code quality bad. Option 2: the team pro-actively prepared the specifications, gave them to the client for approval. Writing the specification was, a kind of, added flexibility, that was introduced in the sprints.
Another example, why should the sprints be fixed at 2 weeks. Sometimes, people try to finish for two weeks and they produce bad quality code, because they are time pressured. Be flexible and make them 3 weeks, if the sprint includes things like, preparing specifications, or if the sprint includes pauses for bug fixing. :)
So it is not the Agile that makes the project successful, it is the people. Agile just help for tracking where you are , and what you need to do ;)
Now with AI, you can use Agile again, there are agentic frameworks that support it and they give good results, in my opinion. If the people use it wisely, think what they do, and try to do things better, it will work. Of people are lazy, don't know what they are doing, don't have expertise on software development, it will fail :)
I bet some jerk is going to organize a multi agent scrum process at some point and burn some tokens on this nonsense.
The same is true of software. At first you try to make software, and you do, and it's kinda easy. Then you try to make more advanced software, and it seems much harder than it should be, as what you think will work doesn't. You spend a lot of time changing your design to make things work, which ends up not being exactly as you thought it should at first. Finally, after you master software development, things get easier and work like you expect.
In both cases, when you are ignorant, you do the wrong thing, and it works despite your ignorance, because you're doing an easy thing in the most straightforward way. But then you get cocky and try things that aren't as easy, and suddenly the straightforward way doesn't work anymore, because complex things never work the way you expect. Finally, after you've screwed up doing the thing enough, you remember what not to do, and now you can do it without the mistakes. But you're just not-screwing-up the things you already screwed up once before. You'll still screw up new things, because you haven't learned them yet. And you'll screw up again when you forget a past screw-up.
What separates the woodworker from the software engineer is, the woodworker doesn't make a lot of different things, and doesn't use a lot of different ways to do it. The software engineer is constantly doing new things, in different ways. So the software engineer is perpetually rising to their level of ignorance, while the woodworker stays mostly within their level of competence.
This is why there is no system in the universe that will be better than any other at software development. Agile, Waterfall, or anything else, doesn't matter. As long as you keep doing new things, you'll never not be screwing up. But stick to one thing and master it, and it doesn't matter how you do it.
That’s it. Whatever process it takes to get that occurring (without burning people out) should be the goal.
In my experience this fails if 1) Designers and engineers are bad at breaking down their vision into iterations, or 2) Managers are bad at breaking down their vision into iterations, or 3) Stakeholders don’t value iterations. And people get pissed off when asked to do something they’re bad at…or they’re good at it but others don’t value that ability.
But if agile is criticized... only worse alternatives are given, if at all. Here, spec-driven development is inferior, as in most cases the goal is only vaguely known. Cyclical development is not some hollow mantra, it is how life works. All the rituals around it were just to faciliate more communication. A lot of people in this field just hate that, they want their tickets and to be left alone.
Now that implementation cycles are even shorter, there is even less manual need for coding, agile methodologies will be actually more prevalent.
smackeyacky•1h ago
Agile was always aiming to solve the wrong problem (that code is the bottleneck) but it turned out to be a massive lie exposed by LLMs.
It’s always the poor specs, terrible analysis and release constraints that kill projects.
DeathArrow•1h ago
So most of the problems are related to business people and not the development teams? Who would have guessed?
k__•1h ago
No, it aimed to solve the "out specs are bad and we need to iterate faster" problem.
"a massive lie exposed by LLMs"
No. LLMs add no insight about the problem and they expose nothing. They just help to engage this well-known problem with another tool.
prerok•1h ago
Agile is about working code instead of hundreds of pages of spec nobody reads.