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

41–50 of 271 posts

Re: Saying goodbye to Agile

#41

Post by prerok »

operatingthetan wrote: post #31
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…

I can't count how many times I've seen "agile" projects that were just actually waterfall due to demands from stakeholders.

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.

Re: Saying goodbye to Agile

#42

Post by thelastgallon »

waschl wrote: post #23
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…

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

Religion. Your life isn't better because of {not devout enough, didn't self-flagellate enough, didn't donate enough to the religious leaders/church/god, committed some other sins, belief is lacking}

Re: Saying goodbye to Agile

#43

Post by t43562 »

operatingthetan wrote: post #31
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…

I can't count how many times I've seen "agile" projects that were just actually waterfall due to demands from stakeholders.

Absolutely! "You're going to do agile .... and this list of features will be ready on September 20th."

"Oh, feature no 32 is going to take months and we realised that users can just...."

"No"

Re: Saying goodbye to Agile

#44

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

Re: Saying goodbye to Agile

#45

Post by boomlinde »

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…

> In that: if it fails, it is only considered evidence that you were not doing it enough.

Good way to ensure devotion to a process rather than devotion to a desirable outcome. Seems distinctly cult-like.

Re: Saying goodbye to Agile

#46

Post by andersmurphy »

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.

Re: Saying goodbye to Agile

#47

Post by Aurornis »

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!

Re: Saying goodbye to Agile

#48

Post by danw1979 »

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.

Re: Saying goodbye to Agile

#49

Post by duped »

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…

> In that: if it fails, it is only considered evidence that you were not doing it enough.

This is a cult tactic, for what it's worth

Re: Saying goodbye to Agile

#50

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

Post reply on HN