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.
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.
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
My contention is not “holding it wrong”, my contention is that it’s irredeemably flawed because the nature of it puts 99% of the actual (not fabricated) work and responsibility solely on developers, making the project manages and BA useless noise you have to fight just to get anything finished.
Extreme Programming, RUP, Spiral Model, RAD, DSDM, probably some variants of CMMI, ISO 9001 , we can continue this list for a while or even get into other disciplines. Each time you start out with a real feedback loop doing real work, and in the end everyone has cargo culted it. Mostly because a lot of people don't grok what feedback loops are, and think they can leave 'em out. I'm not even sure the project managers and BAs are the only ones to blame here. The whole organization conspires to replace scary feedback (and it really is scary!) with comfortable processes. Users don't want to talk to devs. Devs don't want to ship half-baked things. Managers need predictability for their spreadsheets. Everyone gets the cargo cult they deserve. "We mostly just took the good parts" := We left out the active ingredient.
After a while someone comes along with this radical new invention: "let's ACTUALLY apply a feedback loop", and here we go again.
To be fair, it DOES work for a while. you can start out dressing in drag and doing the hula[1] for all I care, so long as you iterate and run a feedback loop! At some point you'll actually successfully build a million dollar product anyway. .... Of course people will then copy you and dress in leaf skirts and dance all night long, and THEIR projects all fail.
This has been "Kim's overly oversimplified history of innovation in development methodologies". You're welcome, I'm sure.
The original Agile Manifesto abolishes VP roles. Are these amendments an effort to try and save your job?
Winston Royce, in his book, invented the waterfall methodology as a hypothetical of what not to do in order to help explain his core thesis. It is not a real thing. Why do you suggest the Agile Manifesto was created to help avoid leaning on a strawman?
Where you find a VP, Agile isn't applicable. At least not in its entirety. It it is likely that you can still cherry-pick some ideas from it to apply to your non-Agile situation. "Do your manager's job for them" is often considered common wisdom after all.