And then, over time, it became clear that, for whatever reason, management just wasn't going for it. So all these different bits and bobs pivoted and morphed and re-scoped into a process by which the stone tries to squeeze more blood out of itself.
IMO, the most valuable bit of Scrum isn't user stories, or story points, or sprinting, or having a Scrum Master, or burndown charts, or anything like that. It's the idea of having a single, designated person whose job is to tell people, "no": The Product Owner.
The dirty secret is, velocity is a crap metric. It unskeptically measures total things implemented, even though we all know that only a portion - I'm guessing often less than half - of those actually needed to be implemented. Meaning that the best way to increase a product team's actual productivity isn't to increase velocity, it's to maximize the average usefulness of features being implemented. Preferably by identifying the useless and less-useful ones ones, and deciding not to implement them. Or, equivalently, identifying the ones that seem most likely to be useful given the currently available information, and making sure those are always the ones at the top of the to-do list.
My suspicion is that, the better your product manager is at that particular job, the less need there is for any of the fancy ceremonies. Because most of those ceremonies aren't there for the developers' benefit; they're really only there to make it easier for the PO to scope and prioritize features.
If the quality of your estimations has ever come up on your annual review, that's them bargaining you down by making you feel bad about yourself.
Someone in a video I watched recently pointed out that story points per week is a graph plotting time on both axes.
One of the earlier agile methodologies (FDD) had one thing figured out: the law of large numbers works just fine for long-term estimation, as long as you can identify the stories, and the range of story 'sizes' is within an order of magnitude (eg, a day vs 2 weeks). You don't have to give a shit if a story is 4 points or 7. That's a waste of everyone's time and especially energy. It's horizontal aggression condensed into a management model. We need to start refusing, as a collective, to engage. The only discussion you need to have is whether this story is less than two weeks, more than two weeks, or way more than two weeks. Those happen at a much lower frequency.
But that requires a very engaged PO who really gets what grooming is really about. Also, I don't know what it is with MBA types, but it really seems like anything that can be turned into a KPI, will be turned into a KPI, without ever pausing to think about whether it makes any sense to do so. And that makes story points radioactive: In the absence of intense and intelligent regulatory oversight, their potential value is more-or-less negated by their potential for abuse and misuse.
Incidentally, this is what fascinates me about the Forth approach: The unflinching dedication to stripping the system down to only the things that you actually need. The problem I see is, the Forth way of doing it seems to assume you're working with an army of one. How do you scale that up to a modern product team that may comprise 10, 50, 100, even 1000 people?
Yep I agree with that.
Although getting the development process right is critical too with all the complexity in today's web stacks etc. 20 years ago dev processes were horrible and error prone compared to today. For example if you had a word doc with the manual install steps that got printed and filled in with specific details for that customer deployment's to hand over to the team that does custom installs, you were lucky. We now have hooks from Github to deploy. That's one example.
At one point, years into the Agile movement, we were wrapping up a very difficult meeting and I said words to the effect, "You know, we knew going into this that most of the problems in a project come from the requirements process. We have tons of studies that show that. And instead of tackling that problem, we just spent 10 years trying to get better at our part of the development process. Why did we do that? Did we think we would shame the business and management people into doing their jobs better?"
We are the drunk looking for his keys under the street light because the light is better here, instead of in the alley where we dropped them. I want another book called "the inmates are running the asylum" but about software development instead of design concerns.