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

31–40 of 271 posts

Re: Saying goodbye to Agile

#31

Post by operatingthetan »

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.

Re: Saying goodbye to Agile

#32

Post by moron4hire »

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…

Dude, this mode of ex post facto rationalization is waaaay older than communism. It's basically one of the main "retention warnings" of most religions.

Re: Saying goodbye to Agile

#33

Post by t43562 »

If your company doesn't fundamentally want "agility" then it will be an exercise in futility but if you're a person who doesn't want to do useless work then you're an agile proponent fundamentally.

Re: Saying goodbye to Agile

#34

Post by tiew9Vii »

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.

Seen this multiple times

The problem is agile as in the original manifesto was an ethos, not a process.

Everything since the manifesto, called agile, has tried to wrap an ethos up as a process, playing lip service forgetting the ethos.

High performing teams are already doing agile, following the ethos without attempting to be agile. High performing teams made to do agile become average teams and low performing teams made to do agile can become average teams.

Re: Saying goodbye to Agile

#35

Post by brigandish »

darkhelmet wrote: post #18

Agile, as implemented in every big company that I've worked for, was a lie. It was really telling at a smaller company that was trying to behave like a big company. I asked a coworker (who had great metrics) what the secret was for dealing with the middle-management-heavy and quite dysfunctional environment. He told me how he did it. Paraphrased: "It's easy. During each sprint, I work on the next sprint's work. Once…

How did he see into the future to know which work he'd be doing on the next sprint, and how did he also finish the current sprint's work with a bullseye thus allowing the next sprint's to begin and match it?

Re: Saying goodbye to Agile

#36

Post by prerok »

TFA first claims that agile invented none of the things it encompasses, seems not to challenge those claims, but then just jumps to agile is dead because LLMs can code based on spec.

This is just a confusing and confused article.

Agile just finally embraced that specs are incomplete and can even be wrong because the writer of the spec does not yet really know or understand what they want. So they need working software to show the spec in action and then we can iterate on the results.

We are still doing that and will be doing it in the foreseeable future. Agile is very much alive and here to stay.

Re: Saying goodbye to Agile

#37

Post by t43562 »

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 because there are not enough tests ... you write more tests don't you? Why would a method be forgiving when compilers and reality itself aren't?

Re: Saying goodbye to Agile

#38

Post by jeremyjh »

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.

Re: Saying goodbye to Agile

#39

Post by anilakar »

hcfman wrote: post #19

The way the author defined water fall makes it sound pretty good to me. Put your hand up if you are ever programming with poor specs? Put your hand up if you have a better idea of what really was wanted after the first cut? And what I really dislike is those that try to design a Swiss Army knife from day one when they haven’t a clue. Jump immediately into over complexity.

Wasn't the whole waterfall model originally a caricature to higlight all the issues one will inevitably encounter if they eliminate feedback loops and go with a strictly sequential development paradigm?

Re: Saying goodbye to Agile

#40

Post by protocolture »

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 feel like I see it all the time.

Sometimes its justified. Like "This is only satisfied when x, y and z are correct"

But then you get

"We will do x and y as a compromise but not z"

And then you have to explain that, the compromise is actually worse.

Post reply on HN