Oh no, the kids are going to invent agile again aren't they?
Stay hopeful, maybe Nu-Agile will become annoying in new and interesting ways!
Saying goodbye to Agile
101–110 of 271 posts
Re: Saying goodbye to Agile
#102Good. 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.
Re: Saying goodbye to Agile
#103And 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.
> 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.
Re: Saying goodbye to Agile
#104Earlier quoted context omitted.
This is a great point! Reminds me of Agentic software development. When it doesn't work out it's only evidence that you could have used more agents. You can never use enough tokens.
> This is a great point! Reminds me of Agentic software development. When it doesn't work out it's only evidence that you could have used more agents. A concept older than agentic software development is bad workmen blaming his tools. I mean, if you can't possibly hammer a nail then is it reasonable to blame the hammer?
Clearly they didn't use enough hammer. Screws always require the most hammer. Common knowledge to any certified practitioner of Hammer™[1].
- [1] Get 20% off your Hammer Master™ certificate with referral code THUMBPAIN
Re: Saying goodbye to Agile
#105There'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…
Yes, but on the other hand, there's https://www.reddit.com/r/ididnthaveeggs/ , which collects cases of home cooks making inadvisable recipe substitutions and then complaining to the recipe creators that the resulting dish tasted bad. Sometimes there are essential ingredients and skipping them or replacing them with something else makes success impossible.
An appealing analogy but recipes have defined testable outcomes. You know what a Victoria sponge is supposed to look like (there's probably even a picture of one in the book). You can perfectly evaluate when a substitute has ruined it.
Agile doesn't have that, there is no functional equivelant of "the cake should be moist and rise evenly". What does "Agile" adoption look like? Faster delivery? Happier Developers? More revenue? Fewer bugs? This is never defined up front and they shift depending on the person being asked. This means you can never actually determine if someone "left out an essential ingredient".
The irony is that Agiles own favoured development practice (TDD) cannot be applied to Agile itself. There is no acceptance test for the process, you can't iterate on something that isn't measured and has no defined outcome.
/r/ididnthaveeggs works because everyone agrees on what the dish should have been.
Re: Saying goodbye to Agile
#106Oh no, the kids are going to invent agile again aren't they?
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.
Re: Saying goodbye to Agile
#107> 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.
Re: Saying goodbye to Agile
#108What 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 th…
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.
Re: Saying goodbye to Agile
#109The way the author defined water fall makes it sound pretty good to me. Put your hand up if you are ever programming with poor specs? Put your hand up if you have a better idea of what really was wanted after the first cut? And what I really dislike is those that try to design a Swiss Army knife from day one when they haven’t a clue. Jump immediately into over complexity.
Wasn't the whole waterfall model 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?
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.
Re: Saying goodbye to Agile
#110Good. 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 i…
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?