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

201–210 of 271 posts

Re: Saying goodbye to Agile

#201

Post by mytailorisrich »

t43562 wrote: post #177
mytailorisrich wrote: post #141

Earlier quoted context omitted.

> "You're going to do agile .... and this list of features will be ready on September 20th." That's OK, the latter is not incompatible with the former. Agile vs waterfall is orthogonal with having to commit to deadlines to deliver features.

Some tasks may simply not be possible or not in the time available. Agile just sort of tells you that - you can see how things are going and if they're going right or not. Then you have a choice - find something to cut out or accept a later date. This is a mode of thinking that I find non developers have difficulty accepting. They want it all and they want it now and their modus operandi is to keep pretending that it…

Sure but that's life, not an issue with Agile. In fact, because Agile values "working software" in principle you should have more "working software" at the deadline than if you had gone waterfall-ish and spent your time writing detailed docs upfront.

Re: Saying goodbye to Agile

#202

Post by yobbo »

9dev wrote: post #65
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…

> […] 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…

They are conditions to be met. It's not enough to proclaim them as "your process" and expect results.

When playing piano, the condition you are measured by is acoustic harmonies in the air, not finger movements. The only reasonable advice is either practice more or give up. If you are tone-deaf, it's not reasonable to expect you will learn to play the piano.

Re: Saying goodbye to Agile

#203

Post by latentsea »

dijit wrote: post #105
chrchr wrote: post #97

Earlier quoted context omitted.

Yes, but on the other hand, there's https://www.reddit.com/r/ididnthaveeggs/ , which collects cases of home cooks making inadvisable recipe substitutions and then complaining to the recipe creators that the resulting dish tasted bad. Sometimes there are essential ingredients and skipping them or replacing them with something else makes success impossible.

An appealing analogy but recipes have defined testable outcomes. You know what a Victoria sponge is supposed to look like (there's probably even a picture of one in the book). You can perfectly evaluate when a substitute has ruined it. Agile doesn't have that, there is no functional equivelant of "the cake should be moist and rise evenly". What does "Agile" adoption look like? Faster delivery? Happier Developers? Mor…

There is one and only one essential ingredient of agile, and it's feedback loops. That's all agile really is. The employment of feedback loops.

Re: Saying goodbye to Agile

#204

Post by lmm »

UnreachableCode wrote: post #195
lmm wrote: post #183

Earlier quoted context omitted.

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

Sure. Occasionally there really is a problem in your signalling system. Even more rarely there's a fundamental design flaw.

If and when I see actually-doing-agile fail, I'll change my mind. But so far I've seen a direct correlation between the extent to which an organisation was actually-doing-agile and the effectiveness of that organisation, across a wide range of industries/environments/countries.

Re: Saying goodbye to Agile

#205

Post by latentsea »

surgical_fire wrote: post #198
latentsea wrote: post #194

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…

Useless as it might seem, I really do think it is actually that basic. Is it useless? Hardly. Take out feedback loops and see what happens.

Re: Saying goodbye to Agile

#206

Post by ilitirit »

tkel wrote: post #145
ilitirit wrote: post #90

I personally have never worked in a team where Agile (the concept) has failed. But I've also seen it fail all around me. Especially when it's mandated without buy-in. Or when people just don't "get it". e.g. - 45 minute "standups" (!?) - PI "planning" that consisting of deadlines and glorified multiplayer MS Paint - Rigid adherence to ceremonies or processes that add zero value - Retros that focus on complaints and v…

Venting is important. When you don't, tension builds and then explodes. It's necessary to give people a way to air complaints and be heard. And if your team has people with some organizational and social skills, you can channel that into action.

> Venting is important.

Of course. But you shouldn't run retros that are focused on it.

Re: Saying goodbye to Agile

#207

Post by locknitpicker »

duskdozer wrote: post #94
locknitpicker wrote: post #83

Earlier quoted context omitted.

> 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. A concept older than agentic software development is bad workmen blaming his tools. I mean, if you can't possibly hammer a nail then is it reasonable to blame the hammer?

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

Re: Saying goodbye to Agile

#208

Post by cindyllm »

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…

[dead]

Re: Saying goodbye to Agile

#209

Post by locknitpicker »

strangegecko wrote: post #84
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…

The problem is a disconnect between management and those who build. My thoughts when PE forced Agile on my employer were dismissed as "you're the technical expert, we're the process experts". As someone without decision power, you read words of empowerment but your reality is a different one, and you're left resolving that dissonance on your own (quietly, otherwise you get pushed aside).

> The problem is a disconnect between management and those who build.

That would clearly be a problem that falls well inside the domain "you are not doing enough Agile".

A key principle of Agile is literally "Business people and developers must work together daily throughout the project."

If a team suffers from that disconnect, it's failing Agile.

More to the point, whatever they are doing is not working, and Agile would fix it.

Re: Saying goodbye to Agile

#210

Post by locknitpicker »

madeofpalk wrote: post #155
strangegecko wrote: post #84

Earlier quoted context omitted.

The problem is a disconnect between management and those who build. My thoughts when PE forced Agile on my employer were dismissed as "you're the technical expert, we're the process experts". As someone without decision power, you read words of empowerment but your reality is a different one, and you're left resolving that dissonance on your own (quietly, otherwise you get pushed aside).

This is the problem with 'Agile', and why people refer to it as "Capital-A Agile". As always, the problem isn't the process, the problem is the people. There's whole industries out there set up to sell A Process, so they come in and try to force something like this on you. They want to stay in business, so they need to make sure they have something to sell. That's the dysfunction - a company that is forcing this labo…

> As always, the problem isn't the process, the problem is the people. There's whole industries out there set up to sell A Process, so they come in and try to force something like this on you.

I would go as far as to claim the problem is middle management types, who feel pressured to adopt buzzwords and want to micromanage things to cultivate an image of control and progress to justify their role.

It's the same type that brags about scrum but don't even bother to show in standup meetings.

Post reply on HN