Archive

DevOps

Product Owners Suck

Teams doing Scrum “by the book” will have a Product Owner. The Scrum Handbook describes this role thusly:

“The Scrum Product Owner is responsible for maximizing the value of the product resulting from the work of the Development Team. How this is done may vary widely across organizations, Scrum Teams, and individuals.”

It goes on to say:

“The Product Owner is the sole person responsible for managing the Product Backlog.”

i.e. the Single Wringable Neck.

Outwith Scrum “by the book”, many teams, Scrum or otherwise, will find themselves with a Product Owner, almost always, in practice, outside the immediate development team itself.

One characteristic common to every Product Owner role I have ever seen has been “push”. The Product Owner pushes work (features, stories, or whatever the unit of backlog) into the backlog, and thus onto the team. The Product Owner generally dictates the priorities of the work items in the backlog, too.

Here’s where the dysfunctions creep in. If we accept that we’d like to encourage intrinsic motivation in the team, and that Dan Pink’s three factors of intrinsic motivation apply (Autonomy, Mastery, and Purpose), then we begin to see how the typical Product Owner stance sucks the motivation away from the team by undermining their autonomy (they’re expected to do what’s pushed on them, with the priorities dictated), their mastery (focus is on delivery not learning), and purpose (the purpose is that of the PO, often opaque or little shared, not a shared common purpose across everyone involved).

Go Pull

I’ve seen clients where this push-oriented Product Owner role has served no one well. Not the Product Owner, nor the development team, nor the product, nor the customers. The Product Owner is worn to a frazzle trying to herd the developers, like cats, towards the outcomes he or she thinks the customers want. It’s most unlikely the Product Owner will know what features are valuable, and how they should work, before stuff gets in front of the customers anyway, and the delays in the “push” model just exacerbate this dysfunction.

Further, in the push model, developers have little opportunity to experiment and innovate. They’re often far better placed than the Product Owner or even the customers to spot opportunities for breakthrough innovations, both large and small, yet the push model basically precludes them from contributing in this way.

So why not turn it around? In my career, I’ve seen all the best products come from development teams that directly own the product. And, consequently, directly own the relationship with the customer. Often, not the whole team, as this might irk the customers – at Familiar we had one member of the development team act as “customer liaison” – a role which could rotate between team members if it started to become a chore for the person in question.

It’s unlikely the Product Owner will wish to do themselves out of a job, so how can we arrange things such that everyone has a better time than with the “push” model? And so we make even better use of the most valuable things the Product Owner has – product domain expertise and customer nous?

In the service (call centre, etc.) sector, Vanguard introduced the idea of front-line call staff taking all the calls, with limited (brief) training to handle the most common types of call, and with experts and specialists on hand to help them through handling the less common types of call as they arrive.

Transferring this idea to the Product Owner role, why not have the development team own the product, take all the decisions about features, stories and priorities – by pulling information from the customers – and whenever the development team has some questions they can’t answer themselves or in conjunction with the customers, have the Product Owner (now Product Domain Specialist or some such renamed role) on hand to pitch in and provide the missing knowledge or expertise.

I guess the Analytic minded organisations out there will feel uneasy about no longer having their hands around the Single Wringable Neck, but learning about Team Accountability might go some way to compensate for this?

So, let the teams suck (pull), instead of having the Product Owner push.

– Bob

PS Note that the above suggestion – to hand over core elements of the Product Owner role to the development team – assumes the development team owns the scope for the whole product, not just the software, and can collaborate and coordinate with other people and groups to ensure the whole product is delivered (whether incrementally for not). See also: Obeya.

Further Reading

The Transformation of O2 – A Vanguard Case Study in Reengineering Call Centres (pdf)

The Cold Wet Nose Of Reality

bloodhound

If you’re in the business of supplying IT services, especially software and product development, to your clients, you may be getting uneasy (again). Agile software development, and its close cousin, DevOps, are the latest in a long line of approaches promising to solve the “software crisis”. And like the many approaches that have gone before, their faults are beginning to show, and the chickens are coming home to roost.

As they say:

“…you can’t fool all of the people all of the time.”

I don’t doubt that many solutions providers and consultancies have the best interests of both their clients and their own staff at heart, and are not just focused on their revenues. And just like their antecedents, Agile and DevOps did look promising. But just as with those antecedents, time has shown the core ideas wanting. Or, more accurately, insufficient in the majority of cases.

Why Early Adopters Have Good News

Whatever the approach, its early adopters generally have good stories to tell, about good outcomes. And why not? These folks had the enthusiasm, the curiosity, the drive, and the grasp of the principles to make the approach work. Later adopters, absent some or all of these advantages, have struggled to see useful benefits. No matter what the approach.

That Nose

Truly, the cold wet nose of reality has been sniffing out the latent flaws implicit in Agile and DevOps from the outset.

Smarter Now

I’d like to hope that we’re collectively smarter now. That having seen so many promising approaches come and go, we might be on the verge of seeing beyond the superficial attractions of each new approach. That we may be, finally, developing the deeper lore that will show us why all our approaches to date have sooner or later failed us. I’d like to hope that, But in general, I see precious little evidence of it happening.

“A new type of thinking is essential if mankind is to survive and move toward higher levels.”
~ Albert Einstein

– Bob

<span>%d</span> bloggers like this: