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

51–60 of 271 posts

Re: Saying goodbye to Agile

#51

Post by Cwizard »

endymi0n wrote: post #21

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

Yes, exactly. It works great. But it is not cookie cutter enough for most orgs to adopt which is what led to Scrum, SAFE and what else. And then organisations take those frameworks (often change them to get even more agility out) and adopt them like it is gospel.

I have worked at an org where team members were not allowed to create tickets because that was the scrum master's job and the product owner had to approve all tickets etc. Who can even think that is a good idea??

Not sure what the solution is. There might not be any.

Re: Saying goodbye to Agile

#52

Post by AndrewThrowaway »

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…

If AI fails, you wrote the prompt wrong.

Re: Saying goodbye to Agile

#53

Post by 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.

Re: Saying goodbye to Agile

#55

Post by ytoawwhra92 »

jeremyjh wrote: post #29
mrloba wrote: post #3

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.

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.

The point is that sometimes you don't know the spec is wrong until you've built the software and it's being used.

Re: Saying goodbye to Agile

#56

Post by tux1968 »

t43562 wrote: post #37
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…

It's usually because your company doesn't fundamentally want it. You cannot have roadmaps with lists of features that you advertise to customers AND have the flexibility to decide to ignore things that turn out to be useless or disporportionately time consuming. If someone handed you a plan for making a jet engine and you messed around with the instructions ... why would you expect it to work? If you have a bug becau…

But that isn't evidence that the method works. If you're a native tribe, that has an ancient traditional rain dance, it is invoked whenever there is a drought. Sometimes it rains shortly after the dance is performed. But if it doesn't rain, it's not proof that you danced poorly, it's evidence that you didn't understand the situation fully or properly. The instructions or "wisdom" you relied on, didn't actually capture something useful.

Re: Saying goodbye to Agile

#57

Post by somesortofthing »

jeremyjh wrote: post #38
somesortofthing wrote: post #16

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

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

Traditional design doc review processes aren't perfect but I'll take them over Radical Ticket Anarchy any day of the week.

Re: Saying goodbye to Agile

#58

Post by Erndob »

andersmurphy wrote: post #46
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…

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.

Which also conveniently makes you spend more money on tokens.

With agile, at least no one was charging you for it. Like sure, there’s a cost to the process. But there wasn’t direct agile.com profiting from you.

Meanwhile agentic workflows every solution to the problem is giving more money to the ai companies.

Model is bad? Made more expensive model. Still bad? Here’s an infrastructure that reads huge text files again and again making you consume tokens. Still bad? Here’s a way to easily spin up multiple agents at once so you can delegate work. Still bad? Here’s a new service that will automatically review code. Still bad? Maybe a biggger more expensive model will help.

Re: Saying goodbye to Agile

#59

Post by z3t4 »

patcon wrote: post #30
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…

I suspect there might not be love for this angle here, but there's something else that follows this format: God. Spirituality. Religion. I'm not religious is any traditional sense, but I'd argue that it's not always the hallmark of a bad dynamic when a system always asks of you to do inner work when failures happen in contact with the real world. Sometimes that's a healthier mode than the alternative -- externalizing…

when it comes to some diets, some only work if you follow them wholeheartedly, like meat only diet, one speck of peppar might be enough to cause an inflammation. But generally you can't take a process that worked well for another person or company and apply it on you or your company. Like for example a training program, you can't just take a training program from a professional athlete and reuse it on your kid and expect him/her to become as good as the pro. Programs and processes are very individual tailored.

Re: Saying goodbye to Agile

#60

Post by 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.

Post reply on HN