Product owner anti-patterns

Every scrum master must look for anti-patterns in how product owners do their jobs.  In a perfect world, the product owner and the scrum master are like siblings working toward the same goal.  In reality, mismatched business priorities and lack of cooperation by business partners can happen in any organization.  So, this article will help you recognize the smells you should look out for as a scrum master.  I hope a few of you will be kind enough to provide suggestions on dealing with these anti-patterns.  Many of these examples come from Roman Pichler’s excellent book on product ownership.

The Under Powered Product Owner

We have all seen this product owner.  They have the look of an abused animal.  They are not empowered to say “no,” and when they say that they speak for the business, you know what they say is they speak for their boss, who will overrule them when convenient.  The underpowered product owner is a figurehead who is there because the scrum process says so.  The people with the real say will not surrender their authority to let this product owner do the job.  The authoring of user stories consists of being called into the boss’s office to take dictation from the boss.  The boss sets priorities, and if something goes wrong, it is the fault of the development team rather than the boss.  Everything is a priority, so nothing is a priority until something goes wrong, which triggers a spasm of unsustainable development. 

The Overworked Product Owner

According to Certified Scrum Master training, each software project should have a product owner and a scrum master along with a group of developers ranging in size from five to seven people.  Executives look at this as a waste of resources and often assign multiple scrum masters over many development teams and do the same with product owners.  The by-product is the overworked product owner.  Currently, I work with a Product owner whose work is divided among four software development teams.  This forces the Product owner to spend only the minimum time necessary to get stories written and ensure that priorities fit into the sprint. The scrum master or another developer rewrites the stories so they are clear enough to be understood by the other developers.  Stand-up meetings, retrospectives, and demonstrations are missed because the product owner does not consider them critical.  They only turn up when something goes wrong or when upper management is paying attention.  Quality suffers, and the notion of sustainable development is nothing more than a sick joke.

The Absent Product Owner

Sometimes, projects are kicked off, and the executives who demand the work can’t find or won’t hire a product owner.  The software is still expected to be written, but no one can write the user stories.  Software developers and scrum masters should be smart enough to determine what creates user value.  This creates situations where what is constructed is often not what the business wants. Fortunately, the failure process is faster, so the executive can ask questions like “What is wrong with you people?” and “This is a simple business process. Why am I paying you so much money to screw this up?” 

The Product Owner by Committee

Some projects have a great deal of visibility and multiple project teams; this creates the product owner by committee.  These are individuals who are all empowered to write stories in the backlog, and they are also equally empowered to set priorities.  This pulls the development like taffy and forces the scrum master and the development team to juggle priorities with the dexterity of chainsaws.  One mistake creates the loss of a limb and the destruction of a career.  In addition, the horrific aftermath generated meetings outside the scrum process and cut into the team's productivity.  This is why many of us in the agile community discuss scaling large projects: multiple development teams and product owners lead to this situation.

The Rogue Product Owner

This is a product owner who has his interests in mind rather than the needs of the business when creating work for the development team.  You know, when you work for a rouge product owner, your boss comes to you and asks what your team is working on.  This is because the team is making life easy for the product owner. Still, new customers are not being generated because the features to attract those new customers are not prioritized as highly by the product owner.  This undermines the agile process because the only value created is for the product owner instead of the business. 

So there you have it: five different anti-patterns for product owners.  Be on the watch for all of them; otherwise, your life as a scrum master will become very painful.

Until next time.