8 ms·

Saying goodbye to Agile

182 points by matrixhelix 6mo ago

smackeyacky 6mo ago
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 6mo ago
  >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?
  - smackeyacky 6mo ago
    Holding analysts to account would be a good start. Agile lets them get away with laziness. It’s always “oh sure we got that wrong better luck next sprint”
- k__ 6mo ago
  "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.
  - smackeyacky 6mo ago
    Not in my experience. AI exposes the truth that agile as it is practised is a huge waste of time. All the bullshit ceremonies and short sprints were designed to get code squeezed out faster, no matter if the code actually addressed the goals of the project. The stupidity of agile is in its iteration speed since you can be handed utter crap, implement it to hit your story points and find out the drooling shitgibbon who wrote the specs phoned it in so your work is now wasted. Rinse, repeat.
- prerok 6mo ago
  Agile never claimed that. Agile is about working code instead of hundreds of pages of spec nobody reads.
  - smackeyacky 6mo ago
    Ironically the AI guys are now saying good spec is what we need for the agents to code. So which one is it
- rowyourboat 6mo ago
  > always the poor specs But that is fundamentally what agile is about. It's not about coding faster, it's the recognition that the specs are incomplete or wrong because fundamentally, a lot of customers cannot tell you what the want until they see it. That's why "build something simple and iterate on it" works. Regardless of how good your spec is, once the coding is done the customer is going to realise that that's not what they actually wanted.
  - smackeyacky 6mo ago
    This is a weird backwards logic to justify terrible analysis
    - array_key_first 6mo ago
      No this is literally in the agile manifesto. It's not logic at all, it's the written word of what agile is. What that means is that Agile and agile are not the same thing. Most companies practice Agile, very few are agile.
mrloba 6mo ago
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.
- DeathArrow 6mo ago
  I think there is some good middle ground between spec driven development and iterations, like Compound Engineering. https://github.com/EveryInc/compound-engineering-plugin https://github.com/EveryInc/compound-engineering-plugin
- jeremyjh 6mo ago
  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.
  - ytoawwhra92 6mo ago
    The point is that sometimes you don't know the spec is wrong until you've built the software and it's being used.
    - 9dev 6mo ago
      Still though, that cycle can be iterated many times in a single day. Write a spec, let the agent build it, use the software, evaluate results, repeat.
      - ytoawwhra92 6mo ago
        Yes, that's agile software development.
        6mo ago
EugeneOZ 6mo ago
Absolutely awesome, thank you, Lewis!
DeathArrow 6mo ago
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.
- bitwize 6mo ago
  That's clearly a human's job. The AI's job is to do the programming.
mnsc 6mo ago
Oh no, the kids are going to invent agile again aren't they?
- rcaught 6mo ago
  Aigile
- kombookcha 6mo ago
  Stay hopeful, maybe Nu-Agile will become annoying in new and interesting ways!
  - zelphirkalt 6mo ago
    Perhaps needing to estimate tasks in cloud credits? That would be a new one. And then of course mapping those credits uselessly to time needed.
    - kombookcha 6mo ago
      Maybe you gotta do daily standups with all your own Agents and then have both you and them do standup with the rest of the team's Agents to touch base, sync up and loop back or whatever.
- LAC-Tech 6mo ago
  Author here. So one of the main points in this massive, 700 word Treatise (which I do hope you will find the time to read) was that nothing Agile practitioners slapped their label onto was actually novel. Why re-invent agile, when agile itself was just a reinvention by "the kids" (your words, not mine) of things people in the 1970s already knew? One might as well go straight to the 1970s directly.
  - mnsc 6mo ago
    Yeah I read it and didn't get the point. So agile is dead? And we are now doing waterfall due to Ai needing unambiguous specifications? But also agile was nothing new because they knew that waterfall didn't work in the 70s. But now it works? Or are we still doing iterative development but the term agile is banned as unoriginal?
zer00eyz 6mo ago
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 6mo ago
  That’s Scrum you are thinking of. Not agile.
DeathArrow 6mo ago
But if Agile is going to die, what are Scrum Masters going to do?
- Hamuko 6mo ago
  Same as before: nothing.
- deleted 6mo ago
  [deleted]
FpUser 6mo ago
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
- 4ggr0 6mo ago
  at the same time, how can you judge something so harshly if you've never experienced it yourself.
  - FpUser 6mo ago
    Because I had "pleasure" watching others doing it. One does not have to step into shit personally
dijit 6mo ago
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.
- dvfjsdhgfv 6mo ago
  This applies to everything. If your coding agent has problems with non-trivial programs, it's your fault, too.
- jeremyjh 6mo ago
  If brute force is not working, you are not using enough.
- waschl 6mo ago
  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
  - moron4hire 6mo ago
    Dude, this mode of ex post facto rationalization is waaaay older than communism. It's basically one of the main "retention warnings" of most religions.
somesortofthing 6mo ago
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 6mo ago
  > 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.
  - somesortofthing 6mo ago
    Traditional design doc review processes aren't perfect but I'll take them over Radical Ticket Anarchy any day of the week.
- LAC-Tech 6mo ago
  Author here. Well I think this just proves we can slap "agile" onto anything. The people before agile actually wrote things with more substance than the manifesto. The agile projects you worked on sound wonderful, and I would align "writing specs" with what you describe, at least in terms of the design doc.
- zelphirkalt 6mo ago
  In an actually agile project or organization, the source of truth is the user of the software, because the developers periodically and whenever else necessary talk directly with the users and listen to what they have to say, and put that into writing. In a fake agile project or org, the source of truth is a made up document written by the PO or PM and only remotely related to what the actual user says. Devs are kept away from the user by their higher ups, who seek job guarantees.
darkhelmet 6mo ago
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 6mo ago
  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 6mo ago
  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?
  - tass 6mo ago
    Not the op, but you only commit to what you already did in this sprint. So this sprint shows what you delivered 2 sprints ago, next sprint will be the work you just finished.
  - mitthrowaway2 6mo ago
    From my reading, it's really quite brilliant. He just says that he's about to start the tasks that, in reality, he's just finishing up. Then he delays reporting that the task is done. His estimates are then always made with perfect hindsight.
hcfman 6mo ago
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 6mo ago
  Wasn't the whole waterfall model originally a caricature to higlight all the issues one will inevitably encounter if they eliminate feedback loops and go with a strictly sequential development paradigm?
  - LAC-Tech 6mo ago
    Author here. Yes, that would be the first paper I linked to in the article, "Managing the Development of Large Software Systems" (Royce, 1970). The first diagram is the classic waterfall diagram, used there for illustrative purposes as an example of what not to do. Highly recommend it to people - it's short but a real breathe of fresh air. Mostly still applicable today.
