In the same way, I don't particularly care if Scrum fails because people consistently fail to implement it "right" or if it fails because it's a flawed concept at its heart. Either way, odds are that my team will suffer if we introduce Scrum: if Scrum isn't fundamentally flawed, it's still hubris to assume that we'll be the team that finally gets it right.
[0]
> “Listen, if tomorrow we pulled into Biren and someone told you there were shamble-men in the woods, would you believe them?” My father shook his head.
> “What if two people told you?” Another shake.
> Ben leaned forward on his stump. “What if a dozen people told you, with perfect earnestness, that shamble-men were out in the fields, eating—”
> “Of course I wouldn’t believe them,” my father said, irritated. “It’s ridiculous.”
> “Of course it is,” Ben agreed, raising a finger. “But the real question is this: Would you go into the woods?”
“Steer clear of things called Scrum” is a very limited guide to how to develop software, actually figuring out what the methodological pitfalls are and addressing them is something that is, I would submit, worth pursuing in more detail, especially for people who have some influence over substantive development methodology choices, rather than only having a choice of whether or not to avoid some place that is imposing a thing that they call “Scrum”. (And, really, you should probably steer clear of any place where being in the dev team gives you no input on substantive methodological decisions irrespective of whether what is imposed is called “Scrum”.)
I am suggesting that calling it Scrum will increase your risk of failure, and you'll likely be better off choosing a completely different methodology that has more consistency in implementation and a higher success rate.
By all means let's dig into what specific details of the implemented methodologies work well and which don't! But taking the output of that process and calling it "Real Scrum™" will just lead to further confusion.
I’m not saying “Real Scrum™” should be the name of the output. I’m saying that diagnosing the problem is obscured by not distinguishing between “what is in the Scrum Guide” and “what someone is doing and calling Scrum”, especially as the latter can be a diversity of mutually incompatible approaches.
Much less TLDRish, but zooming out to take a broader perspective:
There seems to be an intense agreement with both of the following statements:
1. The practices in the industry that the people imposing them call “Scrum” are often quite bad, and
2. The practices in the industry that the people imposing them call “Scrum” often bear very little relationship to the methodology laid out in any version of the Scrum Guide.
Apparently because consensus is a bad thing and there aren’t enough real issues to argue about, some people who agree on points #1 and #2 seem to have squared off into a weird tribal battle over whether “Scrum” is bad due to #1 specifically that mostly turns on whether or not the One True Meaning of “Scrum”” is the thing they agree is very often bad in #1 or the thing they agree that thing differ differs from in #2. My position is that this is mostly silly, especially since there are very few contexts where both of those things are meaningful to consider: the first is so inconsistent in terms of actual practices that it is useless describe as a single thing in the context of concrete development practice, though it may be interesting to discuss as an industry cultural phenomenon, whereas particular practices or combinations of practices within its ambit can be discussed more productively when the focus is on concrete development practice; the second is specific enough to be useful to discuss in the context of concrete development practices, but not much else, except maybe in terms of its historical role in relation to the cultural phenomenon. With a little care to being clear what they are talking about and the what it is people are looking for from a discussion, the whole semantic side-debate can be avoided.
I appreciate you being willing to articulate an unpopular opinion :-)
Well, if there was a distinct Product Owner and they delegated this to the Scrum Master, it may have been by-the-Guide Scrum, but just extraordinarily poor judgement.
But it sounds like you had a dev team that wasn’t using Scrum, got a Scrum Master and no P.O., and gave the Scrum Master some or all of the P.O. duties. Even as weakly prescriptive as the current Scrum Guide is, that's still not real Scrum.
(Moreover, most places that purport to do Scrum also purport to do Agile, and having a bottleneck between the team and client is even more explicitly not Agile than it is not Scrum.)
Which is not to say your scenario isn’t a valid illustration of problems with Scrum (or Agile) in terms of the (largely cargo-cult) common behavior going under the name.
Its just that in terms of clarity of discussion of what practices should be adopted, its worth noting that the problems being identified are with practices which the Scrum Guide (at the organizational level) and Agile Manifesto (and the broad practice level) are pretty explicitly directed against. Not just in terms of the communication bottleneck but also things like:
> tickets taking exactly one sprint to complete
This seems to be confusing increments or Sprint Backlog items (for which the dev team is responaible for making from Product Backlog items) with Product Backlog items that the P.O. is responsible for (and also Product Backlog items with client tickets, though the Scrum Guide doesn't explicitly discuss client tickets at all — in fact, it mentions customers only once — and so doesn’t explicitly distinguish them from Product Backlog items. The P.O. is free to, and responsible for, structure Product Backlog items optimally based on achieving customer goals, which is almost never realistically going to be 1:1 with tickets.)
EDIT: I want to make extra clear that I am neither disagreeing with the criticism of “Scrum as the thing that I am likely to have imposed on me if my workplace says they are doing Scrum” nor arguing that the Scrum Guide (or Agile Manifesto and principals) are anything like perfect edicts that can only be failed but never fail.
I am just saying it is important to recognize the difference between “this failure is caused by a set of practices a workplace adopted under the label ‘Scrum’” and “this failure is caused by adopting the practices described in the Scrum Guide”, eepecially if you are interested in what good practices might be.