Thank you for listing out the cancer that is Scrum.
Anecdotal story:
Are product owners engineers? Typically not, and this is where the problem starts for most engineering teams doing "Scrum".
I work with overzealous POs (who aren't engineers) and since they "own" the product and the backlog (as according to that definition), they own everything. Since the PO is supposed to manage the backlog, we have POs running backlog refinement sessions where the vast majority of topics and tickets being discussed are of an engineering/technical nature (lots of stuff that is periphery to the product features such as security enhancements, build pipelines, performance, code quality and tests, etc.) and since the PO "owns" it all it is their decision/opinion what counts, i.e. they pretend to be tech-leads.
I even work with a PO who insists of writing all the engineering tickets (title/description), where no engineer can understand what the ticket is about since this person simply doesn't have the ability to clearly and concisely articulate engineering tasks.
Now, obviously people will point out that this is not a problem with Scrum but a culture issue with the organisation, and I agree (my organisation has many ingrained and deeply embedded institutional dysfunctions) but the Scrum definitions aren't helping engineering teams.
Anecdotal story:
Are product owners engineers? Typically not, and this is where the problem starts for most engineering teams doing "Scrum".
I work with overzealous POs (who aren't engineers) and since they "own" the product and the backlog (as according to that definition), they own everything. Since the PO is supposed to manage the backlog, we have POs running backlog refinement sessions where the vast majority of topics and tickets being discussed are of an engineering/technical nature (lots of stuff that is periphery to the product features such as security enhancements, build pipelines, performance, code quality and tests, etc.) and since the PO "owns" it all it is their decision/opinion what counts, i.e. they pretend to be tech-leads.
I even work with a PO who insists of writing all the engineering tickets (title/description), where no engineer can understand what the ticket is about since this person simply doesn't have the ability to clearly and concisely articulate engineering tasks.
Now, obviously people will point out that this is not a problem with Scrum but a culture issue with the organisation, and I agree (my organisation has many ingrained and deeply embedded institutional dysfunctions) but the Scrum definitions aren't helping engineering teams.