endymi0n 6mo ago
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 6mo ago
  I can't count how many times I've seen "agile" projects that were just actually waterfall due to demands from stakeholders.
  - prerok 6mo ago
    I've seen that too, though I have to say that none of those were as waterfally as the actual waterfall process we used to follow. Back then it was quite literally 0 lines of code until spec (100s of pages) is complete.
    - steinsgatezero 6mo ago
      Which ironically makes Agile even worse at times by forcing developers to implement incomplete spec, parts of which are often rewritten over and over again everytime the PM talks to the client.
      - ryandrake 6mo ago
        A lot of managers confuse "Agile" with fast and think that "agile" teams are going to deliver software faster. In reality, it's often slower than waterfall. If you have a single feature that's never going to change, and you absolutely positively need it by Date X, then you're probably better off with waterfall.
t43562 6mo ago
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.
bartvk 6mo ago
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.
prerok 6mo ago
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.
- adrian_b 6mo ago
  Iterative development has existed since forever, since earlier than written history. It is not something invented by the Agile proponents. They have proposed a much more specific variant of iterative development, which at least as I have seen it implemented in any company which claimed to implement it, was really bad in comparison with the right ways of organizing development work, which I have seen elsewhere. Any high quality product must be designed starting from a good written specification. Obviously, almost always the initial specification must pass through one or more update cycles, after experience is gathered through the implementation. This has always been universally used, not just by Agile practitioners. There have always existed bad managers, who wrongly believed that a development process can always be linear and who did not include in their timelines the necessity for loops, but that was just bad management, so if Agile proponents pointed to such cases, those were just strawmen, not the best existing practices.
- lpapez 6mo ago
  > 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. I agree, but what you describe is agile, not Agile (capital A). Agile (capital A) is Scrum (capital S) where you have Backlog Grooming (patent pending) where the team clears any ambiguity to define a spec (ticket). Deviating from said spec is seen as Scope Creep (gasp) and might lead to complaints during Sprint Review (trademark). So yes, agile prefers working software over detailed spec. But typical manifestations of Agile (capital A) are exactly the opposite.
dannyobrien 6mo ago
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.
- urban_winter 6mo ago
  Yes! Ask anyone with 30 years in the industry whether "agile", for all its problems, was a force for good or bad, and the answer will be an emphatic Good! If nothing else, it gave us ammunition to argue against the impossibility of delivering a fixed thing in a fixed amount of time - which was the universal view from senior stakeholders of what competent software delivery looked like.
- zelphirkalt 6mo ago
  No, you are not going to get that consensus, because middle management and hire ups don't want to know what agile actually means, but want to continue believing, that the processes they impose are agile, and they have probably never even seen that page. In a truly agile team, the team takes many if not all of their work and responsibilities, so that even the jobs of PMs and low middle management would be on the line. As we know it is difficult to get someone to understand something, when their income depends on not understanding it.
- oersted 6mo ago
  https://agilemanifesto.org/ https://agilemanifesto.org/
hussfelt 6mo ago
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." Handbook: https://agile.flights/docs/introduction/why-flights/ https://agile.flights/docs/introduction/why-flights/
- deleted 6mo ago
  [deleted]
duped 6mo ago
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.
drumstock 6mo ago
[dead]
01100011 6mo ago
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.
- tonyedgecombe 6mo ago
  Doesn’t the F-35 need to be rebooted on a regular basis to keep it running. That sounds exactly like my TV.
sminchev 6mo ago
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 :)
leric 6mo ago
[dead]
jillesvangurp 6mo ago
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.
ludovicianul 6mo ago
I've written something similar https://blog.dochia.dev/blog/waterfall-returning/ https://blog.dochia.dev/blog/waterfall-returning/ As code is less expensive, specs are the new bottleneck.
- badgersnake 6mo ago
  Getting the requirements right was always the hard part. Hence agile.
  - ludovicianul 6mo ago
    Yes, exactly. We move cost in another place. When you look holistically at a (complex) project, efficiencies are not that big.
0xbadcafebee 6mo ago
If you've never built a complex thing out of wood, I highly recommend it. There's an interesting curve of experience. First you try to build basic things, and it seems kinda easy, everything just works. Then you start trying more advanced things, and it seems like everything gets screwed up constantly. Finally you master the advanced things, and you screw up less and it gets easier. The same is true of software. At first you try to make software, and you do, and it's kinda easy. Then you try to make more advanced software, and it seems much harder than it should be, as what you think will work doesn't. You spend a lot of time changing your design to make things work, which ends up not being exactly as you thought it should at first. Finally, after you master software development, things get easier and work like you expect. In both cases, when you are ignorant, you do the wrong thing, and it works despite your ignorance, because you're doing an easy thing in the most straightforward way. But then you get cocky and try things that aren't as easy, and suddenly the straightforward way doesn't work anymore, because complex things never work the way you expect. Finally, after you've screwed up doing the thing enough, you remember what not to do, and now you can do it without the mistakes. But you're just not-screwing-up the things you already screwed up once before. You'll still screw up new things, because you haven't learned them yet. And you'll screw up again when you forget a past screw-up. What separates the woodworker from the software engineer is, the woodworker doesn't make a lot of different things, and doesn't use a lot of different ways to do it. The software engineer is constantly doing new things, in different ways. So the software engineer is perpetually rising to their level of ignorance, while the woodworker stays mostly within their level of competence. This is why there is no system in the universe that will be better than any other at software development. Agile, Waterfall, or anything else, doesn't matter. As long as you keep doing new things, you'll never not be screwing up. But stick to one thing and master it, and it doesn't matter how you do it.
- zelphirkalt 6mo ago
  And that's why agile is not a set in stone process, that imposes tools and process upon the devs, but states: "Individuals and interactions over processes and tools". Basically, it tells you, that you will need to figure out what works for this project and this set of people.
deleted 6mo ago
[deleted]
poisonborz 6mo ago
As others said, if agile fails, "you were not doing it enoug". But if agile is criticized... only worse alternatives are given, if at all. Here, spec-driven development is inferior, as in most cases the goal is only vaguely known. Cyclical development is not some hollow mantra, it is how life works. All the rituals around it were just to faciliate more communication. A lot of people in this field just hate that, they want their tickets and to be left alone. Now that implementation cycles are even shorter, there is even less manual need for coding, agile methodologies will be actually more prevalent.
ilitirit 6mo ago
I personally have never worked in a team where Agile (the concept) has failed. But I've also seen it fail all around me. Especially when it's mandated without buy-in. Or when people just don't "get it". e.g. - 45 minute "standups" (!?) - PI "planning" that consisting of deadlines and glorified multiplayer MS Paint - Rigid adherence to ceremonies or processes that add zero value - Retros that focus on complaints and venting with no actionable outcomes - etc etc Every time I've introduced Agile to a team or project that was new to it I was always met with skepticism. But 6 months down the line noone on the team/project wanted to go back to the "old" way of working. I don't even really care about any text book definitions. These are the only things we try to stick to: - Short, daily standups - Planning based on risk reduction - Estimates based on complexity (ties in with risk reduction) - Actionable retro items - User demos every sprint (makes it easier to pivot - users rarely know what they want)
- zelphirkalt 6mo ago
  If you don't care about definitions, then it would be good to not perpetuate using the word agile for your own set process. "Individuals and interactions over processes and tools"
