Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Saying goodbye to Agile

lewiscampbell.tech

Post reply on HN
Print view View original

211–220 of 271 posts

Re: Saying goodbye to Agile

#211

Post by locknitpicker »

pydry wrote: post #122
locknitpicker wrote: post #72

Earlier quoted context omitted.

> My favorite Agile-ism is when Agile is defined as “the process that works for the team”. What compels you to believe it isn't? I mean, read the Agile Manifesto. All it does is basically define a set of values and principles. Things like "customer comes first" or "we welcome changes in requirements" or "software must be delivered frequently". What leads you to believe Agile implies a fixed set of precise, rigid rule…

It isnt but the fact it ultra vague and hand wavey means anybody can claim anything they do is agile including things that the exact opposite. I actually think OP's criticisms apply mostly to Scrum. Scrum is well defined but its adherents' wont hear a critical word said about it. "You just werent doing it right" even when you were doing it precisely as described.

> It isnt but the fact it ultra vague and hand wavey means anybody can claim anything they do is agile including things that the exact opposite.

I don't really agree. The set of principles are quite straight forward. It's things like delivering software frequently, accommodating new requirements, continuously looking into improving processes, business types and developers working together, etc.

Then you have concrete executions like scrum vs kanban. Agile doesn't specify one or the other. Retrospective meetings are popular, but aren't specified by Agile per se.

Re: Saying goodbye to Agile

#212

Post by mfru »

danw1979 wrote: post #48
dijit wrote: post #13

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…

Ideologues are everywhere. If it isn’t presented as a theory that might be proven wrong, or an idea that might not work, that’s when my alarm starts going off. Another signal: trying stuff we already tried that didn’t work, usually with an unconvincing reason why it’s different this time.

In many contexts "already tried" does not apply under "this and this conditions" though.

You can try the same thing under different contexts and it will probably yield different results (at least in any context that is organizational / social)

Re: Saying goodbye to Agile

#213

Post by fragmede »

dijit wrote: post #196
fragmede wrote: post #193

Earlier quoted context omitted.

But is it wrong? If you're in a plane and it's on the ground and it starts moving but it doesn't take off, the answer really is to move faster. If you press a button and it doesn't activate, the answer might just be to press harder. If you're running away from a bear but it's catching up to you, the answer really is run faster. If you don't, you're dead. So the problem with that is that it's an oversimplification in…

all of those examples have a known causal mechanism and a measurable outcome.

I know, right? If only the rest of life was that easy!

Re: Saying goodbye to Agile

#214

Post by jeremyjh »

zelphirkalt wrote: post #120
9dev wrote: post #67

Earlier quoted context omitted.

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.

Until the agents start touching things that already worked well before and break them.

They do need a competent developer operating them. That has nothing to do with whether nor not specs have value.

Re: Saying goodbye to Agile

#215

Post by smackeyacky »

rowyourboat wrote: post #103
smackeyacky wrote: post #2

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.

> 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 n…

This is a weird backwards logic to justify terrible analysis

Re: Saying goodbye to Agile

#216

Post by smackeyacky »

prerok wrote: post #14
smackeyacky wrote: post #2

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.

Agile never claimed that. Agile is about working code instead of hundreds of pages of spec nobody reads.

Ironically the AI guys are now saying good spec is what we need for the agents to code. So which one is it

Re: Saying goodbye to Agile

#217

Post by smackeyacky »

DeathArrow wrote: post #6
smackeyacky wrote: post #2

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.

>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?

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”

Re: Saying goodbye to Agile

#218

Post by smackeyacky »

k__ wrote: post #10
smackeyacky wrote: post #2

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.

"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.

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.

Re: Saying goodbye to Agile

#219

Post by duskdozer »

locknitpicker wrote: post #207
duskdozer wrote: post #94

Earlier quoted context omitted.

If it's an internet-required smarthammer without a handle that instead hits out on voice prompt, sometimes without enough or with too much force, sometimes knocks the nail out of the way and punches a hole, and sometimes hits you in the face, then yeah

> If it's an internet-required smarthammer without a handle that (...) A suitable comparison would be to be faced with a nailgun and proceeding to criticize it on the grounds it doesn't have a handle, it doesn't pull nails, and it requires electricity to run. While you complain about those detailed those using nailguns are an order of magnitude more productive at the same task, and can still carry a hammer in their t…

I originally was writing the post using a nailgun, but decided someone would criticize it for straying too far away from a hammer. Alas.

Re: Saying goodbye to Agile

#220

Post by AnimalMuppet »

Aurornis wrote: post #47
dijit wrote: post #13

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…

My favorite Agile-ism is when Agile is defined as “the process that works for the team”. If a team adopts agile (in any variation) and doesn’t like it, the Agile defenders will appear and argue that the team wasn’t actually doing agile. Agile is defined as the process that works, so if it didn’t work it couldn’t have been agile. If only you read The Agile Manifesto you would understand!

My definition of agile is that process is a knob that you can turn. You don't like how the process is working out for your team? Adjust the process. Find the sweet spot for your team. As your team changes size and/or members, keep adjusting.

"We're going to do agile by following this rigid process" is an oxymoron.

Post reply on HN