Saying Goodbye to Agile

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.

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.

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?

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.

DeathArrow

But if Agile is going to die, what are Scrum Masters going to do?

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.

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.

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.

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.

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.

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.