- tkel 6mo ago
  Venting is important. When you don't, tension builds and then explodes. It's necessary to give people a way to air complaints and be heard. And if your team has people with some organizational and social skills, you can channel that into action.
  - ilitirit 6mo ago
    > Venting is important. Of course. But you shouldn't run retros that are focused on it.
    - tkel 6mo ago
      Sure, but if people are using the retro as a vent session, maybe it's because they need an outlet. Perhaps a separate meeting titled "vent session" is what you want. Although it's important to have action come out of that meeting as well, don't want to just channels peoples' real concerns into a meeting that is intended to hear them out and then do nothing. Manipulating peoples' concerns into a channel where they are made unobstructive and ineffective, so they can be easier ignored is a pattern of bad-faith bosses. Conflict avoidance is toxic. You and the team building skills in conflict resolution can help.
rsanheim 6mo ago
This post sets up a straw man from the outset, and only gets worse from there. I understand how we got here, where many experienced programmers, managers, and bloggers only know capital-A Agile as the watered down version sold via certifications, crummy medium posts, and atlassian flavored kanban boards. But that isn't agile. I can’t even with the pitch into spec driven development as some sort of high watermark of software methodology.
tetrisgm 6mo ago
Good. I've worked in several organizations where we had Agile. With the years, I've come to think about it as a sing and dance designed to make the project managers, PMs and sales feel like the actually impactful ICs considered them. There's something really absurd about making programmers sit down and say it's a 5 or 8 effort, then punish them for being "wrong". All it achieves is reduce velocity at best, with the illusion that it's for the greater good.
- BrissyCoder 6mo ago
  Worked in and managed a few "Agile" teams. Never heard of a dev get punished for a bad estimate. Can you describe exactly what you mean?
  - tetrisgm 6mo ago
    1. estimate this sprint. let's say it's 100 points. 2. oh no, you shipped 80 points. 3. "we need to better estimates": a) engineer spends more time trying to guess which direction the wind will blog b) engineer starts sandbagging estimates c) engineer changes nothing. looks bad next time the imaginary goal isn't met. "bob needs help estimating".
    - lmm 6mo ago
      > 3. "we need to better estimates" Push back on that. Agile says other things are more important.
    - BrissyCoder 6mo ago
      Yeah okay. Thanks for clarifying. I guess I thought when you said "punish" you meant something more dramatic!
perfunctory 6mo ago
> One unambiguously positive development that's followed is that software professionals are writing specs again. LLMs - like many of us - do not perform well with ambiguity, and specifying problems is proving to be an effective tool for generating correct code. Replace "LLM" with "compiler", "specs" with "code" and "correct code" with "correct machine code" and we are back to square one.
ezekiel68 6mo ago
Ward Cunningham [edit: oops, it was Kent Beck] had it right, long ago, when he wrote in "Extreme Programming" [paraphrase]: You don't drive to Florida by carefully lining up your car in New York on I-95 South, locking the steering wheel, and then pressing the accelerator until you arrive. This was really all that Agile was ever trying to avoid -- the tyranny of imaginedf omniscience. The bad old way (which I did labor under in the '90s) set up a Gant chart of dependent requirement up front, during a "design phase" which completely de-valued learnings and insights gained along the way as a software system was constructed during the "implementation phase". It was the best we had till then, but many software projects were failing due to their inability to adapt to unforeseen design flaws or to the feedback of stakeholders (once the software finally got into their hands). I don't know why the ceremonies became ossified and sacred. I guess every movement must confront the danger of settling for form over substance. I do know one thing. You can't build an amazon dot com, a Facebook, or a Grand Theft Auto in a 1-million token context session with an LLM. I'm sure you can do it with many such sessions, but it won't be an LLM that ties it all together properly (again - too much context). And I say this as an enthusiastic user of agentic programming.
erpellan 6mo ago
If we just put enough effort in and write the right spec/prompt/design then the programmers/llms/plug compatible coding units will produce the correct output first time! Closing feedback loops. That’s the whole thing. WE Deming would have recognised agile (little a) as a PDCA system and approved.
28304283409234 6mo ago
The problem is reality. I've found that Finance, and the Tax Office of any government, rarely care about your Agile processes. They have their yearly cycles, and C-Level will always want to follow _those_ cycles. Then, for those that have schoolgoing kids or work with people that have schoolgoing kids (aka: everyone everywhere): there is the school vacations cycles. These too rarely care about your scrum rituals or PI planning. This means that your calendar is not a reflection of reality: July/August barely exists. Same goes for November or December. And at the same time December is full of actual deadlines due to end-of-year financial cycles. And finally: the complexity of the work itself rarely lends itself to the linear timelines people expect. Rarely have I met a Product-person, or a SCRUM person, that actually understands this. And can account for it in their Agile way of working. End result: a continuous stream of disappointment. What fun times we live in.
- badgersnake 6mo ago
  Then don't use it in those environments. Agile is not a silver bullet, nothing is.
