HN Explorer

Show HN: An addendum to the Agile Manifesto for the AI era (github.com)

7 points by brackishman ↗ HN
I'm a VP of Engineering with 20 years in the field. I've been thinking deeply on why AI is breaking every engineering practice, and it led me to the conclusion that the Agile Manifesto's values need updating.

The core argument: AI made producing software cheap, but understanding it is still expensive. The Manifesto optimizes for the former. This addendum shifts the emphasis toward the latter.

Four updated values, three refined principles, with reasoning for each. Happy to discuss and defend any of it.

7 comments

[ 2.6 ms ] story [ 24.4 ms ] thread
9rx
> I'm a VP of Engineering ... Happy to discuss and defend any of it.

The original Agile Manifesto abolishes VP roles. Are these amendments an effort to try and save your job?

smackeyacky
It’s pretty obvious that Agile as practiced in most places is a failure, only highlighted by how fast coding has become. The problem it tries to solve was always the wrong one. It has become obvious that it isn’t the speed of iteration it’s the crappy requirements most organisations generate.

This is because your average BA or project manager have long gotten away with blaming programmers for missed deadlines. If you’ve worked both sides of the fence you know the users only vaguely know what they want, the BA role is essentially an incredibly lazy one (I made a wrong ticket but nobody knows it’s wrong until UAT so who gives a fuck about making them right). No matter how your sprint is organised or how many stupid ceremonies you insist on, if you can’t be arsed doing the hard work of specification the whole process is pointless.

I truly hope AI starts doing 100% of the coding so that the tide properly goes out on this farce.

Kim_Bruning
Oh, my impression is that there's many iterative approaches to writing code (and doing other things besides). All of them work for a while, and then either someone "simplifies" out the iteration part, or in some way they render the iterative part toothless.

Basically you end up with something resembling a cargo cult, with all the rituals still there, but the tightly coupled feedback loop is missing.

Quick question: There's some sort of minor UAT ~once a week (or per whatever your cycle is), RIGHT? And then you find out umpteen things wrong (with the software and with the specs) , and you fix them; RIGHT?

If you have an actual commissioning or final UAT at the end of your project, it's just a formality with cake RIGHT?

Else how is that even agile? :-P

disrael
I like what you've done but doesn't

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

need changing also? I think the software needs to be delivered early and continuously, but not necessarily to the customer in production.

Delivering directly to the customer made sense when there was much less software in the world and nearly anything you made was useful. These days the last thing customers need is more half baked software to have to evaluate.

stevenalowe
The proposal elevates team learning above delivering working software, which is contrary to the point of any programming job. Expect to be fired, a lot.
svilen_dobrev
this new "understanding" priority reminds me of :

  "... This means the speed of the project is proportional to the speed at which information moves between people's heads. Every obstacle to detecting and moving information between heads slows the project. Understanding and attending to this issue is essential to playing the game effectively. ..."
from Alistair.Cockburn's 2004 "The end of software engineering and the start of economic-cooperative gaming " - https://web.archive.org/web/20140329202313/http://alistair.c...

Even then , coding is not mentioned..

What do you think of it?