Failing as a Product Owner

The Product Owner

Many organisations utilise a proxy Product Owner, often to augment lack of resource within the organisation. In come the help, (usually Management Consultants) and off we go. Life is good right? Often this doesn’t work though – usually because there is just so much more to each of these roles – companies fail time and time again to realise this.

Why do companies use proxy PO’s?

Scrum is massively disruptive to traditional top-down management in organisations. Primarily because Scrum favours self-organisation, companies try and squeeze everyone into a role to keep them happy so you’ll often see;

Project Managers becoming Change/Release managers or Scrum masters
BA’s turned into Product Owners
Product Owner role becoming politically managerial

The list is endless….

Who is the Product Owner?

Scrum is as purposefully vague as you’d expect,

‘ How this is done may vary widely across organisations, Scrum Teams and individuals’

– Scrum Guide 2017

The Product owner must be empowered and capable of driving real decisions. Defining the product strategy, its implementation and understanding how to maximise value. The business must respect this true PO role. This person should ideally also be managing the backlog and attending the Scrum events but that is a massive load on anyone so it’s important it’s the right person, and anyway, trying to get two people to do it rarely works. This is often an anti-pattern for me. Because then the Product Owner role is diluted.

You see, the proxy PO often doesn’t have the last say on the product backlog whatsoever. This heavily conflicts with the Scrum Guide.

‘ For the Product Owner to succeed, the entire organization must respect his or her decisions’

– Scrum Guide 2017

Further issues come about when the real PO doesn’t or cannot interact with the Scrum Team and maybe doesn’t attend the Sprint reviews. If they do, are they equipped with enough knowledge to be effective? If not, this is often a recipe for disaster and causes massive misalignment.

Ultimately

Without question, the Product Owner is the most important (in my mind) person in the Scrum team. Your PO should have full vision awareness, strategy, budget decision making capability along with full visibility across the backlog. PO’s who don’t have this control will often, fail in the role and fail the product.

Anti-Patterns

So, when you have a proxied PO set up on your project the additional kicker is this often creates anti-patterns. Anti-patterns (when an Agile way of working doesn’t improve things, it makes it worse) often manifest and include things like;

Anti-Pattern	Things to consider
No single product owner	Ensure the one capable person is empowered appropriately, if not Scrum may not work
Inaccessible product owner	Ensure the PO is not also doing a ‘day job’ and time is being spent elsewhere on other things
Proxy Product owner	Not using one – a Proxy PO helps cause distrust, and complexity along with delayed decision making
Role confusion	Follow the Scrum guide
Lack of Product focus	If the roles confused as a managerial role, it could attract political appointments and result in sub-optimal performance
Absent governance	Ensure the project is not either swallowed in governance or completely ignored. Find the balance.
Inadequate Product backlog management	The PO SHOULD BE responsible for creating and maintaining the backlog. The PO needs to be across every item, the whole product and ensure work is visible and transparent

So what?

I’m not a fan of shoehorning bits of Scrum into an organisation and following the process loosely. You can do that with over-arching Agile, taking the bits you need and blending them into your way of working, but Scrum is Scrum and the only way to have success in my eyes, is pretty much to follow it to the letter.

Now, the big issue here is organisations who choose to use this way of working for projects which involve both digital and non-digital elements. The non-digital elements of any project, be they slower moving parts or more waterfall time boxed things, don’t suit or need Agile and Scrum and, can be perfectly managed using standard Waterfall project management. The trick is to learn how to meld the two into one coherent project and I’ll demonstrate how I’ve done that before in my next post.

Links & References