mark124mj 6mo ago
[dead]
js8 6mo ago
When Agile came about to company (large American corp) I work for, around 2015 (arguably quite late), I was quite skeptical. In my opinion, a decent waterfall (basically a sort of compromise) worked pretty well, and I didn't like fake "innovations" like Scrum or renaming everything in project management terminology. Then I read Steve Yegge's Good Agile, Bad Agile. It basically says, Agile is just a Kanban queue. And I think I got it, and I think that's working very well. At least from the project management side. There are IMHO three management angles to look at any engineering project - product, project and architecture. If you are building a house, you need a blueprint to tell where to put what concrete, you need a render (or paper model) that you show to a customer, and you need a BOM and a timeline to make the investors happy. The software is not different. But that's also where there are misunderstandings in what Agile is - the product management, project management and engineering all have different ideas what kind of "plan" is needed. So in the case of software, specs are like the house's blueprint. In some cases, specs might be useful prototype, in some cases not. It's just not the type of plan that the project or product management cares about. Regarding the project management angle, for me Agile today is clearly Kanban, and almost everything else is wrong or not required. I often make an analogy with computers. In the 50s and 60s, people tried to plan the work that the computer calculates by creating some scheduling algorithms that plan ahead the use of resources, avoid conflicts and such. Eventually, we found out that simple dispatch queues work the best, don't estimate at all how long the task will take. Just give it a priority, a time slice, and let it run. And I think the same applies for the SW development. And I think it's time that project management people take note from computer scientists - they already know. Doesn't mean SW development time cannot be estimated if you need to, it's just not a very efficient to do so (it takes extra time, depending on how good estimate you want).
globular-toast 6mo ago
There's a problem with any formalisation of patterns like Agile and other things like SOLID, Design Patterns (GoF) etc.: if you never saw the world before them, you will never appreciate why they exist. Is anyone actually doing true waterfall development any more? How would that even work with the amount of open source software in use? The world is fundamentally different now than it was 25 years ago. Stuff like SOLID and Design Patterns etc. are such good ideas that they've been incorporated directly into the design of modern languages and frameworks. It's natural that someone would pick up Design Patterns today and think it's all pointless. That's because the book was written in 1994 and it wasn't pointless to say it back then. I guess this is why history tends to repeat itself. Many people can't internalise why something is bad unless they've experienced it themselves. Many more don't even read about it in the first place. Scary to think.
mickduprez 6mo ago
I think that Agile in principle is a good idea, keep iterations small and work on the issues together and deliver working products. The missing piece I think is that PDCA (Plan/Do/Check/Act) cycle isn't being done correctly. The idea is not just to improve the product but to improve the process of creating the product. This may mean you stray way of the path of the Agile system but that doesn't matter, the standard Agile process is just a starting point, it's your shop, create it how you like. I like a saying from the LEAN manufacturing culture - "The Process is the Expert" but that comes with a caveat, each and every team member is a Process Engineer!
time4tea 6mo ago
Spec driven ddevelopment.. ahh yes, because the formal methods era of computer programming was so quick and successful! Let me find my: Requirements Specification Requirements Analysis ... The circle will turn once again when people re-realise that by tue time you've written what should happen in enough detail, you've written the software, and English isn't that great at avoiding ambiguity.
mytailorisrich 6mo ago
LLMs and AI coding do not change anything to the validity and wisdom of the Agile Manifesto and principles. It's only a new tool in the tool box. It is difficult to take the author seriously after his claims that the Agile Manifesto is only "platitudes" and "near devoid of meaning"...
tru1ock 6mo ago
Gather requirements -> Small focused spec -> code -> Validate -> Fix/Adjust -> Remove spec once it is captured in code and tests. Agile is stronger than ever, spending time on every small detail in a waterfall approach makes you burn human time on work that most probably could have been perfectly fine with a default approach. Context matter but I fail to see people spending months on planning out a system before building anything.
jokoon 6mo ago
Feels like another bad idea from management born in the silicon valley
red_admiral 6mo ago
> The Manifesto sayeth naught of Daily Standups, nor Agile Coaches The manifesto says "Stop trying to micromanage your programmers." It's written vaguely and politely but its spirit is the opposite of mandating daily meetings ("processes"), having trained coaches, or any metrics like story points ("tools"). As the explanation says: > Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
koonsolo 6mo ago
The problem with spec driven development is that your specs are never complete, and for sure contain inconsistencies, wrong assumptions, etc. So now you write specs, and then an LLM, which is known to be overly compliant, will handle the implementation. If you don't see the issues with this workflow, you for sure have learned nothing about how the software development process evolved.
tome 6mo ago
I'm curious whether it's the author's contention that the signatories of the Agile Manifesto thought that the ideas they were championing went back only a few years, and they had no idea they went back at least 30. In particular > All of these things were later claimed as Agile innovations Are there some references that demonstrate that? [EDIT: that the signatories thought they were their own innovations] And if so, is that a bad thing? Ideas are repeatedly rediscovered. This article isn't called "Saying goodbye to Royce, Bell and Thayer", and I'm wondering why not.
- eesmith 6mo ago
  Yes, there is an entire narrative that first there was chaos, then there was waterfall, and then there was agile. For example, https://www.infoworld.com/article/2334751/a-brief-history-of-the-agile-methodology.html https://www.infoworld.com/article/2334751/a-brief-history-of... It's as if people believed that all the microcomputing software of the 1970s and 1980s, from VisiCalc to Zork to the Macintosh, was done by waterfall design.
  - tome 6mo ago
    Right, some people believe that. But did any of the signatories of the Agile Manifesto?
    - eesmith 6mo ago
      Oh, absolutely not.
jokethrowaway 6mo ago
Saying the Agile manifesto was void of meaning is ridiculous. - 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 problem is that the Agile industry mostly didn't follow the Agile manifesto and ended up with monstruosity like SCRUM, which is all about processes over people. Daily Standups, Retrospective, Backlog Grooming = PROCESS This crap should all be replaced with async written communication (for quality of life and recording), but each team should ultimately be free to decide. The Agile manifesto was all about freedom and it was turned into a jail.
pushedx 6mo ago
How about "documentation driven development"? So many times I have found myself writing the end-user documentation (even after writing tests for the code), and realized that the design should change. This is the kind of post that makes me log in to hn to give a vote.
ghusto 6mo ago
> and at worst it was commercially unworkable ("Welcome changing requirements, even late in development") It's been workable for me. We can change the requirements as late as you like, because I'm getting paid by the hour. Scaled up to a company, that translates to not giving a fixed price for anything. If you need to give a fixed price, either be experienced enough to know by how much your agreement can change and factor that in, or turn it down. You should also turn down demands for a fixed price on novel solutions you can't have experience on.
neo_doom 6mo ago
> One unambiguously positive development that's followed is that software professionals are writing specs again. I feel this in my core. There has been a period of the last 5-6 years where folks have stopped writing specs entirely and it has driven me nuts. Everything is a story or some other abstract requirement. The absence of a specs has made software worse and less predictable in my opinion. All hail the specification!
foozebox 6mo ago
If the term "agile" didn't have such double or triple meaning, it may have worked. The term itself promises too much with little context and it was always too easy to fall into the trap of "being agile" because, why not? Agility is a valuable trait in human terms.
Garlef 6mo ago
SDD has no real track record. It's only a promise of a method. If you think it's waterfall again: Wrong. Everyone who phantasizes about "just"™ writing the perfect spec will be in for a rude awakening. The spec will change over time and your initial version will turn out to be very wrong.
gls2ro 6mo ago
Here is one experience I did not maybe consider enough: the teams that behave the closest to what the Agile manifesto seems to define as agility had three things in common, two of them were inside the team: 1. emotionally mature team members 2. competent team members that were able to deliver and knew their strenght and acknolwedge their unknowns and the one item outside the team: 3. Trust and respect for them from the business leadership Of course having these 3 things makes any SDLC work

