product owner Archives - Page 2 of 107 - Scrum Master Toolbox Podcast

Sheik Meeajaun: When Spillover Becomes Normal, Scrum Teams Stop Seeing the Cost

“A good Scrum Master makes their Product Owner look like a superstar.” – Sheik Meeajaun

Sheik describes a team pattern many Scrum Masters recognize: spillover had become so normal that finishing the sprint felt like a special event. Refinement was weak, stories were often written during refinement instead of before it, and Product Backlog Items were sometimes little more than one-line titles. The Product Owner was not consistently engaged, standups had become update sessions for the PO, and nobody was connecting non-delivery to business impact. Sheik brought his Product Owner background into the Scrum Master role and started asking a more pragmatic question: what is the cost per sprint when we do not deliver? By making cost of delay visible, he helped the team see that spillover was not just a process issue. It was lost value. The experiments were practical: protect focus, prepare stories before refinement, and tackle the gaps at ground level instead of pretending the organization would fix everything first.

Self-reflection Question: What does your team treat as normal today that is quietly costing the product money every sprint?

Featured Book of the Week: The Scrum Guide by Ken Schwaber and Jeff Sutherland

Sheik does not pretend to have a long reading list. He says experience shaped him more than any single book, because contracting exposed him to many organizations and many versions of Scrum in practice. Still, he points listeners back to The Scrum Guide as the minimum reference every Scrum Master should know.

For Sheik, the guide gives the vocabulary and foundation, but experience teaches the translation work: how those ideas survive contact with real teams, weak refinement, Product Owners who are stretched thin, and organizations that say “Agile” while still behaving like escalation machines.

Transform Your Agile Teams with Hard-Earned Lessons from Super-Experienced Scrum Masters

Do you wish you had decades of experience? Learn from the Best Scrum Masters In The World, Today! The Tips from the Trenches – Scrum Master edition audiobook includes hours of audio interviews with SM’s that have decades of experience: from Mike Cohn to Linda Rising, Christopher Avery, and many more. Super-experienced Scrum Masters share their hard-earned lessons with you. Learn those today, make your teams awesome!

About Sheik Meeajaun

Sheik is a seasoned product and Agile leader with over 20 years of experience scaling innovative, customer-centric digital solutions. A certified Scrum and Agile expert, he bridges strategy and execution, driving high-performance teams at enterprises like Rabobank and citizenM. As a hands-on builder, Sheik created Scrumling—a free, interactive Agile training platform—and ScrumJobs.net, a niche job board for Agile professionals. His passion lies in transforming theory into impactful, real-world results.

You can link with Sheik Meeajaun on LinkedIn.

You can also explore Scrumling, ScrumJobs.net, and Simatech.

BONUS: Why Software Projects Fail When Everyone Keeps Quiet

Software projects rarely fail because no one noticed the problem. More often, people see the missing database, the wrong assumptions, the broken process, or the weak product ownership, but the organization has trained them to stay quiet. In this BONUS episode, Mark Stringer, author of Delivering the Impossible, helps us understand how Scrum Masters can make reality visible again.

The Problem Of Intention In Software Projects

“You’ve got here a problem of intention, and you can’t fix that by coming up with new, more magical marks on the page.”

Mark starts with a story from the mid-1990s, before Agile was a common word in software teams. In a software development course, he heard the familiar promise: if only requirements could be captured with the right notation, the project would go correctly. His reaction was different. Software is not only a problem of documentation or process, it is a problem of translating intent into reality. That gap between marks on a page and what people actually need is where many projects begin to drift.

Point Of View Can Make Smart People Miss Reality

“If we see things in the wrong way, then point of view can take 80 IQ points off us.”

Mark uses Alan Kay’s idea that point of view is worth 80 IQ points to explain why good people can still make poor project decisions. A methodology can help, but only if it helps the team see what is actually happening. When the model becomes more important than reality, teams start defending the plan instead of learning from the system they are trying to change. Scrum Masters can help by asking what the current point of view hides, not only what it explains.

The Swamp: Why Project Complexity Is Not On The Diagram

“The fastest way between two points in a real organization is not necessarily a straight line.”

In one banking project, Mark found two realities that had not survived the diagrams. First, a transaction database shown on every architecture diagram did not exist. Second, after six months of requirements work and several million pounds spent, a simple show and tell revealed that the design was organized around accounts when stakeholders needed it organized around people. The point was not that the team had failed to write enough requirements. The point was that the real environment was a swamp of legacy systems, power shifts, competing groups, regulations, users, and assumptions. You only discover that swamp by starting, showing real work, and letting stakeholders react.

