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

111–120 of 271 posts

Re: Saying goodbye to Agile

#111

Post by zelphirkalt »

mitthrowaway2 wrote: post #89
brigandish wrote: post #35

Earlier quoted context omitted.

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?

From my reading, it's really quite brilliant. He just says that he's about to start the tasks that, in reality, he's just finishing up. Then he delays reporting that the task is done. His estimates are then always made with perfect hindsight.

This only works though, if one is working in isolation and no one else checks out the work before the time one commits to the work. That would mean being some lone expert in that part of the product, which is not a good sign for the business, because bus factors of 1.

Re: Saying goodbye to Agile

#112

Post by globular-toast »

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 never really got the "Individuals and interactions over processes and tools" one. What processes and tools is it talking about? Surely it's not saying I should talk to a colleague to track a change rather than use version control? I feel like I'm missing some context of what "tools and processes" it is talking about.

The others I get, but only after having already spent years in software. I guess like many things you have to see the other way before you can appreciate the better way.

Re: Saying goodbye to Agile

#113

Post by tetrisgm »

BrissyCoder wrote: post #110
tetrisgm wrote: post #102

Good. I've worked in several organizations where we had Agile. With the years, I've come to think about it as a sing and dance designed to make the project managers, PMs and sales feel like the actually impactful ICs considered them. There's something really absurd about making programmers sit down and say it's a 5 or 8 effort, then punish them for being "wrong". All it achieves is reduce velocity at best, with the i…

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

Re: Saying goodbye to Agile

#114

Post by FpUser »

4ggr0 wrote: post #81
FpUser wrote: post #12

Lucky me, I've never had to say Hi Agile in a first place. It is a tumor. Been in programming since 80s. Mostly on my own except 6 years long stint at the company. Quit in 2000 from position of CTO

at the same time, how can you judge something so harshly if you've never experienced it yourself.

Because I had "pleasure" watching others doing it. One does not have to step into shit personally

Re: Saying goodbye to Agile

#115

Post by magicalhippo »

t43562 wrote: post #43
operatingthetan wrote: post #31

Earlier quoted context omitted.

I can't count how many times I've seen "agile" projects that were just actually waterfall due to demands from stakeholders.

Absolutely! "You're going to do agile .... and this list of features will be ready on September 20th." "Oh, feature no 32 is going to take months and we realised that users can just...." "No"

> "You're going to do agile .... and this list of features will be ready on September 20th."

Well often the real world forces it upon you. As in customer will switch invoicing system on September 20th, integrations have to be ready by then.

We have a lot of this, and hard cut-off is very frequent. If we ain't got all those deliverables implemented by then we will lose customers.

Re: Saying goodbye to Agile

#116

Post by zelphirkalt »

dannyobrien wrote: post #44

I think it's worth linking to the original Agile Manifesto[1], because that's pretty much all the consensus you're ever going to get on what's "agile" and "what's not". Lewis is right that most of these principles were described before the manifesto, but I can vouch for the near-impossibility in many contexts of convincing anyone who wasn't a coder (and a lot of coders too) why these might be sensible defaults. For e…

No, you are not going to get that consensus, because middle management and hire ups don't want to know what agile actually means, but want to continue believing, that the processes they impose are agile, and they have probably never even seen that page. In a truly agile team, the team takes many if not all of their work and responsibilities, so that even the jobs of PMs and low middle management would be on the line. As we know it is difficult to get someone to understand something, when their income depends on not understanding it.

Re: Saying goodbye to Agile

#117

Post by watwut »

z3t4 wrote: post #59
patcon wrote: post #30

Earlier quoted context omitted.

I suspect there might not be love for this angle here, but there's something else that follows this format: God. Spirituality. Religion. I'm not religious is any traditional sense, but I'd argue that it's not always the hallmark of a bad dynamic when a system always asks of you to do inner work when failures happen in contact with the real world. Sometimes that's a healthier mode than the alternative -- externalizing…

when it comes to some diets, some only work if you follow them wholeheartedly, like meat only diet, one speck of peppar might be enough to cause an inflammation. But generally you can't take a process that worked well for another person or company and apply it on you or your company. Like for example a training program, you can't just take a training program from a professional athlete and reuse it on your kid and ex…

A process that fails when you slightly diverge is process that fails. Because all human orgs diverge from stated process here or there. Including army which puts huge amounts of resources into making people comply with everything.

Re: Saying goodbye to Agile

#118

Post by ezekiel68 »

Ward Cunningham [edit: oops, it was Kent Beck] had it right, long ago, when he wrote in "Extreme Programming" [paraphrase]: You don't drive to Florida by carefully lining up your car in New York on I-95 South, locking the steering wheel, and then pressing the accelerator until you arrive.

This was really all that Agile was ever trying to avoid -- the tyranny of imaginedf omniscience. The bad old way (which I did labor under in the '90s) set up a Gant chart of dependent requirement up front, during a "design phase" which completely de-valued learnings and insights gained along the way as a software system was constructed during the "implementation phase". It was the best we had till then, but many software projects were failing due to their inability to adapt to unforeseen design flaws or to the feedback of stakeholders (once the software finally got into their hands).

I don't know why the ceremonies became ossified and sacred. I guess every movement must confront the danger of settling for form over substance. I do know one thing. You can't build an amazon dot com, a Facebook, or a Grand Theft Auto in a 1-million token context session with an LLM. I'm sure you can do it with many such sessions, but it won't be an LLM that ties it all together properly (again - too much context). And I say this as an enthusiastic user of agentic programming.

Re: Saying goodbye to Agile

#119

Post by codeduck »

operatingthetan wrote: post #31
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.

Ah yes, the old Agile-as-drunken-waterfall pattern

Re: Saying goodbye to Agile

#120

Post by zelphirkalt »

9dev wrote: post #67
ytoawwhra92 wrote: post #55

Earlier quoted context omitted.

The point is that sometimes you don't know the spec is wrong until you've built the software and it's being used.

Still though, that cycle can be iterated many times in a single day. Write a spec, let the agent build it, use the software, evaluate results, repeat.

Until the agents start touching things that already worked well before and break them.
Post reply on HN