182 points by matrixhelix 6mo ago

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 6mo ago
>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?
- smackeyacky 6mo ago
  Holding analysts to account would be a good start. Agile lets them get away with laziness. It’s always “oh sure we got that wrong better luck next sprint”
k__ 6mo ago
"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.
- smackeyacky 6mo ago
  Not in my experience. AI exposes the truth that agile as it is practised is a huge waste of time. All the bullshit ceremonies and short sprints were designed to get code squeezed out faster, no matter if the code actually addressed the goals of the project. The stupidity of agile is in its iteration speed since you can be handed utter crap, implement it to hit your story points and find out the drooling shitgibbon who wrote the specs phoned it in so your work is now wasted. Rinse, repeat.
prerok 6mo ago
Agile never claimed that. Agile is about working code instead of hundreds of pages of spec nobody reads.
- smackeyacky 6mo ago
  Ironically the AI guys are now saying good spec is what we need for the agents to code. So which one is it
rowyourboat 6mo ago
> always the poor specs But that is fundamentally what agile is about. It's not about coding faster, it's the recognition that the specs are incomplete or wrong because fundamentally, a lot of customers cannot tell you what the want until they see it. That's why "build something simple and iterate on it" works. Regardless of how good your spec is, once the coding is done the customer is going to realise that that's not what they actually wanted.
- smackeyacky 6mo ago
  This is a weird backwards logic to justify terrible analysis
  - array_key_first 6mo ago
    No this is literally in the agile manifesto. It's not logic at all, it's the written word of what agile is. What that means is that Agile and agile are not the same thing. Most companies practice Agile, very few are agile.

mrloba 6mo ago

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.

DeathArrow 6mo ago
I think there is some good middle ground between spec driven development and iterations, like Compound Engineering. https://github.com/EveryInc/compound-engineering-plugin https://github.com/EveryInc/compound-engineering-plugin
jeremyjh 6mo ago
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.
- ytoawwhra92 6mo ago
  The point is that sometimes you don't know the spec is wrong until you've built the software and it's being used.
  - 9dev 6mo ago
    Still though, that cycle can be iterated many times in a single day. Write a spec, let the agent build it, use the software, evaluate results, repeat.
    - ytoawwhra92 6mo ago
      Yes, that's agile software development.
      - 6mo ago

EugeneOZ 6mo ago

Absolutely awesome, thank you, Lewis!

DeathArrow 6mo ago

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.

bitwize 6mo ago
That's clearly a human's job. The AI's job is to do the programming.

mnsc 6mo ago

Oh no, the kids are going to invent agile again aren't they?

rcaught 6mo ago
Aigile
kombookcha 6mo ago
Stay hopeful, maybe Nu-Agile will become annoying in new and interesting ways!
- zelphirkalt 6mo ago
  Perhaps needing to estimate tasks in cloud credits? That would be a new one. And then of course mapping those credits uselessly to time needed.
  - kombookcha 6mo ago
    Maybe you gotta do daily standups with all your own Agents and then have both you and them do standup with the rest of the team's Agents to touch base, sync up and loop back or whatever.
LAC-Tech 6mo ago
Author here. So one of the main points in this massive, 700 word Treatise (which I do hope you will find the time to read) was that nothing Agile practitioners slapped their label onto was actually novel. Why re-invent agile, when agile itself was just a reinvention by "the kids" (your words, not mine) of things people in the 1970s already knew? One might as well go straight to the 1970s directly.
- mnsc 6mo ago
  Yeah I read it and didn't get the point. So agile is dead? And we are now doing waterfall due to Ai needing unambiguous specifications? But also agile was nothing new because they knew that waterfall didn't work in the 70s. But now it works? Or are we still doing iterative development but the term agile is banned as unoriginal?

zer00eyz 6mo ago

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 6mo ago
That’s Scrum you are thinking of. Not agile.

DeathArrow 6mo ago

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

Hamuko 6mo ago
Same as before: nothing.
deleted 6mo ago
[deleted]

FpUser 6mo ago

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

4ggr0 6mo ago
at the same time, how can you judge something so harshly if you've never experienced it yourself.
- FpUser 6mo ago
  Because I had "pleasure" watching others doing it. One does not have to step into shit personally

dijit 6mo ago

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.

dvfjsdhgfv 6mo ago
This applies to everything. If your coding agent has problems with non-trivial programs, it's your fault, too.
jeremyjh 6mo ago
If brute force is not working, you are not using enough.
waschl 6mo ago
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
- moron4hire 6mo ago
  Dude, this mode of ex post facto rationalization is waaaay older than communism. It's basically one of the main "retention warnings" of most religions.

somesortofthing 6mo ago

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 6mo ago
> 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.
- somesortofthing 6mo ago
  Traditional design doc review processes aren't perfect but I'll take them over Radical Ticket Anarchy any day of the week.
LAC-Tech 6mo ago
Author here. Well I think this just proves we can slap "agile" onto anything. The people before agile actually wrote things with more substance than the manifesto. The agile projects you worked on sound wonderful, and I would align "writing specs" with what you describe, at least in terms of the design doc.
zelphirkalt 6mo ago
In an actually agile project or organization, the source of truth is the user of the software, because the developers periodically and whenever else necessary talk directly with the users and listen to what they have to say, and put that into writing. In a fake agile project or org, the source of truth is a made up document written by the PO or PM and only remotely related to what the actual user says. Devs are kept away from the user by their higher ups, who seek job guarantees.

darkhelmet 6mo ago

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 6mo ago
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 6mo ago
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?
- tass 6mo ago
  Not the op, but you only commit to what you already did in this sprint. So this sprint shows what you delivered 2 sprints ago, next sprint will be the work you just finished.
- mitthrowaway2 6mo ago
  From my reading, it's really quite brilliant. He just says that he's about to start the tasks that, in reality, he's just finishing up. Then he delays reporting that the task is done. His estimates are then always made with perfect hindsight.

hcfman 6mo ago

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 6mo ago
Wasn't the whole waterfall model originally a caricature to higlight all the issues one will inevitably encounter if they eliminate feedback loops and go with a strictly sequential development paradigm?
- LAC-Tech 6mo ago
  Author here. Yes, that would be the first paper I linked to in the article, "Managing the Development of Large Software Systems" (Royce, 1970). The first diagram is the classic waterfall diagram, used there for illustrative purposes as an example of what not to do. Highly recommend it to people - it's short but a real breathe of fresh air. Mostly still applicable today.