Agreed Activity: When The Rituals Keep Going But The Project Is Already Lost

“Everybody knows why the project’s failing. It’s not a mystery at all.”

Mark calls one common failure mode “agreed activity.” The team keeps attending standups, planning meetings, status reviews, and retrospectives, even when people privately know the project is not going anywhere. Often they have tried to raise the real issue before and were punished for it. After that, silence becomes rational. The organization keeps reporting activity, expenditure, and compliance with the process, while the real blockers stay untouched. For Scrum Masters, this is a warning: ceremonies are useful only when they let reality enter the conversation.

Product Ownership, Bad News, And The Message Leaders Send

“The message that the development team hears is: don’t rock the boat, just keep taking the money.”

The Product Owner role can help break agreed activity, but only if the person has enough authority to make decisions and enough proximity to the team to learn. Mark describes two common anti-patterns: appointing someone junior who can be pushed around, or appointing someone so senior they have no time for the work. Worse, when someone points out a fundamental problem and gets metaphorically shot, the team learns the real rule: stay quiet. Leaders may think they are asking for positivity or commitment, but the team hears permission to cut corners, hide bad news, and treat spending as progress.

Make Scrum A Hypothesis Testing Framework Again

“That kind of unexpected feedback, that’s the hope. That’s the machine working.”

Mark’s practical advice is to keep the cadence, but make the meetings real. A show and tell should expose assumptions. A retrospective should make uncomfortable feedback usable. Scrum works best when it is treated as an empirical, hypothesis-testing framework, not a list of meetings to implement. Mark also points to user research as a way to extend learning back into the environment. Teams cannot guess how users will react, which buttons they will press, what they will ignore, or what market and organizational changes are shaping the work. They have to test, learn, and adjust.

About Mark Stringer

Mark Stringer is the author of Delivering the Impossible, a 2026 Apress book on better ways of seeing software project management. He has spent 30 years in software delivery as a developer, application researcher, and project manager, working with IBM, Xerox, and Cambridge University.

You can link with Mark Stringer on LinkedIn and follow Mark’s writing at markstringer.github.io. You can find Delivering the Impossible on Amazon and Springer.

5th September 2026 at 10:05 CET
BONUS Why Software Projects Fail When Everyone Keeps Quiet With Mark Stringer

Arun Parameswaran: Product Owners Who Create Better Product Conversations in Scrum

In this episode, we refer to Arun’s AI prompt library for Scrum Masters and project managers.

The Great Product Owner: Curiosity, Clear Direction, and Outcome Focus

“A great PO doesn’t only ask, did we deliver? They ask, do people communicate openly?” – Arun Parameswaran

Arun describes great Product Owners as collaborative, curious, and close enough to the team to understand how delivery really works. The best POs he worked with did more than check whether items were delivered. They asked whether knowledge was distributed, whether people communicated openly, and whether everyone had a chance to contribute.

They gave the team clear product direction, supported prioritization, managed stakeholders, and stayed available when the team needed context. Arun emphasizes outcome focus: value for the customer expressed in a way the team can understand. A strong PO becomes the bridge in both directions, helping stakeholders understand the team and helping the team understand the customer.

Self-reflection Question: Does your Product Owner help the team understand customer value, or only the next ticket?

The Bad Product Owner: Turning the Team Into a Ticket Factory

“The Scrum Master shouldn’t just help the PO write better tickets. We should help create better product conversations.” – Arun Parameswaran

The anti-pattern Arun warns about is the Product Owner as ticket distributor. Stakeholders ask for something, the PO turns it into a ticket, and the team delivers without understanding the problem, the outcome, or why the work matters. Over time, the team becomes a delivery factory, and Scrum starts to look like waterfall with smaller batches.

Arun’s coaching move is to shift the conversation away from “better tickets” and toward better product thinking. What problem are we solving for customers? What outcome do we expect? What should we prioritize? What can we say no to? For Scrum Masters, this means coaching the PO and the team to bring customer context, stakeholder feedback, and prioritization into the same conversation.

Self-reflection Question: What product conversation is your team avoiding by hiding behind ticket writing?

Transform Your Agile Teams with Hard-Earned Lessons from Super-Experienced Scrum Masters

About Arun Parameswaran

