Agile Zone is brought to you in partnership with:

Jurgen Appelo calls himself a creative networker. But sometimes he's a writer, speaker, trainer, entrepreneur, illustrator, manager, blogger, reader, dreamer, leader, freethinker, or… Dutch guy. Since 2008 Jurgen writes a popular blog at www.noop.nl, covering the creative economy, agile management, and personal development. He is the author of the book Management 3.0, which describes the role of the manager in agile organizations. And he wrote the little book How to Change the World, which describes a supermodel for change management. Jurgen is CEO of the business network Happy Melly, and co-founder of the Agile Lean Europe network and the Stoos Network. He is also a speaker who is regularly invited to talk at business seminars and conferences around the world. After studying Software Engineering at the Delft University of Technology, and earning his Master’s degree in 1994, Jurgen Appelo has busied himself starting up and leading a variety of Dutch businesses, always in the position of team leader, manager, or executive. Jurgen has experience in leading a horde of 100 software developers, development managers, project managers, business consultants, service managers, and kangaroos, some of which he hired accidentally. Nowadays he works full-time managing the Happy Melly ecosystem, developing innovative courseware, books, and other types of original content. But sometimes Jurgen puts it all aside to spend time on his ever-growing collection of science fiction and fantasy literature, which he stacks in a self-designed book case. It is 4 meters high. Jurgen lives in Rotterdam (The Netherlands) -- and in Brussels (Belgium) -- with his partner Raoul. He has two kids, and an imaginary hamster called George. Jurgen has posted 145 posts at DZone. You can read more from them at their website. View Full User Profile

Wasteful Product Owners?

04.12.2011
| 1049 views |
  • submit to reddit

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?

Complex Environments

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?

Social Complexity

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. :-)

References
Published at DZone with permission of its author, Jurgen Appelo. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Tags:

Comments

Mark Anthony replied on Fri, 2012/04/13 - 9:57am

I like your original negative instinct. Policies should always be suspect.

But what if the proposed solution were not policies, but values? Values which are constantly discussed and hashed over in specific applications, such that an organization can have a very good expectation that disparate people would arrive at similar treatments of a given situation, without the need for policies and procedures.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.