endymi0n 6mo ago

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 6mo ago
I can't count how many times I've seen "agile" projects that were just actually waterfall due to demands from stakeholders.
- prerok 6mo ago
  I've seen that too, though I have to say that none of those were as waterfally as the actual waterfall process we used to follow. Back then it was quite literally 0 lines of code until spec (100s of pages) is complete.
  - steinsgatezero 6mo ago
    Which ironically makes Agile even worse at times by forcing developers to implement incomplete spec, parts of which are often rewritten over and over again everytime the PM talks to the client.
    - ryandrake 6mo ago
      A lot of managers confuse "Agile" with fast and think that "agile" teams are going to deliver software faster. In reality, it's often slower than waterfall. If you have a single feature that's never going to change, and you absolutely positively need it by Date X, then you're probably better off with waterfall.

t43562 6mo ago

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.

bartvk 6mo ago

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.

prerok 6mo ago

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.

adrian_b 6mo ago
Iterative development has existed since forever, since earlier than written history. It is not something invented by the Agile proponents. They have proposed a much more specific variant of iterative development, which at least as I have seen it implemented in any company which claimed to implement it, was really bad in comparison with the right ways of organizing development work, which I have seen elsewhere. Any high quality product must be designed starting from a good written specification. Obviously, almost always the initial specification must pass through one or more update cycles, after experience is gathered through the implementation. This has always been universally used, not just by Agile practitioners. There have always existed bad managers, who wrongly believed that a development process can always be linear and who did not include in their timelines the necessity for loops, but that was just bad management, so if Agile proponents pointed to such cases, those were just strawmen, not the best existing practices.
lpapez 6mo ago
> 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. I agree, but what you describe is agile, not Agile (capital A). Agile (capital A) is Scrum (capital S) where you have Backlog Grooming (patent pending) where the team clears any ambiguity to define a spec (ticket). Deviating from said spec is seen as Scope Creep (gasp) and might lead to complaints during Sprint Review (trademark). So yes, agile prefers working software over detailed spec. But typical manifestations of Agile (capital A) are exactly the opposite.

dannyobrien 6mo ago

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.

urban_winter 6mo ago
Yes! Ask anyone with 30 years in the industry whether "agile", for all its problems, was a force for good or bad, and the answer will be an emphatic Good! If nothing else, it gave us ammunition to argue against the impossibility of delivering a fixed thing in a fixed amount of time - which was the universal view from senior stakeholders of what competent software delivery looked like.
zelphirkalt 6mo ago
No, you are not going to get that consensus, because middle management and hire ups don't want to know what agile actually means, but want to continue believing, that the processes they impose are agile, and they have probably never even seen that page. In a truly agile team, the team takes many if not all of their work and responsibilities, so that even the jobs of PMs and low middle management would be on the line. As we know it is difficult to get someone to understand something, when their income depends on not understanding it.
oersted 6mo ago
https://agilemanifesto.org/ https://agilemanifesto.org/

hussfelt 6mo ago

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." Handbook: https://agile.flights/docs/introduction/why-flights/ https://agile.flights/docs/introduction/why-flights/

deleted 6mo ago
[deleted]

duped 6mo ago

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.

drumstock 6mo ago

[dead]

01100011 6mo ago

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.

tonyedgecombe 6mo ago
Doesn’t the F-35 need to be rebooted on a regular basis to keep it running. That sounds exactly like my TV.

sminchev 6mo ago

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 :)

leric 6mo ago

[dead]

jillesvangurp 6mo ago

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.

ludovicianul 6mo ago

I've written something similar https://blog.dochia.dev/blog/waterfall-returning/ https://blog.dochia.dev/blog/waterfall-returning/ As code is less expensive, specs are the new bottleneck.

badgersnake 6mo ago
Getting the requirements right was always the hard part. Hence agile.
- ludovicianul 6mo ago
  Yes, exactly. We move cost in another place. When you look holistically at a (complex) project, efficiencies are not that big.

0xbadcafebee 6mo ago

If you've never built a complex thing out of wood, I highly recommend it. There's an interesting curve of experience. First you try to build basic things, and it seems kinda easy, everything just works. Then you start trying more advanced things, and it seems like everything gets screwed up constantly. Finally you master the advanced things, and you screw up less and it gets easier. The same is true of software. At first you try to make software, and you do, and it's kinda easy. Then you try to make more advanced software, and it seems much harder than it should be, as what you think will work doesn't. You spend a lot of time changing your design to make things work, which ends up not being exactly as you thought it should at first. Finally, after you master software development, things get easier and work like you expect. In both cases, when you are ignorant, you do the wrong thing, and it works despite your ignorance, because you're doing an easy thing in the most straightforward way. But then you get cocky and try things that aren't as easy, and suddenly the straightforward way doesn't work anymore, because complex things never work the way you expect. Finally, after you've screwed up doing the thing enough, you remember what not to do, and now you can do it without the mistakes. But you're just not-screwing-up the things you already screwed up once before. You'll still screw up new things, because you haven't learned them yet. And you'll screw up again when you forget a past screw-up. What separates the woodworker from the software engineer is, the woodworker doesn't make a lot of different things, and doesn't use a lot of different ways to do it. The software engineer is constantly doing new things, in different ways. So the software engineer is perpetually rising to their level of ignorance, while the woodworker stays mostly within their level of competence. This is why there is no system in the universe that will be better than any other at software development. Agile, Waterfall, or anything else, doesn't matter. As long as you keep doing new things, you'll never not be screwing up. But stick to one thing and master it, and it doesn't matter how you do it.

zelphirkalt 6mo ago
And that's why agile is not a set in stone process, that imposes tools and process upon the devs, but states: "Individuals and interactions over processes and tools". Basically, it tells you, that you will need to figure out what works for this project and this set of people.

deleted 6mo ago

[deleted]

poisonborz 6mo ago

As others said, if agile fails, "you were not doing it enoug". But if agile is criticized... only worse alternatives are given, if at all. Here, spec-driven development is inferior, as in most cases the goal is only vaguely known. Cyclical development is not some hollow mantra, it is how life works. All the rituals around it were just to faciliate more communication. A lot of people in this field just hate that, they want their tickets and to be left alone. Now that implementation cycles are even shorter, there is even less manual need for coding, agile methodologies will be actually more prevalent.

ilitirit 6mo ago

I personally have never worked in a team where Agile (the concept) has failed. But I've also seen it fail all around me. Especially when it's mandated without buy-in. Or when people just don't "get it". e.g. - 45 minute "standups" (!?) - PI "planning" that consisting of deadlines and glorified multiplayer MS Paint - Rigid adherence to ceremonies or processes that add zero value - Retros that focus on complaints and venting with no actionable outcomes - etc etc Every time I've introduced Agile to a team or project that was new to it I was always met with skepticism. But 6 months down the line noone on the team/project wanted to go back to the "old" way of working. I don't even really care about any text book definitions. These are the only things we try to stick to: - Short, daily standups - Planning based on risk reduction - Estimates based on complexity (ties in with risk reduction) - Actionable retro items - User demos every sprint (makes it easier to pivot - users rarely know what they want)