Arun is an Agile delivery leader at Bosch Global Software Technologies who builds high-performing, data-driven ecosystems. He blends flow metrics, Jira analytics, Power BI, and applied AI to turn delivery into a transparent, predictable system.

You can link with Arun Parameswaran on LinkedIn.

You can also explore Arun’s AI prompt library for Scrum Masters and project managers.

Arun Parameswaran: How Powerful Questions Help Scrum Teams Handle Stakeholder Conflict

“Sometimes the best thing a Scrum Master can give the team isn’t the answer. It’s a question.” – Arun Parameswaran

Arun describes a team pattern many Scrum Masters recognize: stakeholders bypassing the Product Owner and going straight to developers with new requests after the sprint had already started. The developers wanted to help, so they accepted the interruptions.

The result was context switching, broken priorities, and a quiet loss of focus. Arun worked with the customer team, Product Owner, and developers to create a simple agreement: new work had to come through the PO, be clarified, and be prioritized before it reached the team. That agreement gave developers permission to protect the sprint without turning every conversation into a personal conflict.

Arun also shares how he handled the classic misunderstanding that “being Agile” means accepting every change immediately. For him, adaptability still needs timing, clarity, and shared agreements.

In this segment, we talk about the coaching stance and how Scrum Masters can use questions to help teams think together.

Self-reflection Question: What agreement would help your team protect focus without shutting stakeholders out?

Featured Book of the Week: Coaching Agile Teams by Lyssa Adkins

Arun recommends Coaching Agile Teams by Lyssa Adkins because it helped him move beyond ceremony facilitation. The book gave him a clearer picture of the Scrum Master as a coach for individuals, the team, and the wider organization. One question stayed with him: am I solving the problem for the team, or helping the team learn to solve it themselves?

That shift changed how Arun worked. Instead of telling teams what to do, he began asking questions such as “What do you think is causing this?”, “What options do we have?”, and “What are we not seeing?” For Arun, the book is a practical reminder that coaching is not about leading people to your answer. It is about helping people think.

Transform Your Agile Teams with Hard-Earned Lessons from Super-Experienced Scrum Masters

About Arun Parameswaran

You can link with Arun Parameswaran on LinkedIn.

Joshua McDonald: Product Owners Earn Team Loyalty By Showing Up, Learning, And Deciding

The Great Product Owner: Vulnerable Enough To Learn The Technical Details

“I’ve seen developers be fiercely loyal to their product owner who makes that type of effort.” – Joshua McDonald

Joshua describes the great Product Owner as someone who connects with the team even without a technical background. They do not pretend to know everything.

Instead, they get into refinement with curiosity, write stories with the developers, and say, “I think this is what needs to be done, but correct me if I’m wrong.” That vulnerability creates a strong partnership. Developers see the effort and often respond with loyalty, to the point where they may refuse to continue important discussions without the Product Owner in the room.

The lesson is useful for Scrum Masters coaching Product Owners: deep technical expertise is not the entry ticket. Presence, curiosity, and the willingness to learn with the team are what create trust.

Self-reflection Question: How does your Product Owner show the team they are willing to learn the product with them?

The Bad Product Owner: The Dependent Note Taker

“Sometimes you ask the product owner, you’re the bus driver, where do you want us to go? And they say, let me go talk with the product manager.” – Joshua McDonald

The Product Owner anti-pattern Joshua highlights is the dependent PO: the person who shows up as a note taker rather than a decision maker. This often happens when a Product Manager sits behind the PO and every decision has to be checked elsewhere.

The day-to-day symptoms are easy to spot: camera off, muted, disconnected, asking people to repeat questions, missing meetings they scheduled themselves, and leaving the team without timely answers. Joshua’s coaching response starts with one-on-ones, support, and curiosity.

He asks how they are doing, what support they need, and what signals would help the team see they are engaged. When the product feels too technical, he sits beside them, learns with them, and helps them build confidence instead of leaving them exposed.

Self-reflection Question: Where is your Product Owner dependent on someone else for decisions, and how is that affecting the team?

Transform Your Agile Teams with Hard-Earned Lessons from Super-Experienced Scrum Masters

About Joshua McDonald

Joshua is endlessly curious about better ways of working. He helps teams grow by blending experimentation, creativity, and AI with practical coaching. When a meeting feels routine, he’s already testing a new approach to make it more valuable. Energetic and inventive, he turns everyday collaboration into opportunities for team growth.

You can link with Joshua McDonald on LinkedIn.