Live data from Hacker News

Saying goodbye to Agile

lewiscampbell.tech

241–250 of 271 posts

Re: Saying goodbye to Agile

#241

Earlier quoted context omitted.

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

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

The point is still unaddressed, isn't it?

Re: Saying goodbye to Agile

#242

Earlier quoted context omitted.

I think the confusion comes from considering Agile as a process instead of a set of values and principles. The Agile Manifesto only talks about values and principles( https://agilemanifesto.org/ ). Values are not right or wrong, they are just values you agree to or don't. The problem mostly arises when processes are shoe-horned under the guise of 'Agile' in setups where they might not be the best fit by so-called pro…

I think it’s long past the time where we can pretend that The Agile Manifesto is representative of what the word “Agile” means in tech companies. The manifesto is a minimal set of principles but every real world Agile shop I’ve interacted with has subscribed to a set of processes that everyone in tech would recognize as “Agile”. The manifesto has become a safe retreat that agile fans bring out whenever someone has cr…

Industrial Agile is mostly Agile Manifesto with the negation of the first principle (Processes and tools over individuals and interactions).

Re: Saying goodbye to Agile

#243

Earlier quoted context omitted.

I think it’s long past the time where we can pretend that The Agile Manifesto is representative of what the word “Agile” means in tech companies. The manifesto is a minimal set of principles but every real world Agile shop I’ve interacted with has subscribed to a set of processes that everyone in tech would recognize as “Agile”. The manifesto has become a safe retreat that agile fans bring out whenever someone has cr…

Industrial Agile is mostly Agile Manifesto with the negation of the first principle (Processes and tools over individuals and interactions).

"Industrial" cannot rely on any one individual. You have to be able to scale your process (or whatever), duplicate your process, have your process survive multiple people leaving, and so on.

Which means that any true agile cannot be industrial. And therefore any industrial agile cannot be true to the principles of the Agile Manifesto.

Re: Saying goodbye to Agile

#244

Earlier quoted context omitted.

>It signals to me that the process doesn't work in reality. You are better off doing something else. Whatever you do instead, you will also cargo-cult to some degree and fail equally as badly at. For all the "You're doing it wrong!" I've seen in industry with respect to agile, I've also felt that every team I've been part of that did some version of it, seemed to function OK. I always found the "Agile Manifesto" a co…

I've belonged to numerous teams that followed some form of agile, to varying degrees of success (or failure). The shape of what Agile meant in each of those teams was very different from one another. It would be disingenuous to say "the ones that succeeded were truer to Agile". If Agile can be summarized as "employ tighter feedback loops", the whole Agile thing was beyond useless. A single sentence, as useful a tenet…

> If Agile can be summarized as "employ tighter feedback loops", the whole Agile thing was beyond useless.

Not just that, Royce's original paper that coined the term "waterfall" in 1970[1] can be summarized as "employ tighter feedback loops" compared to top-down design (figures 2-4 in the paper).

[1] https://www.praxisframework.org/files/royce1970.pdf

Re: Saying goodbye to Agile

#245
SDD has no real track record.

It's only a promise of a method.

If you think it's waterfall again: Wrong.

Everyone who phantasizes about "just"™ writing the perfect spec will be in for a rude awakening.

The spec will change over time and your initial version will turn out to be very wrong.

Re: Saying goodbye to Agile

#246
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 actually agree with you but I love that the response was just a long version of "you're not doing it right!"

Re: Saying goodbye to Agile

#247
post #65

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…

> […] when applied to small, excellent teams. Isn't that the biggest issue here, though? I think all of us can agree on the four sentences you wrote, but this only works in a team of professionals with shared goals (and alignment on them!), each individually competent and motivated. That is the case for a small founder team and maybe a while after that if you're lucky, but IME the more people join a company, the more…

I'm wondering how many production strategies strictly can't work with "excellent teams", small or otherwise, barring gross incompetence or intentional sabotage.

Re: Saying goodbye to Agile

#248
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 you failed it is only evidence that you were not doing enough." is the core principle the whole self-help, self-improvement and large parts of weight loss and health industries always have been based on.

Re: Saying goodbye to Agile

#249
post #65

Earlier quoted context omitted.

> […] when applied to small, excellent teams. Isn't that the biggest issue here, though? I think all of us can agree on the four sentences you wrote, but this only works in a team of professionals with shared goals (and alignment on them!), each individually competent and motivated. That is the case for a small founder team and maybe a while after that if you're lucky, but IME the more people join a company, the more…

> this only works in a team of professionals with shared goals (and alignment on them!), each individually competent and motivated. Counterpoint: I learned a variant of agile in exactly this type of environment, long before any of this was publicized. Which is another point: agile wasn't something new, certainly not at the time of the manifesto, which was a compromise document. But not even before the manifesto. XP,…

Not to take away from your point, but that sure does sound competent, aligned, and motivated to me!

Re: Saying goodbye to Agile

#250
post #7

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

Yeah I read it and didn't get the point. So agile is dead? And we are now doing waterfall due to Ai needing unambiguous specifications? But also agile was nothing new because they knew that waterfall didn't work in the 70s. But now it works? Or are we still doing iterative development but the term agile is banned as unoriginal?
Post reply on HN