zelphirkalt 6mo ago
If you don't care about definitions, then it would be good to not perpetuate using the word agile for your own set process. "Individuals and interactions over processes and tools"
tkel 6mo ago
Venting is important. When you don't, tension builds and then explodes. It's necessary to give people a way to air complaints and be heard. And if your team has people with some organizational and social skills, you can channel that into action.
- ilitirit 6mo ago
  > Venting is important. Of course. But you shouldn't run retros that are focused on it.
  - tkel 6mo ago
    Sure, but if people are using the retro as a vent session, maybe it's because they need an outlet. Perhaps a separate meeting titled "vent session" is what you want. Although it's important to have action come out of that meeting as well, don't want to just channels peoples' real concerns into a meeting that is intended to hear them out and then do nothing. Manipulating peoples' concerns into a channel where they are made unobstructive and ineffective, so they can be easier ignored is a pattern of bad-faith bosses. Conflict avoidance is toxic. You and the team building skills in conflict resolution can help.

rsanheim 6mo ago

This post sets up a straw man from the outset, and only gets worse from there. I understand how we got here, where many experienced programmers, managers, and bloggers only know capital-A Agile as the watered down version sold via certifications, crummy medium posts, and atlassian flavored kanban boards. But that isn't agile. I can’t even with the pitch into spec driven development as some sort of high watermark of software methodology.

tetrisgm 6mo ago

Good. I've worked in several organizations where we had Agile. With the years, I've come to think about it as a sing and dance designed to make the project managers, PMs and sales feel like the actually impactful ICs considered them. There's something really absurd about making programmers sit down and say it's a 5 or 8 effort, then punish them for being "wrong". All it achieves is reduce velocity at best, with the illusion that it's for the greater good.

BrissyCoder 6mo ago
Worked in and managed a few "Agile" teams. Never heard of a dev get punished for a bad estimate. Can you describe exactly what you mean?
- tetrisgm 6mo ago
  1. estimate this sprint. let's say it's 100 points. 2. oh no, you shipped 80 points. 3. "we need to better estimates": a) engineer spends more time trying to guess which direction the wind will blog b) engineer starts sandbagging estimates c) engineer changes nothing. looks bad next time the imaginary goal isn't met. "bob needs help estimating".
  - lmm 6mo ago
    > 3. "we need to better estimates" Push back on that. Agile says other things are more important.
  - BrissyCoder 6mo ago
    Yeah okay. Thanks for clarifying. I guess I thought when you said "punish" you meant something more dramatic!

perfunctory 6mo ago

> One unambiguously positive development that's followed is that software professionals are writing specs again. LLMs - like many of us - do not perform well with ambiguity, and specifying problems is proving to be an effective tool for generating correct code. Replace "LLM" with "compiler", "specs" with "code" and "correct code" with "correct machine code" and we are back to square one.

ezekiel68 6mo ago

Ward Cunningham [edit: oops, it was Kent Beck] had it right, long ago, when he wrote in "Extreme Programming" [paraphrase]: You don't drive to Florida by carefully lining up your car in New York on I-95 South, locking the steering wheel, and then pressing the accelerator until you arrive. This was really all that Agile was ever trying to avoid -- the tyranny of imaginedf omniscience. The bad old way (which I did labor under in the '90s) set up a Gant chart of dependent requirement up front, during a "design phase" which completely de-valued learnings and insights gained along the way as a software system was constructed during the "implementation phase". It was the best we had till then, but many software projects were failing due to their inability to adapt to unforeseen design flaws or to the feedback of stakeholders (once the software finally got into their hands). I don't know why the ceremonies became ossified and sacred. I guess every movement must confront the danger of settling for form over substance. I do know one thing. You can't build an amazon dot com, a Facebook, or a Grand Theft Auto in a 1-million token context session with an LLM. I'm sure you can do it with many such sessions, but it won't be an LLM that ties it all together properly (again - too much context). And I say this as an enthusiastic user of agentic programming.

erpellan 6mo ago

If we just put enough effort in and write the right spec/prompt/design then the programmers/llms/plug compatible coding units will produce the correct output first time! Closing feedback loops. That’s the whole thing. WE Deming would have recognised agile (little a) as a PDCA system and approved.

28304283409234 6mo ago

The problem is reality. I've found that Finance, and the Tax Office of any government, rarely care about your Agile processes. They have their yearly cycles, and C-Level will always want to follow _those_ cycles. Then, for those that have schoolgoing kids or work with people that have schoolgoing kids (aka: everyone everywhere): there is the school vacations cycles. These too rarely care about your scrum rituals or PI planning. This means that your calendar is not a reflection of reality: July/August barely exists. Same goes for November or December. And at the same time December is full of actual deadlines due to end-of-year financial cycles. And finally: the complexity of the work itself rarely lends itself to the linear timelines people expect. Rarely have I met a Product-person, or a SCRUM person, that actually understands this. And can account for it in their Agile way of working. End result: a continuous stream of disappointment. What fun times we live in.

badgersnake 6mo ago
Then don't use it in those environments. Agile is not a silver bullet, nothing is.

mark124mj 6mo ago

[dead]

js8 6mo ago

When Agile came about to company (large American corp) I work for, around 2015 (arguably quite late), I was quite skeptical. In my opinion, a decent waterfall (basically a sort of compromise) worked pretty well, and I didn't like fake "innovations" like Scrum or renaming everything in project management terminology. Then I read Steve Yegge's Good Agile, Bad Agile. It basically says, Agile is just a Kanban queue. And I think I got it, and I think that's working very well. At least from the project management side. There are IMHO three management angles to look at any engineering project - product, project and architecture. If you are building a house, you need a blueprint to tell where to put what concrete, you need a render (or paper model) that you show to a customer, and you need a BOM and a timeline to make the investors happy. The software is not different. But that's also where there are misunderstandings in what Agile is - the product management, project management and engineering all have different ideas what kind of "plan" is needed. So in the case of software, specs are like the house's blueprint. In some cases, specs might be useful prototype, in some cases not. It's just not the type of plan that the project or product management cares about. Regarding the project management angle, for me Agile today is clearly Kanban, and almost everything else is wrong or not required. I often make an analogy with computers. In the 50s and 60s, people tried to plan the work that the computer calculates by creating some scheduling algorithms that plan ahead the use of resources, avoid conflicts and such. Eventually, we found out that simple dispatch queues work the best, don't estimate at all how long the task will take. Just give it a priority, a time slice, and let it run. And I think the same applies for the SW development. And I think it's time that project management people take note from computer scientists - they already know. Doesn't mean SW development time cannot be estimated if you need to, it's just not a very efficient to do so (it takes extra time, depending on how good estimate you want).

