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.
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!
- Manager: curiously, some Product Owners try to manage the Development Team, which causes a huge problem. The Product Owners assign tasks directly to the team members, tell who does what. Product Owners should not behave as Managers! Instead, they should trust the Development Team. They know how to organize their work.
- New requests: the Product Owner comes to the Daily Scrum, then fires new demands so that the Development Team can take them. The Daily Scrum is not for that. New items need to be refined and then prioritized. When Product Owners give demands during the daily, it shows a lack of direction. Then I ask, how would the team trust such a Product Owner?
- Daily doesn’t start without the Product Owner: if the Development Team doesn’t begin the daily without the Product Owner, probably this event is a status report to the Product Owner. Remember that the daily is for the Development Team, that is when the team gets the alignment they need to keep moving towards the Sprint Goal.
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.
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.
- New features: sometimes the Product Owner has new ideas to share with the Development Team, there is a moment for that; it is called product backlog refinement. If you interrupt the team to talk about all of your ideas, the Development Team will not focus on what matters. Before you interrupt them, ask, “Is this relevant for our Sprint goal?”, if not, wait for the right moment.
- Meetings: the Product Owner attends to many meetings; some relate to future possibilities that may never happen. However, some Product Owner insists on taking team members to such meetings. Therefore, wasting their time. I am not saying that tech members should be far from business, I am saying that Product Owners should understand when to involve them so that they don’t waste time.
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.”
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.”
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!
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.
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.
- The work has no purpose.
- Focus on features instead of value.
- Little or no chance for collaboration.
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.