Before I leap into the actual subject at hand, I want to look at an example of the problem:
The attached graphic is an excellent summary of everything that a good Product person does. You will note that "project management," "manage tickets," "compel or browbeat people to build X," and "use Jira" are nowhere to be seen. One of the enormous failures of the Scrum Guide, IMO, is that the PO is not explicitly required to be a product manager. Looking at the Guide, they are essentially ticket monkeys, in charge of ordering stories. They are effectively nothing but backlog managers.
Of course, in a frequent-release feedback-driven environment, there will be little or no backlog to manage because it will be changing continuously as we learn. There’s no point in a large backlog if we’re just going to throw away most of it. Managing a backlog with four items on it is hardly a full-time job, so backlog-manager POs often create busy work for themselves by adding unnecessary stories to the backlog or by bloating tickets by adding finer and finer details that will be discarded once construction begins and feedback is received. They are effectively waterfall-specification authors.
To me, POs should be spending that time doing actual project management (as laid out in that graphic) instead. A PO who is not also a PdM will fail.
Of course, to even come up with a Scrum "product goal," you need to be an actual product manager, but many people seem to miss that point, given that it's only implied by the Guide. I think that more POs need to learn how to do actual product management. The Scrum certs don't seem to teach that (with some notable exceptions—I took Jeff Patton's PSPO class and loved it. Scrum was never mentioned, however. 😄), or if they do, it doesn't stick.
Product Management is, I think, essential. Product Ownership is, I think, not.
So, all this leads up to what I actually want to talk about. When I publish things like the above, I often (and did) get the following response from a Scrum-trainer reader:
I don’t know where you get the notion that a PO trained by Scrum are not behaving as a product manager. In my experience all the details in your graphic are in my course material. So where do you get your information?
This is a common reaction that I get from Scrum trainers when I talk about Scrum-as-implemented as compared to Scrum-as-taught, so I think it deserves an answer.
First, I'm sure those trainers’ workshops are good, and all that PM stuff should be in the course material. It’s essential. Many great instructors are teaching great classes. I mentioned Jeff Patton earlier, for example. However, there are several things in play:
I’ve only rarely seen the Scrum that the trainers claim to be “real Scrum” in the wild. They often accuse me of not knowing what I’m talking about (sometimes quite stridently) when I’m describing what I actually see with my own eyes and what many of you report to me. I am sure that there are Scrum shops that do the “real Scrum,” they are teaching, but I’ve yet to witness one.
Not all workshops are of high quality, and actual Product Management, in all its glory, is typically not covered. Marty Cagen has observed the same thing.
Peers affect your behavior more than academic knowledge. If the org culture is messed up, people will follow organizational norms. This is true even when people attend workshops. Social interaction, along with organizational pressure and incentives, will always trump whatever you learn in class.
The issue isn't the quality of the teaching, it's what happens in actual practice. I can pretty much guarantee that the things covered in most high-quality classes are not put into actual practice nearly as much as the teachers wish.
Then there's the problem of the Scrum Guide, which is supposed to be definitive. Good classes teach all sorts of things that are not even hinted at by the Guide because you need those things to get Scrum to work at all. A lot of what they teach is inferred from this or that, not stated outright. Some of it is Lean or Agile thinking that you can’t even infer. That extra stuff is essential, but is way beyond what Scrum-as-defined is. To me, Scrum is what it says in the Guide. Everything else is Not-Scrum, no matter how essential. Scrum-by-the-guide taken at its word and in isolation is pretty worthless, IMO, and those great teachers agree, otherwise they wouldn’t supplement the Guide so heavily.
What those trainers and I usually disagree on is whether all that Agile stuff that is ignored by the Guide actually comprises Scrum. I think not.
Also, Scrum was initially positioned as a wrapper around XP that made Agile software development more palatable to backwards management. It was not XP, an Agile process. It was a wrapper around it that actually suppressed some of XP’s agility. I think Scrum is still essentially that. Scrum always wraps something else. That's pretty much confirmed by the rhetoric that comes out of the certificate mills, which claim that you can wrap Scrum around literally any kind of work. Feel free to do that if you want, but I don’t see much value, to be honest.
