This was very hard to read and I wasn't even sure what is the conclusion. One thing I didn't understand, how does one disagree with agile dev processes, which are mostly built on top of the fact that many things, especially UX, you can't know in advance, so you have to build something small, get feedback, then either scrap it or improve it. The process described here sounds exactly like someone spending weeks if not months designing the GUI, then devs spend weeks or months implementing it, without any cross-communication, so it's kind of obvious it needs to be fully re-done so many times. People started switching to agile dev specifically to shorten the feedback loop and scrap bad ideas faster.
> so it's kind of obvious it needs to be fully re-done so many times.
But it hasn't really caught on in the management layer. Sure, they use all the right Agile buzzwords, but they still put features A, B and C into the plan, and ask questions like "when will B be finished?"
"Finished?". Nah - we're the stewards of 14 bugs-as-a-service. We won't so much "finish B" as much as we'll transition to becoming the stewards of 15 bugs-as-a-service.
This precisely. They treat development (programming) as the slowest part of the process, but that has not been my experience since Figma came out. I’ve not seen agile done right since it arrived, we’re just doing waterfall with sprints.
