Interesting analogy but I’m not convinced it’s the best one. One might also note that in many large scale restaurants, there is in fact only a handful of chefs who determine the menu and most of the day to day is handled by cooks assigned to various specialized stations.
> One might also note that in many large scale restaurants, there is in fact only a handful of chefs who determine the menu and most of the day to day is handled by cooks assigned to various specialized stations
But those handful of chefs, are indeed, actually cooks, not? Not some person who read a book on cooking and is now telling cooks how to cook...
In my experience many software teams work exactly in this way, even if many do not. There is often one lead that drives a lot of the architectural decisions and champions things like code quality and best practices.
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.
That's for people outside the Scrum team, meaning that no external stakeholder may manipulate the backlog by bypassing the POs.
Internally the team must act as a cohesive unit, which means that a Scrum dev should have the same objectives as a PO, with regards to both priorities and goals. That may mean adding items in the backlog pertaining to technical debt, and so forth
As much as this comes across as an obvious strawman, it is also consistent with Scrum in practice. Scrum proponents constantly suffer from the "no true Scotsman" fallacy exactly because in practice Scrum inevitably resembles it's own strawman.
Yet another dig at Scrum and Agile that, in their very premise, are talking about something that is [at least supposed to be] anti-Agile and anti-Scrum.
Agile was a small manifesto that listed a set of principles, one of which was "people over processes." If the relationship between your PO and the rest of the team is not collaborative, that's not because Scrum has some dogmatic prescription somewhere in the Scrum bible that declares "though shalt grovel at the feet of your PO and accept their every command without question or suggestion"
If that's how your PO and team behaves, it's because that's how your organization set things up.
Ironically, the relationship described in the article describes "waterfall"; the very boogeyman that Scrum and Agile were a response to.
The role of PO is really just to have a final decision maker as far as how product development gets prioritized and represents THE person to ask when there are unclear product requirements. I mean, at the end of the day when you're trying to ship something, you can't always get everyone sitting down at a table to hash out how the product ought to behave, or whether or not a particular defect is severe enough to block the release.
Also as far as backlog prioritization and delegation goes, you could just as easily target the Scrum Master with the same complaints if your team has one. Although sometimes the PO and SM hats are worn by the same person ... I've seen that at a lot of companies.
I wonder if the article's author would take issue with the concept of a lead developer who has final say on what technical solutions get adopted when there are alternatives (including things like code conventions, 3rd party libraries etc.) because certain lead developers might not collaborate in the way that he thinks all should.
> I wonder if the article's author would take issue with the concept of a lead developer who has final say on what technical solutions get adopted when there are alternatives ...
Pretty much every solution has alternatives and in the same manner that a PO would have final say over the product, a tech-lead would have final say over implementation. However, there is no concept of a tech-lead in scrum so what happens in most cases, the PO becomes the tech-lead. A recipe for a true dictatorship.
As I see it, whoever has the "final say" has to take the final responsibility. There is then no room for blaming anyone else. Discord arises if the developer gets criticized for the outcomes of decisions made by someone else.
reply