Willem-Jan always writes insightful pieces. But I disagree on a fundamental point:
Whenever he covers a problem with Scrum, he assumes that the problem is with the person using Scrum. I don't assume that - and I realized long ago that Scrum is usually not fit-for-purpose.
The assumption that Scrum cannot be the problem seems to rest on the assumption that the creators of Scrum were great thinkers - Bibilical thinkers - and that they constructed a perfect system - a system so perfect that it is sacrosanct. Scrum can _never_ be the problem, by definition. That sounds like a religion to me.
But the creators of Scrum were not great thiners. In fact, they stole Scrum from earlier work, and twisted it to fit things it was not intended for.
Scrum is not complicated. It is extremely simple.
But it is true, that if you insist on using a hammer to turn a screw, you have to be really, really clever and skilled, and using the hammer in that way will seem like it is really difficult to use properly - but actually, you should not be using a hammer for that purpose.
Referring to Willem-Jan's article, which brings up excellent points as usual, he writes,
"Definition of a Product Goal. Product Backlog Management. Planning the Sprint around a Sprint Goal....But many teams use the concept of Sprints as an excuse to not look further. They consider the Product Backlog to be a list of things to do."
Well yes, because that is all it says to do. Scrum treats the PO as someone who has great insight about the users and can single-handedly create a product vision. But how many POs have you met like that? Sure, if you are a single team in a startup, in which the founder realized a need and launched a company to meet that need, then maybe the PO is a visionary; but 90% of the time the PO does not really know what users need - not really. And thatis why we need Product Design, and it needs to be a robust function, with an experienced product design lead; and that function needs to work closely with the dev teams, to test the market with MVPs. That whole process - the way that works - is entirely unaddressed by Scrum.
Defenders of Scrum will say "But Scrum is just a framework - you can add that." But that makes no sense, because (1) you would have to change Scrum to add it - the PO role has to change, the way the dev team functions needs to change; and (2) if Scrum leaves out something so huge, then Scrum is nothing short of misleading and dangerous.
Indeed, if Willem-Jan were to lead my teams, I would have complete confidence, because he clearly knows what he is doing. He sees the gaps in Scrum, and its problems. Where we differ is that he excuses it and adds guidance about what to _really_ do; but I don't excuse it.
