In his recent blog post Banish “Priority” and “Prioritization” David Anderson (of Kanban fame) argues that prioritization of features by a ProductOwner is a “wasteful” act of “non-value-added” coordination. The ProductOwner role is, in his words, an “old paradigm”. Instead, David suggests to introduce “a set of classes of service” with associated “policies”.
When I first read David’s post, I didn’t understand it. My first reaction was, how can someone so smart write something so silly?
In Scrum it is the job of the ProductOwner to absorb and model the complexity of the environment on behalf of the project stakeholders. Anyone who removes the ProductOwner and replaces the task of prioritization with selection and scheduling using a set of policies commits the fallacy of confusing complexity with complicatedness.
- What if feature A takes precedence now because Sally is the best one to communicate with stakeholder X, and she will go on vacation next week?
- What if feature B should be done a.s.a.p. because the customer accidentally deleted data that can only be recovered with feature B?
- What if feature C must be done instead of feature D because stakeholder Karl is ill, and his input is needed for feature D but not for feature C?
Managing stakeholders in a complex environment is a complex task. It is non-deterministic. Selection of features and replenishment of queues based on “some plan or delivery schedule” (I’m quoting David here) is a complicated task. It is deterministic.
From a complexity thinking point of view it makes no sense to replace a ProductOwner with a set of policies. It takes complexity to deal with complexity, because complexity is irreducible. You cannot simplify the complexity of the environment to a set of rules. You need the complexity of people’s brains to absorb and model the complexity of the environment. A deterministic set of policies associated with classes of services is a very poor approximation of what happens in the real world.
The suggestion that ProductOwners don’t add value, and that they can be replaced with policies, is sending exactly the wrong signal to managers around the world. And it doesn’t matter whether this was intended or not. When I don’t understand the motivation behind this message, then how are more traditional CxO’s going to interpret it? If we can replace the PO with a set of policies, then why not the ScrumMaster and Software Testers too? It is the “machine-thinking fallacy” all over again. No wonder that some old-fashioned managers find the rhetorics of Lean thinkers appealing. It is an old paradigm indeed…
The Real Message
Given my general admiration of David Anderson’s ideas, I realized I could have misunderstood something about his message. And after a lengthy debate on Twitter (which probably costs us both a few followers) it appeared what David really meant is to capture the boring part of the ProductOwner role in a set of policies. (Only the part that can be modeled with deterministic rules.) He said the interesting part of the PO role (handling exceptions, uncertainty, social complexity, etc.) should be taken up by the team. Or, in David’s blog post:
“Empower the team to make good quality risk decisions.”
Ah, so the requisite variety was there after all! But it was (from my perspective) only one line of value among 40 lines of waste. It was easy to miss.
I still think that (most) teams are not able to take on the complex part of the PO role. But at least this suggestion is one I can understand…
p.s. You may notice I tried to write this post in a similar fashion. Most of it is crap about misunderstandings. The real value is in just one line. :-)