Live data from Hacker News

Saying goodbye to Agile

lewiscampbell.tech

181–190 of 271 posts

Re: Saying goodbye to Agile

#181
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 much to add just wanted to say I share the sentiment and it matches my experience :-) . I'm not smart enough to NOT keep it simple; 90% of stuff I work on at $company is really a CRUDbox and I do NOT want to "astronaut-architect" the whole thing. Comprehensive test-suite, push to prod multiple times a day, feedback, dev.

That's it really.

Re: Saying goodbye to Agile

#182
Saying the Agile manifesto was void of meaning is ridiculous.

- Individuals and interactions over processes and tools - Working software over comprehensive documentation - Customer collaboration over contract negotiation - Responding to change over following a plan

The problem is that the Agile industry mostly didn't follow the Agile manifesto and ended up with monstruosity like SCRUM, which is all about processes over people.

Daily Standups, Retrospective, Backlog Grooming = PROCESS

This crap should all be replaced with async written communication (for quality of life and recording), but each team should ultimately be free to decide.

The Agile manifesto was all about freedom and it was turned into a jail.

Re: Saying goodbye to Agile

#183
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 than questioning whether signalling systems work.

Re: Saying goodbye to Agile

#184

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…

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

That's not agile.

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

Maybe this is why so many people can't even try to do agile. It sounds bad. But it works great.

Re: Saying goodbye to Agile

#185

These arguments are pointless. Working software is shipped using either method, some combination, or no method at all. Hell, half the devices in your life probably run some hacked together crap that was built by people who barely knew how to program and eschewed version control for USB sticks. I really hate discussions of "software" as if the software in an F-35, the software presenting data on a webpage, and the sof…

Doesn’t the F-35 need to be rebooted on a regular basis to keep it running. That sounds exactly like my TV.

Re: Saying goodbye to Agile

#186

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

> 3. "we need to better estimates"

Push back on that. Agile says other things are more important.

Re: Saying goodbye to Agile

#187
post #166

Earlier quoted context omitted.

I mean, Switzerland and North Korea both call themselves democracies but the specifics matter. The specifics matter! These discussions are always fascinating in a sort of baffling way to me because I've only had great experiences with what I call agile. Like, you bring it into the team and within months everyone is gushing about how much better life is now. Yet threads like this one are full of people reporting awful…

> The deeply unexpected thing about that, to me, is, if they hate some parts of the process, why are they keeping them? Why are you assuming that they are given a choice? In my experience, whenever a team is trying "agile" in some way but hate it AND are given the choice, they drop it ASAP and are 100% convinced that they are better off without it. Those that hate it and don't stop doing it, are doing so because they…

> whenever a team is trying "agile" in some way but hate it AND are given the choice, they drop it ASAP

Isnt that in itself "agile"? And I specifically dont mean following a religous ceremony plan etc but recognizing that a part of their process isnt working and then changing it. To me thats the entire point of actual agile. You try a process, it doesnt work, you analyze, and adapt.

Re: Saying goodbye to Agile

#188

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/

[deleted]

Re: Saying goodbye to Agile

#189
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…

Communism comes to mind.

It's led to misery every time - but it's always because they just "did it wrong"

Re: Saying goodbye to Agile

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

Post reply on HN