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
>It’s always the poor specs, terrible analysis and release constraints that kill projects.
So most of the problems are related to business people and not the development teams? Who would have guessed?
k__
"Agile was always aiming to solve the wrong problem (that code is the bottleneck)"
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
Agile never claimed that.
Agile is about working code instead of hundreds of pages of spec nobody reads.
mrloba
I really doubt spec driven development is gonna last. As before, creating working software and iterating on it is faster and makes it easier to understand what you thought you wanted but don't, even if it's vibe coded. So, hello agile, welcome back.
The point is the agent writes the specs and the human reviews and revises or asks for another rewrite that takes 90 seconds or less. So specs are both cheaper and better than anything I've seen before. They still get a lot wrong and it is hard to review them very carefully, but its easier than reviewing code to suss out design intent.
EugeneOZ
Absolutely awesome, thank you, Lewis!
DeathArrow
I wonder if there is no AI product yet which runs scrum ceremonies, assigns user stories in planning and computes story point velocity after the sprint ends.
mnsc
Oh no, the kids are going to invent agile again aren't they?
rcaught
Aigile
zer00eyz
Someone once described agile as this: Its just pantomime and posit notes... implying that the process (from the outside) was more performative than anything else.
From "scrum masters" to "planing poker" it's all very silly.
Cwizard
That’s Scrum you are thinking of. Not agile.
DeathArrow
But if Agile is going to die, what are Scrum Masters going to do?
Hamuko
Same as before: nothing.
FpUser
Lucky me, I've never had to say Hi Agile in a first place. It is a tumor. Been in programming since 80s. Mostly on my own except 6 years long stint at the company. Quit in 2000 from position of CTO
dijit
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.
jeremyjh
If brute force is not working, you are not using enough.
waschl
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
lopsotronic
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).
patcon
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 :)
tiew9Vii
> 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.
t43562
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?
protocolture
>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.
boomlinde
> 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.
andersmurphy
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.
Aurornis
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.
danw1979
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.
duped
> 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
somesortofthing
What does "writing specs" here actually mean? Every agile project I've ever worked on has had a design doc that laid out architecture, the basic shape of contracts, dependencies and so on. In fact, the agile artifacts(tickets, estimates, epics etc.) have always been downstream of a design doc source-of-truth. A project where all the work comes directly from tickets with no overarching, agreed-upon document on what the end goal is supposed to be sounds hellish.
jeremyjh
> A project where all the work comes directly from tickets with no overarching, agreed-upon document on what the end goal is supposed to be sounds hellish.
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.
darkhelmet
Agile, as implemented in every big company that I've worked for, was a lie.
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.
cbg0
I've also seen agile hollowed out to become a metric delivery system that keeps managers happy; They know what everyone is doing but it keeps upper management happy to see those metrics trend upwards so the wheel keeps spinning. The actual product ends up being a byproduct of the stats.
brigandish
How did he see into the future to know which work he'd be doing on the next sprint, and how did he also finish the current sprint's work with a bullseye thus allowing the next sprint's to begin and match it?
hcfman
The way the author defined water fall makes it sound pretty good to me.
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.
anilakar
Wasn't the whole waterfall model originaly a caricature to higlight all the issues one will inevitably encounter if they eliminate feedback loops and go with a strictly sequential development paradigm?
endymi0n
I've come to dread any formalization of Agile. Agile development is fine. I've built a 40+ engineering team with it. I can vouch for its effectiveness when applied to small, excellent teams.
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.
operatingthetan
I can't count how many times I've seen "agile" projects that were just actually waterfall due to demands from stakeholders.
bartvk
I don't get the negativity, there's plenty wrong with agile (notably the hours of meetings) but all in all, it's a method and I don't see anything better right now.
t43562
If your company doesn't fundamentally want "agility" then it will be an exercise in futility but if you're a person who doesn't want to do useless work then you're an agile proponent fundamentally.
prerok
TFA first claims that agile invented none of the things it encompasses, seems not to challenge those claims, but then just jumps to agile is dead because LLMs can code based on spec.
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.
dannyobrien
I think it's worth linking to the original Agile Manifesto[1], because that's pretty much all the consensus you're ever going to get on what's "agile" and "what's not".
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.
aryeh
Well put. This article gives the “old” truth. Typically, for other than the largest government, military, and industry projects, iterative development largely preceded agile. However, the “new” truth repeated ad-nauseam (by those that weren’t there) is that nothing existed before agile but “evil” waterfall. A lie repeated often enough becomes the truth.
LAC-Tech
All the 1970s papers I quoted were from people in US military, or adjacent civilian contractors (not sure how that works). I believe that's where the spiral model came from as well. Though I suppose just because it was described and published, does not mean it was followed...
Just finding out now that the "scrum" methodology came from an article in the Harvard Business Review about product manufacturing, in 1986. Interestingly they also have a waterfall-esque diagram, followed by one immediately showing overlapping phases (ie the right way to do it).
mro
and finally washed away by vibe, isn't it?
rbuchberger
Man, I have really unlearned a lot of ideas everyone agreed on back when I was a baby programmer building Rails apps. I learned all about Uncle Bob and his "clean code" and his "agile manifesto", and I read DHH blog posts about how duck typing is great because it's flexible, how OOP is great and it just makes sense because it works like the real world. Hell I even thought metaprogramming was a good idea in cases where it was absolutely not necessary, just because so many other people were doing it in the Ruby world.
Kinda wish I hadn't spun my wheels on bad ideas for so long.
creesch
I mean, a lot of those things aren't necessarily bad. The bigger problem, I feel, is the tendency for many people (certainly in IT) to put things in binary categories and definitions. While things rarely are.
The original manifesto doesn't provide all these rules and rituals people think about now. And it most certainly didn't define the four core principles as binary either or statements. But that is exactly how many people came to see them. So "Working software over comprehensive documentation" became "code is the documentation" where in reality it is more along the lines of "documentation is important, but it is more important that the software works rather than the exact right word and comma is used in paragraph 5, subsection 3a".
The same thing happened with clean code. The dogmatic stuff (every function must be five lines, abstract everything) deserves the backlash it gets. But it also very much brought attention to basic readability, decent naming and not writing needlessly clever code. That's just good practice. Saying "clean code was a bad idea" ignores that we still apply many principles from it we otherwise might not have.
From my perspective the lesson shouldn't be "those ideas were bad". It is more that any idea applied as a universal rule will eventually bite you. Even more so if you follow them without understanding the principles and ideas behind them. Like your metaprogramming example, doing it because a lot of people do it without understanding why they are doing it.
tome
Is there a specific element of the agile manifesto you disagree with?
rsanheim
This post sets up a straw man from the outset, and only gets worse from there.
The version of agile many programmers, managers, and 'tech people' know is the capital-A Agile version: watered down, sold and peddled via certifications, medium posts, and Atlassian flavored kanban boards.
This is legislating history at this point, so not sure it really matters...but many of the agile authors directly reference the fact that their ideas are not new, that they date back to the 1970s or earlier, probably referencing the same works the post mentions. Many of the signers of the manifesto worked on projects that were using 'spiral' or 'waterfall-ish' metholodogies, and they wanted a name for it. But you'd have to read the actual body of work to know that, rather than just taking the agile manifesto as the end-point.
It is pretty funny though that the author turns an attack on sell-out corporate Agile into a promotion of spec driven development as some sort of high watermark of software design. Most folks who are really using llms day-in and day-out are realizing the downfalls of focusing entirely on a spec driven approach (see superpowers plugins for one). But hey, history repeats, over and over and over again. I just hope at some point there is some actual acceptance and learning from the past without trashing it for a clickbait blog post.
LAC-Tech
The version of agile many programmers, managers, and 'tech people' know is the capital-A Agile version: watered down, sold and peddled via certifications, medium posts, and Atlassian flavored kanban boards.
I directly mentioned, linked, and repeatedly quoted from the Agile Manifesto in my "clickbait blog post". Half the point was that it was nothing but a set of platitudes, not enough to count as a process. So what is there to criticise? If we see agile practiced in the wild, we are told it's not Real Agile. If we ask what is Real Agile, we are told the manifesto. When we look at the manifesto, it lacks substance. I'm done with the loop.
It is pretty funny
Well I'm glad I could make you laugh
JulianWgs
I can really recommend "The principles of product development flow" by Donald G. Reinertsen. He explains in multiple dimensions in great detail and very practically how to setup research & development organization, which don‘t just include software companies. Really a great read. His work is a mixture of Kanban, Agile, Scrum and Lean Manufacturing.
faassen
I'm a lot more sympathetic to agile than this post is, but on "waterfall": agile established the narrative about the bad old waterfall it rescued us from. Everybody kept repeating that narrative. Such dominant cultural narratives should be viewed with some suspicion. In reality of course people did all kinds of things.
When I read "Debugging the Development Process" by Steve Maguire from 1994 it struck me how quite a bit of it echoed agile, though not everything did. One of the biggest points it makes: fixing bugs when they are detected, instead of deferring them to the end and writing a lot more code, strikes me as very iterative in nature. Apparently some developers would be seen as heroes because they would crank out a lot of code, but left the bugs in them to be debugged later, possibly by others, before release which pre-internet was a lot more involved than it is now.
I find it hard to distinguish learning to do software development as a young developer from what was in the culture at the time, but I certainly picked up notions of collaborative development, iterative development and writing tests from XP and agile. Now writing tests is wide-spread, but I wish the notion of collaboration during development were more widespread, rather than the mindset of interacting with each other mostly through PR reviews. But PRs are very legible to a corporation, and companies often prefer to do what's more legible rather than what's more effective.
drrobotic
There were 2 things i hated about agile/scrum, first was the lack of a proper planing phase. The argument was "we work agile, we plan every sprint, a rough project understanding is enough", which led often to planings with too little detail about the features, constant contact with the customer to clear things up. The second thing was giving the customer to much influence during implementation phase. Most of the time a non technical customer doesnt know what he exactly wants, so the tech guys (us) should take the project lead, but with agile we considered the customer also as project leader (adding new features, completely changes features), which complicated the dev process and in the end made projects much more expensive.
zod000
I agree completely with these two items. I have never been a big fan of Agile (with a capital A), but it did have some good points. Those points just generally weren't new at all.
valpackett
I really don't get why there's any dogma at all about specs or prototypes. It's so dependent on what each project is, on the context… Use your intuition every time to decide whether writing specs is worth it or jumping into prototyping is easier.
smackeyacky
And good riddance too.
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
>It’s always the poor specs, terrible analysis and release constraints that kill projects.
So most of the problems are related to business people and not the development teams? Who would have guessed?
k__
"Agile was always aiming to solve the wrong problem (that code is the bottleneck)"
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
Agile never claimed that.
Agile is about working code instead of hundreds of pages of spec nobody reads.
mrloba
I really doubt spec driven development is gonna last. As before, creating working software and iterating on it is faster and makes it easier to understand what you thought you wanted but don't, even if it's vibe coded. So, hello agile, welcome back.
The point is the agent writes the specs and the human reviews and revises or asks for another rewrite that takes 90 seconds or less. So specs are both cheaper and better than anything I've seen before. They still get a lot wrong and it is hard to review them very carefully, but its easier than reviewing code to suss out design intent.
EugeneOZ
Absolutely awesome, thank you, Lewis!
DeathArrow
I wonder if there is no AI product yet which runs scrum ceremonies, assigns user stories in planning and computes story point velocity after the sprint ends.
mnsc
Oh no, the kids are going to invent agile again aren't they?
rcaught
Aigile
zer00eyz
Someone once described agile as this: Its just pantomime and posit notes... implying that the process (from the outside) was more performative than anything else.
From "scrum masters" to "planing poker" it's all very silly.
Cwizard
That’s Scrum you are thinking of. Not agile.
DeathArrow
But if Agile is going to die, what are Scrum Masters going to do?
Hamuko
Same as before: nothing.
FpUser
Lucky me, I've never had to say Hi Agile in a first place. It is a tumor. Been in programming since 80s. Mostly on my own except 6 years long stint at the company. Quit in 2000 from position of CTO
dijit
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.
jeremyjh
If brute force is not working, you are not using enough.
waschl
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
lopsotronic
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).
patcon
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 :)
tiew9Vii
> 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.
t43562
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?
protocolture
>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.
boomlinde
> 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.
andersmurphy
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.
Aurornis
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.
danw1979
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.
duped
> 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
somesortofthing
What does "writing specs" here actually mean? Every agile project I've ever worked on has had a design doc that laid out architecture, the basic shape of contracts, dependencies and so on. In fact, the agile artifacts(tickets, estimates, epics etc.) have always been downstream of a design doc source-of-truth. A project where all the work comes directly from tickets with no overarching, agreed-upon document on what the end goal is supposed to be sounds hellish.
jeremyjh
> A project where all the work comes directly from tickets with no overarching, agreed-upon document on what the end goal is supposed to be sounds hellish.
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.
darkhelmet
Agile, as implemented in every big company that I've worked for, was a lie.
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.
cbg0
I've also seen agile hollowed out to become a metric delivery system that keeps managers happy; They know what everyone is doing but it keeps upper management happy to see those metrics trend upwards so the wheel keeps spinning. The actual product ends up being a byproduct of the stats.
brigandish
How did he see into the future to know which work he'd be doing on the next sprint, and how did he also finish the current sprint's work with a bullseye thus allowing the next sprint's to begin and match it?
hcfman
The way the author defined water fall makes it sound pretty good to me.
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.
anilakar
Wasn't the whole waterfall model originaly a caricature to higlight all the issues one will inevitably encounter if they eliminate feedback loops and go with a strictly sequential development paradigm?
endymi0n
I've come to dread any formalization of Agile. Agile development is fine. I've built a 40+ engineering team with it. I can vouch for its effectiveness when applied to small, excellent teams.
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.
operatingthetan
I can't count how many times I've seen "agile" projects that were just actually waterfall due to demands from stakeholders.
bartvk
I don't get the negativity, there's plenty wrong with agile (notably the hours of meetings) but all in all, it's a method and I don't see anything better right now.
t43562
If your company doesn't fundamentally want "agility" then it will be an exercise in futility but if you're a person who doesn't want to do useless work then you're an agile proponent fundamentally.
prerok
TFA first claims that agile invented none of the things it encompasses, seems not to challenge those claims, but then just jumps to agile is dead because LLMs can code based on spec.
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.
dannyobrien
I think it's worth linking to the original Agile Manifesto[1], because that's pretty much all the consensus you're ever going to get on what's "agile" and "what's not".
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.
aryeh
Well put. This article gives the “old” truth. Typically, for other than the largest government, military, and industry projects, iterative development largely preceded agile. However, the “new” truth repeated ad-nauseam (by those that weren’t there) is that nothing existed before agile but “evil” waterfall. A lie repeated often enough becomes the truth.
LAC-Tech
All the 1970s papers I quoted were from people in US military, or adjacent civilian contractors (not sure how that works). I believe that's where the spiral model came from as well. Though I suppose just because it was described and published, does not mean it was followed...
Just finding out now that the "scrum" methodology came from an article in the Harvard Business Review about product manufacturing, in 1986. Interestingly they also have a waterfall-esque diagram, followed by one immediately showing overlapping phases (ie the right way to do it).
mro
and finally washed away by vibe, isn't it?
rbuchberger
Man, I have really unlearned a lot of ideas everyone agreed on back when I was a baby programmer building Rails apps. I learned all about Uncle Bob and his "clean code" and his "agile manifesto", and I read DHH blog posts about how duck typing is great because it's flexible, how OOP is great and it just makes sense because it works like the real world. Hell I even thought metaprogramming was a good idea in cases where it was absolutely not necessary, just because so many other people were doing it in the Ruby world.
Kinda wish I hadn't spun my wheels on bad ideas for so long.
creesch
I mean, a lot of those things aren't necessarily bad. The bigger problem, I feel, is the tendency for many people (certainly in IT) to put things in binary categories and definitions. While things rarely are.
The original manifesto doesn't provide all these rules and rituals people think about now. And it most certainly didn't define the four core principles as binary either or statements. But that is exactly how many people came to see them. So "Working software over comprehensive documentation" became "code is the documentation" where in reality it is more along the lines of "documentation is important, but it is more important that the software works rather than the exact right word and comma is used in paragraph 5, subsection 3a".
The same thing happened with clean code. The dogmatic stuff (every function must be five lines, abstract everything) deserves the backlash it gets. But it also very much brought attention to basic readability, decent naming and not writing needlessly clever code. That's just good practice. Saying "clean code was a bad idea" ignores that we still apply many principles from it we otherwise might not have.
From my perspective the lesson shouldn't be "those ideas were bad". It is more that any idea applied as a universal rule will eventually bite you. Even more so if you follow them without understanding the principles and ideas behind them. Like your metaprogramming example, doing it because a lot of people do it without understanding why they are doing it.
tome
Is there a specific element of the agile manifesto you disagree with?
rsanheim
This post sets up a straw man from the outset, and only gets worse from there.
The version of agile many programmers, managers, and 'tech people' know is the capital-A Agile version: watered down, sold and peddled via certifications, medium posts, and Atlassian flavored kanban boards.
This is legislating history at this point, so not sure it really matters...but many of the agile authors directly reference the fact that their ideas are not new, that they date back to the 1970s or earlier, probably referencing the same works the post mentions. Many of the signers of the manifesto worked on projects that were using 'spiral' or 'waterfall-ish' metholodogies, and they wanted a name for it. But you'd have to read the actual body of work to know that, rather than just taking the agile manifesto as the end-point.
It is pretty funny though that the author turns an attack on sell-out corporate Agile into a promotion of spec driven development as some sort of high watermark of software design. Most folks who are really using llms day-in and day-out are realizing the downfalls of focusing entirely on a spec driven approach (see superpowers plugins for one). But hey, history repeats, over and over and over again. I just hope at some point there is some actual acceptance and learning from the past without trashing it for a clickbait blog post.
LAC-Tech
The version of agile many programmers, managers, and 'tech people' know is the capital-A Agile version: watered down, sold and peddled via certifications, medium posts, and Atlassian flavored kanban boards.
I directly mentioned, linked, and repeatedly quoted from the Agile Manifesto in my "clickbait blog post". Half the point was that it was nothing but a set of platitudes, not enough to count as a process. So what is there to criticise? If we see agile practiced in the wild, we are told it's not Real Agile. If we ask what is Real Agile, we are told the manifesto. When we look at the manifesto, it lacks substance. I'm done with the loop.
It is pretty funny
Well I'm glad I could make you laugh
JulianWgs
I can really recommend "The principles of product development flow" by Donald G. Reinertsen. He explains in multiple dimensions in great detail and very practically how to setup research & development organization, which don‘t just include software companies. Really a great read. His work is a mixture of Kanban, Agile, Scrum and Lean Manufacturing.
faassen
I'm a lot more sympathetic to agile than this post is, but on "waterfall": agile established the narrative about the bad old waterfall it rescued us from. Everybody kept repeating that narrative. Such dominant cultural narratives should be viewed with some suspicion. In reality of course people did all kinds of things.
When I read "Debugging the Development Process" by Steve Maguire from 1994 it struck me how quite a bit of it echoed agile, though not everything did. One of the biggest points it makes: fixing bugs when they are detected, instead of deferring them to the end and writing a lot more code, strikes me as very iterative in nature. Apparently some developers would be seen as heroes because they would crank out a lot of code, but left the bugs in them to be debugged later, possibly by others, before release which pre-internet was a lot more involved than it is now.
I find it hard to distinguish learning to do software development as a young developer from what was in the culture at the time, but I certainly picked up notions of collaborative development, iterative development and writing tests from XP and agile. Now writing tests is wide-spread, but I wish the notion of collaboration during development were more widespread, rather than the mindset of interacting with each other mostly through PR reviews. But PRs are very legible to a corporation, and companies often prefer to do what's more legible rather than what's more effective.
drrobotic
There were 2 things i hated about agile/scrum, first was the lack of a proper planing phase. The argument was "we work agile, we plan every sprint, a rough project understanding is enough", which led often to planings with too little detail about the features, constant contact with the customer to clear things up. The second thing was giving the customer to much influence during implementation phase. Most of the time a non technical customer doesnt know what he exactly wants, so the tech guys (us) should take the project lead, but with agile we considered the customer also as project leader (adding new features, completely changes features), which complicated the dev process and in the end made projects much more expensive.
zod000
I agree completely with these two items. I have never been a big fan of Agile (with a capital A), but it did have some good points. Those points just generally weren't new at all.
valpackett
I really don't get why there's any dogma at all about specs or prototypes. It's so dependent on what each project is, on the context… Use your intuition every time to decide whether writing specs is worth it or jumping into prototyping is easier.
And good riddance too.
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.
>It’s always the poor specs, terrible analysis and release constraints that kill projects.
So most of the problems are related to business people and not the development teams? Who would have guessed?
"Agile was always aiming to solve the wrong problem (that code is the bottleneck)"
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.
Agile never claimed that.
Agile is about working code instead of hundreds of pages of spec nobody reads.
I really doubt spec driven development is gonna last. As before, creating working software and iterating on it is faster and makes it easier to understand what you thought you wanted but don't, even if it's vibe coded. So, hello agile, welcome back.
I think there is some good middle ground between spec driven development and iterations, like Compound Engineering. https://github.com/EveryInc/compound-engineering-plugin
The point is the agent writes the specs and the human reviews and revises or asks for another rewrite that takes 90 seconds or less. So specs are both cheaper and better than anything I've seen before. They still get a lot wrong and it is hard to review them very carefully, but its easier than reviewing code to suss out design intent.
Absolutely awesome, thank you, Lewis!
I wonder if there is no AI product yet which runs scrum ceremonies, assigns user stories in planning and computes story point velocity after the sprint ends.
Oh no, the kids are going to invent agile again aren't they?
Aigile
Someone once described agile as this: Its just pantomime and posit notes... implying that the process (from the outside) was more performative than anything else.
From "scrum masters" to "planing poker" it's all very silly.
That’s Scrum you are thinking of. Not agile.
But if Agile is going to die, what are Scrum Masters going to do?
Same as before: nothing.
Lucky me, I've never had to say Hi Agile in a first place. It is a tumor. Been in programming since 80s. Mostly on my own except 6 years long stint at the company. Quit in 2000 from position of CTO
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.
If brute force is not working, you are not using enough.
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 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 :)
> 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.
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?
>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.
Good way to ensure devotion to a process rather than devotion to a desirable outcome. Seems distinctly cult-like.
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.
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.
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 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
What does "writing specs" here actually mean? Every agile project I've ever worked on has had a design doc that laid out architecture, the basic shape of contracts, dependencies and so on. In fact, the agile artifacts(tickets, estimates, epics etc.) have always been downstream of a design doc source-of-truth. A project where all the work comes directly from tickets with no overarching, agreed-upon document on what the end goal is supposed to be sounds hellish.
> A project where all the work comes directly from tickets with no overarching, agreed-upon document on what the end goal is supposed to be sounds hellish.
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.
Agile, as implemented in every big company that I've worked for, was a lie.
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.
I've also seen agile hollowed out to become a metric delivery system that keeps managers happy; They know what everyone is doing but it keeps upper management happy to see those metrics trend upwards so the wheel keeps spinning. The actual product ends up being a byproduct of the stats.
How did he see into the future to know which work he'd be doing on the next sprint, and how did he also finish the current sprint's work with a bullseye thus allowing the next sprint's to begin and match it?
The way the author defined water fall makes it sound pretty good to me.
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.
Wasn't the whole waterfall model originaly a caricature to higlight all the issues one will inevitably encounter if they eliminate feedback loops and go with a strictly sequential development paradigm?
I've come to dread any formalization of Agile. Agile development is fine. I've built a 40+ engineering team with it. I can vouch for its effectiveness when applied to small, excellent teams.
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.
I can't count how many times I've seen "agile" projects that were just actually waterfall due to demands from stakeholders.
I don't get the negativity, there's plenty wrong with agile (notably the hours of meetings) but all in all, it's a method and I don't see anything better right now.
If your company doesn't fundamentally want "agility" then it will be an exercise in futility but if you're a person who doesn't want to do useless work then you're an agile proponent fundamentally.
TFA first claims that agile invented none of the things it encompasses, seems not to challenge those claims, but then just jumps to agile is dead because LLMs can code based on spec.
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.
I think it's worth linking to the original Agile Manifesto[1], because that's pretty much all the consensus you're ever going to get on what's "agile" and "what's not".
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.
Well put. This article gives the “old” truth. Typically, for other than the largest government, military, and industry projects, iterative development largely preceded agile. However, the “new” truth repeated ad-nauseam (by those that weren’t there) is that nothing existed before agile but “evil” waterfall. A lie repeated often enough becomes the truth.
All the 1970s papers I quoted were from people in US military, or adjacent civilian contractors (not sure how that works). I believe that's where the spiral model came from as well. Though I suppose just because it was described and published, does not mean it was followed...
Just finding out now that the "scrum" methodology came from an article in the Harvard Business Review about product manufacturing, in 1986. Interestingly they also have a waterfall-esque diagram, followed by one immediately showing overlapping phases (ie the right way to do it).
and finally washed away by vibe, isn't it?
Man, I have really unlearned a lot of ideas everyone agreed on back when I was a baby programmer building Rails apps. I learned all about Uncle Bob and his "clean code" and his "agile manifesto", and I read DHH blog posts about how duck typing is great because it's flexible, how OOP is great and it just makes sense because it works like the real world. Hell I even thought metaprogramming was a good idea in cases where it was absolutely not necessary, just because so many other people were doing it in the Ruby world.
Kinda wish I hadn't spun my wheels on bad ideas for so long.
I mean, a lot of those things aren't necessarily bad. The bigger problem, I feel, is the tendency for many people (certainly in IT) to put things in binary categories and definitions. While things rarely are.
The original manifesto doesn't provide all these rules and rituals people think about now. And it most certainly didn't define the four core principles as binary either or statements. But that is exactly how many people came to see them. So "Working software over comprehensive documentation" became "code is the documentation" where in reality it is more along the lines of "documentation is important, but it is more important that the software works rather than the exact right word and comma is used in paragraph 5, subsection 3a".
The same thing happened with clean code. The dogmatic stuff (every function must be five lines, abstract everything) deserves the backlash it gets. But it also very much brought attention to basic readability, decent naming and not writing needlessly clever code. That's just good practice. Saying "clean code was a bad idea" ignores that we still apply many principles from it we otherwise might not have.
From my perspective the lesson shouldn't be "those ideas were bad". It is more that any idea applied as a universal rule will eventually bite you. Even more so if you follow them without understanding the principles and ideas behind them. Like your metaprogramming example, doing it because a lot of people do it without understanding why they are doing it.
Is there a specific element of the agile manifesto you disagree with?
This post sets up a straw man from the outset, and only gets worse from there.
The version of agile many programmers, managers, and 'tech people' know is the capital-A Agile version: watered down, sold and peddled via certifications, medium posts, and Atlassian flavored kanban boards.
This is legislating history at this point, so not sure it really matters...but many of the agile authors directly reference the fact that their ideas are not new, that they date back to the 1970s or earlier, probably referencing the same works the post mentions. Many of the signers of the manifesto worked on projects that were using 'spiral' or 'waterfall-ish' metholodogies, and they wanted a name for it. But you'd have to read the actual body of work to know that, rather than just taking the agile manifesto as the end-point.
It is pretty funny though that the author turns an attack on sell-out corporate Agile into a promotion of spec driven development as some sort of high watermark of software design. Most folks who are really using llms day-in and day-out are realizing the downfalls of focusing entirely on a spec driven approach (see superpowers plugins for one). But hey, history repeats, over and over and over again. I just hope at some point there is some actual acceptance and learning from the past without trashing it for a clickbait blog post.
I directly mentioned, linked, and repeatedly quoted from the Agile Manifesto in my "clickbait blog post". Half the point was that it was nothing but a set of platitudes, not enough to count as a process. So what is there to criticise? If we see agile practiced in the wild, we are told it's not Real Agile. If we ask what is Real Agile, we are told the manifesto. When we look at the manifesto, it lacks substance. I'm done with the loop.
Well I'm glad I could make you laugh
I can really recommend "The principles of product development flow" by Donald G. Reinertsen. He explains in multiple dimensions in great detail and very practically how to setup research & development organization, which don‘t just include software companies. Really a great read. His work is a mixture of Kanban, Agile, Scrum and Lean Manufacturing.
I'm a lot more sympathetic to agile than this post is, but on "waterfall": agile established the narrative about the bad old waterfall it rescued us from. Everybody kept repeating that narrative. Such dominant cultural narratives should be viewed with some suspicion. In reality of course people did all kinds of things.
When I read "Debugging the Development Process" by Steve Maguire from 1994 it struck me how quite a bit of it echoed agile, though not everything did. One of the biggest points it makes: fixing bugs when they are detected, instead of deferring them to the end and writing a lot more code, strikes me as very iterative in nature. Apparently some developers would be seen as heroes because they would crank out a lot of code, but left the bugs in them to be debugged later, possibly by others, before release which pre-internet was a lot more involved than it is now.
I find it hard to distinguish learning to do software development as a young developer from what was in the culture at the time, but I certainly picked up notions of collaborative development, iterative development and writing tests from XP and agile. Now writing tests is wide-spread, but I wish the notion of collaboration during development were more widespread, rather than the mindset of interacting with each other mostly through PR reviews. But PRs are very legible to a corporation, and companies often prefer to do what's more legible rather than what's more effective.
There were 2 things i hated about agile/scrum, first was the lack of a proper planing phase. The argument was "we work agile, we plan every sprint, a rough project understanding is enough", which led often to planings with too little detail about the features, constant contact with the customer to clear things up. The second thing was giving the customer to much influence during implementation phase. Most of the time a non technical customer doesnt know what he exactly wants, so the tech guys (us) should take the project lead, but with agile we considered the customer also as project leader (adding new features, completely changes features), which complicated the dev process and in the end made projects much more expensive.
I agree completely with these two items. I have never been a big fan of Agile (with a capital A), but it did have some good points. Those points just generally weren't new at all.
I really don't get why there's any dogma at all about specs or prototypes. It's so dependent on what each project is, on the context… Use your intuition every time to decide whether writing specs is worth it or jumping into prototyping is easier.
And good riddance too.
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.
>It’s always the poor specs, terrible analysis and release constraints that kill projects.
So most of the problems are related to business people and not the development teams? Who would have guessed?
"Agile was always aiming to solve the wrong problem (that code is the bottleneck)"
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.
Agile never claimed that.
Agile is about working code instead of hundreds of pages of spec nobody reads.
I really doubt spec driven development is gonna last. As before, creating working software and iterating on it is faster and makes it easier to understand what you thought you wanted but don't, even if it's vibe coded. So, hello agile, welcome back.
I think there is some good middle ground between spec driven development and iterations, like Compound Engineering. https://github.com/EveryInc/compound-engineering-plugin
The point is the agent writes the specs and the human reviews and revises or asks for another rewrite that takes 90 seconds or less. So specs are both cheaper and better than anything I've seen before. They still get a lot wrong and it is hard to review them very carefully, but its easier than reviewing code to suss out design intent.
Absolutely awesome, thank you, Lewis!
I wonder if there is no AI product yet which runs scrum ceremonies, assigns user stories in planning and computes story point velocity after the sprint ends.
Oh no, the kids are going to invent agile again aren't they?
Aigile
Someone once described agile as this: Its just pantomime and posit notes... implying that the process (from the outside) was more performative than anything else.
From "scrum masters" to "planing poker" it's all very silly.
That’s Scrum you are thinking of. Not agile.
But if Agile is going to die, what are Scrum Masters going to do?
Same as before: nothing.
Lucky me, I've never had to say Hi Agile in a first place. It is a tumor. Been in programming since 80s. Mostly on my own except 6 years long stint at the company. Quit in 2000 from position of CTO
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.
If brute force is not working, you are not using enough.
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 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 :)
> 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.
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?
>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.
Good way to ensure devotion to a process rather than devotion to a desirable outcome. Seems distinctly cult-like.
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.
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.
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 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
What does "writing specs" here actually mean? Every agile project I've ever worked on has had a design doc that laid out architecture, the basic shape of contracts, dependencies and so on. In fact, the agile artifacts(tickets, estimates, epics etc.) have always been downstream of a design doc source-of-truth. A project where all the work comes directly from tickets with no overarching, agreed-upon document on what the end goal is supposed to be sounds hellish.
> A project where all the work comes directly from tickets with no overarching, agreed-upon document on what the end goal is supposed to be sounds hellish.
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.
Agile, as implemented in every big company that I've worked for, was a lie.
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.
I've also seen agile hollowed out to become a metric delivery system that keeps managers happy; They know what everyone is doing but it keeps upper management happy to see those metrics trend upwards so the wheel keeps spinning. The actual product ends up being a byproduct of the stats.
How did he see into the future to know which work he'd be doing on the next sprint, and how did he also finish the current sprint's work with a bullseye thus allowing the next sprint's to begin and match it?
The way the author defined water fall makes it sound pretty good to me.
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.
Wasn't the whole waterfall model originaly a caricature to higlight all the issues one will inevitably encounter if they eliminate feedback loops and go with a strictly sequential development paradigm?
I've come to dread any formalization of Agile. Agile development is fine. I've built a 40+ engineering team with it. I can vouch for its effectiveness when applied to small, excellent teams.
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.
I can't count how many times I've seen "agile" projects that were just actually waterfall due to demands from stakeholders.
I don't get the negativity, there's plenty wrong with agile (notably the hours of meetings) but all in all, it's a method and I don't see anything better right now.
If your company doesn't fundamentally want "agility" then it will be an exercise in futility but if you're a person who doesn't want to do useless work then you're an agile proponent fundamentally.
TFA first claims that agile invented none of the things it encompasses, seems not to challenge those claims, but then just jumps to agile is dead because LLMs can code based on spec.
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.
I think it's worth linking to the original Agile Manifesto[1], because that's pretty much all the consensus you're ever going to get on what's "agile" and "what's not".
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.
Well put. This article gives the “old” truth. Typically, for other than the largest government, military, and industry projects, iterative development largely preceded agile. However, the “new” truth repeated ad-nauseam (by those that weren’t there) is that nothing existed before agile but “evil” waterfall. A lie repeated often enough becomes the truth.
All the 1970s papers I quoted were from people in US military, or adjacent civilian contractors (not sure how that works). I believe that's where the spiral model came from as well. Though I suppose just because it was described and published, does not mean it was followed...
Just finding out now that the "scrum" methodology came from an article in the Harvard Business Review about product manufacturing, in 1986. Interestingly they also have a waterfall-esque diagram, followed by one immediately showing overlapping phases (ie the right way to do it).
and finally washed away by vibe, isn't it?
Man, I have really unlearned a lot of ideas everyone agreed on back when I was a baby programmer building Rails apps. I learned all about Uncle Bob and his "clean code" and his "agile manifesto", and I read DHH blog posts about how duck typing is great because it's flexible, how OOP is great and it just makes sense because it works like the real world. Hell I even thought metaprogramming was a good idea in cases where it was absolutely not necessary, just because so many other people were doing it in the Ruby world.
Kinda wish I hadn't spun my wheels on bad ideas for so long.
I mean, a lot of those things aren't necessarily bad. The bigger problem, I feel, is the tendency for many people (certainly in IT) to put things in binary categories and definitions. While things rarely are.
The original manifesto doesn't provide all these rules and rituals people think about now. And it most certainly didn't define the four core principles as binary either or statements. But that is exactly how many people came to see them. So "Working software over comprehensive documentation" became "code is the documentation" where in reality it is more along the lines of "documentation is important, but it is more important that the software works rather than the exact right word and comma is used in paragraph 5, subsection 3a".
The same thing happened with clean code. The dogmatic stuff (every function must be five lines, abstract everything) deserves the backlash it gets. But it also very much brought attention to basic readability, decent naming and not writing needlessly clever code. That's just good practice. Saying "clean code was a bad idea" ignores that we still apply many principles from it we otherwise might not have.
From my perspective the lesson shouldn't be "those ideas were bad". It is more that any idea applied as a universal rule will eventually bite you. Even more so if you follow them without understanding the principles and ideas behind them. Like your metaprogramming example, doing it because a lot of people do it without understanding why they are doing it.
Is there a specific element of the agile manifesto you disagree with?
This post sets up a straw man from the outset, and only gets worse from there.
The version of agile many programmers, managers, and 'tech people' know is the capital-A Agile version: watered down, sold and peddled via certifications, medium posts, and Atlassian flavored kanban boards.
This is legislating history at this point, so not sure it really matters...but many of the agile authors directly reference the fact that their ideas are not new, that they date back to the 1970s or earlier, probably referencing the same works the post mentions. Many of the signers of the manifesto worked on projects that were using 'spiral' or 'waterfall-ish' metholodogies, and they wanted a name for it. But you'd have to read the actual body of work to know that, rather than just taking the agile manifesto as the end-point.
It is pretty funny though that the author turns an attack on sell-out corporate Agile into a promotion of spec driven development as some sort of high watermark of software design. Most folks who are really using llms day-in and day-out are realizing the downfalls of focusing entirely on a spec driven approach (see superpowers plugins for one). But hey, history repeats, over and over and over again. I just hope at some point there is some actual acceptance and learning from the past without trashing it for a clickbait blog post.
I directly mentioned, linked, and repeatedly quoted from the Agile Manifesto in my "clickbait blog post". Half the point was that it was nothing but a set of platitudes, not enough to count as a process. So what is there to criticise? If we see agile practiced in the wild, we are told it's not Real Agile. If we ask what is Real Agile, we are told the manifesto. When we look at the manifesto, it lacks substance. I'm done with the loop.
Well I'm glad I could make you laugh
I can really recommend "The principles of product development flow" by Donald G. Reinertsen. He explains in multiple dimensions in great detail and very practically how to setup research & development organization, which don‘t just include software companies. Really a great read. His work is a mixture of Kanban, Agile, Scrum and Lean Manufacturing.
I'm a lot more sympathetic to agile than this post is, but on "waterfall": agile established the narrative about the bad old waterfall it rescued us from. Everybody kept repeating that narrative. Such dominant cultural narratives should be viewed with some suspicion. In reality of course people did all kinds of things.
When I read "Debugging the Development Process" by Steve Maguire from 1994 it struck me how quite a bit of it echoed agile, though not everything did. One of the biggest points it makes: fixing bugs when they are detected, instead of deferring them to the end and writing a lot more code, strikes me as very iterative in nature. Apparently some developers would be seen as heroes because they would crank out a lot of code, but left the bugs in them to be debugged later, possibly by others, before release which pre-internet was a lot more involved than it is now.
I find it hard to distinguish learning to do software development as a young developer from what was in the culture at the time, but I certainly picked up notions of collaborative development, iterative development and writing tests from XP and agile. Now writing tests is wide-spread, but I wish the notion of collaboration during development were more widespread, rather than the mindset of interacting with each other mostly through PR reviews. But PRs are very legible to a corporation, and companies often prefer to do what's more legible rather than what's more effective.
There were 2 things i hated about agile/scrum, first was the lack of a proper planing phase. The argument was "we work agile, we plan every sprint, a rough project understanding is enough", which led often to planings with too little detail about the features, constant contact with the customer to clear things up. The second thing was giving the customer to much influence during implementation phase. Most of the time a non technical customer doesnt know what he exactly wants, so the tech guys (us) should take the project lead, but with agile we considered the customer also as project leader (adding new features, completely changes features), which complicated the dev process and in the end made projects much more expensive.
I agree completely with these two items. I have never been a big fan of Agile (with a capital A), but it did have some good points. Those points just generally weren't new at all.
I really don't get why there's any dogma at all about specs or prototypes. It's so dependent on what each project is, on the context… Use your intuition every time to decide whether writing specs is worth it or jumping into prototyping is easier.