October 24, 2020

Agilists

News for Agilists

How harmful can Product Owners be to the daily business?


Every day the Development Team meets for no more than fifteen minutes. They stand up in front of the board and have the Daily Scrum. Despite lasting only a short time, it’s hard to believe the magnitude of the damage a Product Owner can cause during this event.

Product Owners love breaking many rules during the Daily Scrum. I wonder how we can be so harmful in so little time.

Let’s start from the beginning. The Daily Scrum is an event for the Development Team, not for the Product Owner. Although the Product Owners can participate, they should be no more than listeners, in case the Development asks for help, then the Product Owner should act.

I put in bold the critical aspects of the Daily Scrum to make it easier to understand.

The Daily Scrum is a 15-minute time-boxed event for the Development Team. The Daily Scrum is held every day of the Sprint. At it, the Development Team plans work for the next 24 hours. This optimizes team collaboration and performance by inspecting the work since the last Daily Scrum and forecasting upcoming Sprint work. The Daily Scrum is held at the same time and place each day to reduce complexity.

Scrum Guide

How the Product Owner kills the Development Team’s motivation? I have come across these common problems:

  • Status Report: some Product Owners think the Daily Scrum is a moment where each developer will give a status of what they are working on. Then the Product Owner pushes the team to achieve the goals. Such attitude is command & control, which has nothing to do with Scrum!

Many more anti-patterns happen during the Daily Scrum, which Stefan Wolpers describes in his article about it. Let’s have a look at some examples.

Planning meeting: The PO hijacks the Daily Scrum to discuss new requirements, to refine user stories, or to have a sort of micro (Sprint) planning meeting.

The talkative PO: The Product Owner actively participate in the Daily Scrum. (POs and Stakeholders are supposed to listen in but not distract the Development Team members during their inspection and adaptation.)

Product Owner: Hey, John! I’ve got an idea, it may not be implemented this quarter, but may during the upcoming quarters. Do you have some time?

John: Sure! What is it about?

Product Owner: I was wondering if we could implement a ChatBot in our Web-site.

This is the moment where John forgets totally about the Sprint Goal and starts researching about ChatBots. Later the Sprint will fail, and the Product Owner may blame the team.

Photo by bruce mars on Unsplash

Product Owners receive many requests from different people, but it doesn’t mean Product Owners should react immediately. Also, Product Owners should not interrupt the Development Team as soon as something emerges. As a reminder, the Development Team commits to the Sprint Goal, so don’t take their focus away.

I’ve faced some typical scenarios where Product Owners love interrupting the Development Team:

  • Bug: sometimes Product Owners treat bugs as a synonym as interruptions. Softwares always present flaws. But, the Product Owner first needs to evaluate the impact, then consider interrupting the Sprint. However, flexibility during Sprint is essential; a great Product Owner should find a sustainable balance, so that the Sprint Goal remains achievable.

Remember one thing; Scrum is about maximizing the work not done, so every waste that we may have, we must remove!

“Simplicity — the art of maximizing the amount
of work not done — is essential.”

Agile Principles

If the Product Owner finds no time for the Development Team, the outcome will be at best, sub-optimal.

A good rule of thumb, the Product Owners, should dedicate around 30% of the time for the Development Team. But sometimes the Product Owner only appears during the some Scrum events (sprint planning, review, and retrospective). The rest of the time, the Product Owner is somewhere else, but not with the team.

Being an absent Product Owner will cause significant damage to the Development Team. It will hold the team back from becoming a high-performing team.

“Individuals and Interactions over processes and tools.”

Agile Manifesto

Once we wear the hat of a Product Owner, we should communicate with the team daily, the best way of doing that is face to face, if your team is remote, then a video call. But not through e-mails, comments on Jira, or other electronic formats. The interactions are what matter the most.

In short, the Development Team needs the Product Owner so that they don’t get blocked with doubts and misunderstandings. Great Product Owners are never too busy for the team, because they are part of the team!

The PO is too busy to help the team, so they need the team to help them!

— Vasco Duarte, The (surprising) 9 most common challenges that Product Owners face, and affect their Scrum Teams

Collecting orders from stakeholders and giving them to the Development Team is not a Product Owner. I would say it is like a waiter who gets orders from the clients and sends them to the kitchen.

Photo by Daniel Bradley on Unsplash

Pleasing everyone is a misunderstood instance of a Product Owner. It is known as the Clerk by Robbin Schuurman.

The Clerk is your personal waiter for all your user story serving. Gathering all the wishes, user stories and demands is what The Clerk does. (S)he isn’t focussed on achieving the product vision, nor on crafting clear goals and objectives and the Clerk most certainly never says ‘no’ to stakeholders. There’s nothing wrong with servant leading your customers and stakeholders as a Product Owner, but if your main purpose during the day is getting new ‘orders’ from stakeholders… then you’re missing the point of being a great Product Owner.

Once Product Owners don’t evaluate how the request delivers value, we fail to maximize the business value. Therefore, the backlog becomes a huge wish bucket leading nowhere. This scenario can be called as Christmas wishlist anti-pattern. Such a situation is demotivating for the Development Team, because:

  • The direction is unclear or nonexistent.

If Product Owners are saying “yes” to everyone, they are very far from being a filling the Product Owner role. Once Product Owners have no plan for the product, they will become the plan of someone else.



Source link