HN

Comments (182)

• Menu

  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.
• Menu

  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 toolsWorking software over comprehensive documentationCustomer collaboration over contract negotiationResponding to change over following a planThe 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.
• Menu

  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.
• Menu

  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.
• Menu

  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.
• red_admiral
  > The Manifesto sayeth naught of Daily Standups, nor Agile CoachesThe 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.
• js8
  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).
• Menu

  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.
• Menu

  tome
  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 innovationsAre there some references that demonstrate that?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.
• ezekiel68
  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.
• sminchev
  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 :DFor 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 :)
• Menu

  28304283409234
  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.
• Menu

  hussfelt
  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/
• Menu

  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.
• Menu

  ilitirit
  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 etcEvery 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)
• Menu

  mnsc
  Oh no, the kids are going to invent agile again aren't they?
• mickduprez
  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!
• 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.
• Menu

  tetrisgm
  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.
• tru1ock
  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.
• 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.
• perfunctory
  > 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.
• Menu

  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.
• poisonborz
  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.
• erpellan
  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.
• anon
  undefined
• Menu

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

  01100011
  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.
• time4tea
  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.
• koonsolo
  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.
• Menu

  0xbadcafebee
  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.
• rsanheim
  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.
• mytailorisrich
  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"...
• jokoon
  Feels like another bad idea from management born in the silicon valley
• Menu

  DeathArrow
  But if Agile is going to die, what are Scrum Masters going to do?
• jillesvangurp
  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.
• Menu

  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.
• globular-toast
  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.
• jokethrowaway
  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 planThe 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 = PROCESSThis 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.
• Menu

  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.
• EugeneOZ
  Absolutely awesome, thank you, Lewis!
• duped
  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.
• Menu

  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.
• mark124mj
  [dead]
• drumstock
  [dead]
• leric
  [dead]
• Menu

  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