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

191–200 of 271 posts

Re: Saying goodbye to Agile

#191

Post by azangru »

surgical_fire wrote: post #151
azangru wrote: post #142

Earlier quoted context omitted.

> if it fails, it is only considered evidence that you were not doing it enough. Or not doing it properly. And I understand the suspicion, I really do; but in hindsight, if you honestly tried to review how an organisation was operating, would you sincerely be able to say that it was adhering to a certain agile methodology/framework/mindset/strategy/whatever? I have so far not see an organisation that would be followi…

> I have so far not see an organisation that would be following scrum, as it is described in the scrum guide; or kanban, as it is described in the kanban guide. I have seen or heard about various organisations that use these words, but they have little resemblance to what was actually proposed. If that's true, wouldn't it point at the process being impossible to implement? It is a myth. There exists a version of Agil…

> There exists a version of Agile that could be implemented, and it would be the true Agile. The pure, honest experiment that would just work, because Agile cannot fail, you can only fail to Agile.

"Agile" is a very vague and shapeless idea which is hard to design an experiment for; but I would settle for clean experiments with well-defined methodologies/frameworks/strategies/whatever. Specifically, for scrum or kanban. Whenever people talk about these two, they seem to misunderstand them more often than not.

Re: Saying goodbye to Agile

#192

Post by pushedx »

How about "documentation driven development"?

So many times I have found myself writing the end-user documentation (even after writing tests for the code), and realized that the design should change.

This is the kind of post that makes me log in to hn to give a vote.

Re: Saying goodbye to Agile

#193

Post by fragmede »

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…

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 an attempt to sound smart and insightful and can't be used as a general principle to reason as to whether or not you need to double down to see results.

Re: Saying goodbye to Agile

#194

Post by latentsea »

surgical_fire wrote: post #151
azangru wrote: post #142

Earlier quoted context omitted.

> if it fails, it is only considered evidence that you were not doing it enough. Or not doing it properly. And I understand the suspicion, I really do; but in hindsight, if you honestly tried to review how an organisation was operating, would you sincerely be able to say that it was adhering to a certain agile methodology/framework/mindset/strategy/whatever? I have so far not see an organisation that would be followi…

> I have so far not see an organisation that would be following scrum, as it is described in the scrum guide; or kanban, as it is described in the kanban guide. I have seen or heard about various organisations that use these words, but they have little resemblance to what was actually proposed. If that's true, wouldn't it point at the process being impossible to implement? It is a myth. There exists a version of Agil…

>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 completely silly nothing-burger, but always understood the core tenet of 'agile' to be "employ tighter feedback loops", which... is sort of mostly how it plays out in practice??

Re: Saying goodbye to Agile

#195

Post by UnreachableCode »

lmm wrote: post #183
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. > The solution can never be at fault, it's your execution, or your devotion to the process (in this case) that was faulty. This isn't some religious premise, it's the lesson of bitter experience. It's like how when two trains crash into each other the inspectors start by looking for which one went through a danger signal, rather…

Isn't this type of reasoning okay to an extent until you (or in more humbling cases, someone else) points out it's no longer working?

Re: Saying goodbye to Agile

#196

Post by dijit »

fragmede wrote: post #193
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…

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.

Re: Saying goodbye to Agile

#197

Post by tome »

eesmith wrote: post #190
tome wrote: post #176

I'm curious whether it's the author's contention that the signatories of the Agile Manifesto thought that the ideas they were championing went back only a few years, and they had no idea they went back at least 30. In particular > All of these things were later claimed as Agile innovations Are there some references that demonstrate that? [EDIT: that the signatories thought they were their own innovations] And if so,…

Yes, there is an entire narrative that first there was chaos, then there was waterfall, and then there was agile. For example, https://www.infoworld.com/article/2334751/a-brief-history-of... It's as if people believed that all the microcomputing software of the 1970s and 1980s, from VisiCalc to Zork to the Macintosh, was done by waterfall design.

Right, some people believe that. But did any of the signatories of the Agile Manifesto?

Re: Saying goodbye to Agile

#198

Post by surgical_fire »

latentsea wrote: post #194
surgical_fire wrote: post #151

Earlier quoted context omitted.

> I have so far not see an organisation that would be following scrum, as it is described in the scrum guide; or kanban, as it is described in the kanban guide. I have seen or heard about various organisations that use these words, but they have little resemblance to what was actually proposed. If that's true, wouldn't it point at the process being impossible to implement? It is a myth. There exists a version of Agil…

>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 as it may be, does not a philosophy make. And this idea was not even new by the time the Agile manifesto came out (as explained in the linked blog post).

Re: Saying goodbye to Agile

#199

Post by eesmith »

tome wrote: post #197
eesmith wrote: post #190

Earlier quoted context omitted.

Yes, there is an entire narrative that first there was chaos, then there was waterfall, and then there was agile. For example, https://www.infoworld.com/article/2334751/a-brief-history-of... It's as if people believed that all the microcomputing software of the 1970s and 1980s, from VisiCalc to Zork to the Macintosh, was done by waterfall design.

Right, some people believe that. But did any of the signatories of the Agile Manifesto?

Oh, absolutely not.

Re: Saying goodbye to Agile

#200

Post by BrissyCoder »

tetrisgm wrote: post #113
BrissyCoder wrote: post #110

Earlier quoted context omitted.

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?

1. estimate this sprint. let's say it's 100 points. 2. oh no, you shipped 80 points. 3. "we need to better estimates": a) engineer spends more time trying to guess which direction the wind will blog b) engineer starts sandbagging estimates c) engineer changes nothing. looks bad next time the imaginary goal isn't met. "bob needs help estimating".

Yeah okay. Thanks for clarifying. I guess I thought when you said "punish" you meant something more dramatic!
Post reply on HN