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 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.
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.
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.
"If you failed it is only evidence that you were not doing enough."
is the core principle the whole self-help, self-improvement and large parts of weight loss and health industries always have been based on.
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.
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 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 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.
Ran into the same wall - ceremony eating the actual work. The Flight methodology cuts through it: a landing date, a single captain, no story points, no mandatory standups.
The tagline from the handbook: "Agile started with a manifesto. It ended with Jira."
I'm of the belief that most project management voodoo is just that - voodoo. There is no rigor, there's no formal basis for ideas, and there's no testing of hypotheses and rejection when evidence counters it.
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.
These arguments are pointless. Working software is shipped using either method, some combination, or no method at all.
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.
I watched a video a few years ago where one of Kent Beck, Martin Fowler, Jeff Sutherland, Ken Schwaber, I don't remember who exactly, explained what they wanted to do with the Agile Manifesto, what screwed up. He explained that they wanted to give guidelines, not a strict rules. They wanted flexibility. But people started selling this as courses, business, rules. Some Agile practitioners become fanatics on the topic. And this created misunderstanding and chaos :D
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 :)
A requirement specification is how you prompt software engineers. One-shotting it doesn't work (waterfall). You need to put the SEs in planning mode. They will ask you questions and refine the plan. And you end up with a better plan. But if you make it too complicated the plan will go off the rails. So, you need to make them assign Fibonacci tokens to their planned tasks. Now you have a better plan and you can assign your SEs to tasks and get them working on it. Fibonacci tokens are not time units. This is very important. But you will run out of tokens after two weeks. So you need to buy some extra pizza tokens and make them work until midnight (crunch time!). That's how you get the job done. Every time. Sort of.
I bet some jerk is going to organize a multi agent scrum process at some point and burn some tokens on this nonsense.
57 comments
[ 25.0 ms ] story [ 1058 ms ] threadAgile 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.
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.
The do-more-with-less cancer that is infecting so many companies, where the tumor is Continuous Growth.
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.
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.
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.
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.
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.