globular-toast 6mo ago

There's a problem with any formalisation of patterns like Agile and other things like SOLID, Design Patterns (GoF) etc.: if you never saw the world before them, you will never appreciate why they exist. Is anyone actually doing true waterfall development any more? How would that even work with the amount of open source software in use? The world is fundamentally different now than it was 25 years ago. Stuff like SOLID and Design Patterns etc. are such good ideas that they've been incorporated directly into the design of modern languages and frameworks. It's natural that someone would pick up Design Patterns today and think it's all pointless. That's because the book was written in 1994 and it wasn't pointless to say it back then. I guess this is why history tends to repeat itself. Many people can't internalise why something is bad unless they've experienced it themselves. Many more don't even read about it in the first place. Scary to think.

mickduprez 6mo ago

I think that Agile in principle is a good idea, keep iterations small and work on the issues together and deliver working products. The missing piece I think is that PDCA (Plan/Do/Check/Act) cycle isn't being done correctly. The idea is not just to improve the product but to improve the process of creating the product. This may mean you stray way of the path of the Agile system but that doesn't matter, the standard Agile process is just a starting point, it's your shop, create it how you like. I like a saying from the LEAN manufacturing culture - "The Process is the Expert" but that comes with a caveat, each and every team member is a Process Engineer!

time4tea 6mo ago

Spec driven ddevelopment.. ahh yes, because the formal methods era of computer programming was so quick and successful! Let me find my: Requirements Specification Requirements Analysis ... The circle will turn once again when people re-realise that by tue time you've written what should happen in enough detail, you've written the software, and English isn't that great at avoiding ambiguity.

mytailorisrich 6mo ago

LLMs and AI coding do not change anything to the validity and wisdom of the Agile Manifesto and principles. It's only a new tool in the tool box. It is difficult to take the author seriously after his claims that the Agile Manifesto is only "platitudes" and "near devoid of meaning"...

tru1ock 6mo ago

Gather requirements -> Small focused spec -> code -> Validate -> Fix/Adjust -> Remove spec once it is captured in code and tests. Agile is stronger than ever, spending time on every small detail in a waterfall approach makes you burn human time on work that most probably could have been perfectly fine with a default approach. Context matter but I fail to see people spending months on planning out a system before building anything.

jokoon 6mo ago

Feels like another bad idea from management born in the silicon valley

red_admiral 6mo ago

> The Manifesto sayeth naught of Daily Standups, nor Agile Coaches The manifesto says "Stop trying to micromanage your programmers." It's written vaguely and politely but its spirit is the opposite of mandating daily meetings ("processes"), having trained coaches, or any metrics like story points ("tools"). As the explanation says: > Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

koonsolo 6mo ago

The problem with spec driven development is that your specs are never complete, and for sure contain inconsistencies, wrong assumptions, etc. So now you write specs, and then an LLM, which is known to be overly compliant, will handle the implementation. If you don't see the issues with this workflow, you for sure have learned nothing about how the software development process evolved.

tome 6mo ago

I'm curious whether it's the author's contention that the signatories of the Agile Manifesto thought that the ideas they were championing went back only a few years, and they had no idea they went back at least 30. In particular > All of these things were later claimed as Agile innovations Are there some references that demonstrate that? [EDIT: that the signatories thought they were their own innovations] And if so, is that a bad thing? Ideas are repeatedly rediscovered. This article isn't called "Saying goodbye to Royce, Bell and Thayer", and I'm wondering why not.

eesmith 6mo ago
Yes, there is an entire narrative that first there was chaos, then there was waterfall, and then there was agile. For example, https://www.infoworld.com/article/2334751/a-brief-history-of-the-agile-methodology.html https://www.infoworld.com/article/2334751/a-brief-history-of... It's as if people believed that all the microcomputing software of the 1970s and 1980s, from VisiCalc to Zork to the Macintosh, was done by waterfall design.
- tome 6mo ago
  Right, some people believe that. But did any of the signatories of the Agile Manifesto?
  - eesmith 6mo ago
    Oh, absolutely not.

jokethrowaway 6mo ago

Saying the Agile manifesto was void of meaning is ridiculous. - 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 problem is that the Agile industry mostly didn't follow the Agile manifesto and ended up with monstruosity like SCRUM, which is all about processes over people. Daily Standups, Retrospective, Backlog Grooming = PROCESS This crap should all be replaced with async written communication (for quality of life and recording), but each team should ultimately be free to decide. The Agile manifesto was all about freedom and it was turned into a jail.

pushedx 6mo ago

How about "documentation driven development"? So many times I have found myself writing the end-user documentation (even after writing tests for the code), and realized that the design should change. This is the kind of post that makes me log in to hn to give a vote.

ghusto 6mo ago

> and at worst it was commercially unworkable ("Welcome changing requirements, even late in development") It's been workable for me. We can change the requirements as late as you like, because I'm getting paid by the hour. Scaled up to a company, that translates to not giving a fixed price for anything. If you need to give a fixed price, either be experienced enough to know by how much your agreement can change and factor that in, or turn it down. You should also turn down demands for a fixed price on novel solutions you can't have experience on.

neo_doom 6mo ago

> One unambiguously positive development that's followed is that software professionals are writing specs again. I feel this in my core. There has been a period of the last 5-6 years where folks have stopped writing specs entirely and it has driven me nuts. Everything is a story or some other abstract requirement. The absence of a specs has made software worse and less predictable in my opinion. All hail the specification!

foozebox 6mo ago

If the term "agile" didn't have such double or triple meaning, it may have worked. The term itself promises too much with little context and it was always too easy to fall into the trap of "being agile" because, why not? Agility is a valuable trait in human terms.

Garlef 6mo ago

SDD has no real track record. It's only a promise of a method. If you think it's waterfall again: Wrong. Everyone who phantasizes about "just"™ writing the perfect spec will be in for a rude awakening. The spec will change over time and your initial version will turn out to be very wrong.

gls2ro 6mo ago

Here is one experience I did not maybe consider enough: the teams that behave the closest to what the Agile manifesto seems to define as agility had three things in common, two of them were inside the team: 1. emotionally mature team members 2. competent team members that were able to deliver and knew their strenght and acknolwedge their unknowns and the one item outside the team: 3. Trust and respect for them from the business leadership Of course having these 3 things makes any SDLC work