I wouldn't fault it for lack of technical craft, that's not a specific statement in the original manifesto, except loosely maybe "working software". Largely forgotten now since more than a decade has passed, but even the poor implementation of Scrum has helped shut down the RUP hyper-documentation madness, massive unshippable releases with hundreds of bugs, etc.
When trying to explain "Why agile?" to new devs out of school, I struggle "Well... it helps to have been through a soul crushing waterfall deathmarch. If you read the manifesto after that, you will start to weep for joy." But they don't really get it.
So i could argue that even when badly done Scrum has improved the success rate and business satisfaction across the industry. Every couple of weeks the business gets some new functionality and the devs get feedback. Great! But I would agree, it's been long enough with Scrum, I'm ready for the next evolution in this story.
Much of it does also depend on the type of team, product, environment so that scrumbut customization seems nearly inevitable in my view.
Agree we need a way around the short-sighted prioritization, we've overlain some classical PM roadmap concepts to make sure we also chip away at longer term initiatives and debt.
In part one of this series (https://www.lambdacambridge.com/blog/2018-05-how-scrum-destr...) I explain how technical craft was key in all the agile methodologies, except Scrum. So I think that was part of the thinking in the original manifesto, but not expressed at the time (fish don't perceive water?)
I suppose you're right that Scrum is better than waterfall deathmarches, but I hope we can do even better.
You assert that technical craft was key I think by inferring the bent of the associated methodology of each the people involved?
I don't agree, I think the main aim of agile was to solve the extreme dysfunction with the business-side and non-technical people, and there it has succeeded. (This is perhaps also reflected in your observation that XP interest has ebbed while scrum continues to climb in popularity.)
Quotes from that:
"At the core, I believe Agile Methodologists are really about "mushy" stuff—about delivering good products to customers by operating in an environment that does more than talk about "people as our most important asset" but actually "acts" as if people were the most important, and lose the word "asset". So in the final analysis, the meteoric rise of interest in—and sometimes tremendous criticism of—Agile Methodologies is about the mushy stuff of values and culture."
"For example, I think that ultimately, Extreme Programming has mushroomed in use and interest, not because of pair-programming or refactoring, but because, taken as a whole, the practices define a developer community freed from the baggage of Dilbertesque corporations."
Fair enough, I agree that avoiding the baggage of Dilbertesque (great word!) corporations was key.
My point was just that all the methods except agile had explicit technical requirements. XP required TDD and pair programming which was incredibly extreme at the time (and still is fairly out there).
These were people meeting up at OOPSLA. They were programmers' programmers. I absolutely think craft and technical quality was important to them. I think it was so intrinsically important that they didn't express it clearly in the manifesto.
When trying to explain "Why agile?" to new devs out of school, I struggle "Well... it helps to have been through a soul crushing waterfall deathmarch. If you read the manifesto after that, you will start to weep for joy." But they don't really get it.
So i could argue that even when badly done Scrum has improved the success rate and business satisfaction across the industry. Every couple of weeks the business gets some new functionality and the devs get feedback. Great! But I would agree, it's been long enough with Scrum, I'm ready for the next evolution in this story.
Much of it does also depend on the type of team, product, environment so that scrumbut customization seems nearly inevitable in my view.
Agree we need a way around the short-sighted prioritization, we've overlain some classical PM roadmap concepts to make sure we also chip away at longer term initiatives and debt.