As part of our upcoming “Coach Your Product Owner” course, we’ve been hard at work creating simple and actionable tools you can use to help your Product Owner progress. But that coaching cannot happen unless we tackle the biggest problems we have when coaching Product Owners. So, last week I asked people who receive my Newsletter to help me answer this question:
When it comes to Coaching and Supporting your Product Owner(s), what is the single Biggest Challenge that you are facing right now?
The reason for this question is my belief that, as Scrum Masters and Agile Coaches, we must help the Product Owners as part of our duties. Sometimes those duties may be just about helping them manage/facilitate a particular session, but often we need to help the Product Owner grow their skills, knowledge, and experience with Agile product development. All aspects of it.
So what are the key challenges we face, when coaching and supporting our Product Owners?
Would you want to have a simple, collected, set of solutions (techniques and strategies) to solve the most common challenges Product Owners face? So would I! But before we can collect the solutions, we must understand the problem!
All of us working with Agile and Scrum are used to the (sometimes) large transformations that these approaches can have at work. But it is not everyday we see the impact, the amazing impact, it can have on other types of work. How about this: Marcus Hammarberg, walks into a hospital and the hospital is about the crumble. Literally! The roof has collapsed, there’s dripping water and buckets everywhere and the second floor is overrun with debris. But that is not where the problems end…
A few months later, and using Kanban, Agile and Lean ideas the hospital is saved. But how did that happen?
Marcus explains his story, and the amazing transformation in his latest book: The Bungsu (now available for pre-order at Amazon), and we have a short video to explain the main points of the story right here.
Click on to see the video, and sign-up to get the first chapter of the book.
This is a question that every Scrum team should know the answer to. Not knowing the answer means more meetings, more disagreements, more conflicts, and ultimately the wrong work gets done first. But this does not happen because anyone is doing something wrong! It happens because there’s no common, agreed and clear way to decide what is the most important work. How to solve this problem?
Work life is a serious thing. We spend (at least) one-third of our time awake at work, and in some cases much more time than what we spend with our families most days of the year.
Now imagine what would happen if your work would be falling apart. You have too much work, and are being constanly interrupted. Your authority and ability to contribute is undermined. And on top of it your place of work is literally crumbling: the roof collapsed and what is left is being innudated by dirty water that runs off from the roof’s debri.
Meet Ibu Elsye! Ibu Elsye is the lady dressed in black in the picture or “Mrs.” Elsye if you don’t speak Indonesian ;).
She’s General Manager of a hospital, Rumah Sakit Bungsu (aka The Bungsu), that Marcus Hammarberg helped, in Indonesia. General Manager; what is that, in a hospital? I’m happy you asked: basically she’s in charge of everything that is not health care. Food, laundry, maintenance, security staff, drivers … you name it.
In The Bungsu, if you need something fixed – go to Ibu Elsye.
But Ibu Elsye’s work life was not going very well…
When Marcus Hammaberg first started to work with the Bungsu hospital they were in a devastating situation. Their finances were on a bottom low after years of decline of patients visiting, their operational permit had not been renewed and they were operating on a probation, the staff was disengaged and blasé … oh, that’s right – the roof of the entire second floor had collapsed.
When a product grows and becomes a success, so will the demands on the Product Owner.
There will be more stakeholders interested in the product, which leads to more meetings. The number of teams developing the product will grow, which will increase the number of meetings and daily questions to the Product Owner.
The more successful the product becomes, the harder it is to manage that product with one single Product Owner.
It is no surprise that most successful products seem to be constantly affected by the lack of time on the part of the PO. However, that’s not the only cause for a PO to be pressed for time. In smaller companies that are adding products to their offering, we often need to start working on a new service or product before a new PO can be hired. On top of that, the knowledge that is already in the PO’s head will be hard to transfer to a new PO, so hiring more Product Owners may even be the wrong thing to do.
Read on for more details and the full article download.
Why do we have daily meetings? Why do I need to be involved with the team every day? Why can’t I just give you the requirements document and concentrate on other tasks?
This blog is part of Module 2 of the Coach your Product Onwer v2.0 video course.
The Anti-Patterns When A Product Owner Is New To The Team, The Product And To Scrum
These are just some of the questions that Product Owners that are new to Scrum will ask. But sometimes we need to onboard Product Owners that are new to Scrum, new to the Product and new to the team. That’s not an easy task.
The Product Owner may not have any technical knowledge of the product or the understanding of the business the product supports. When a Product Owner is new to the team, and the collaboration habits have not yet developed. For example, he may be tempted to just go away and write all the User Stories in isolation or with a Business Analyst, and never involve the team. Which later leads to the “tell the team what to do, and disappear” anti-pattern. Continue reading Product Goal-Setting: How Scrum Masters can onboard a new or beginner Product Owner
The overly busy or absent Product Owner is a common anti-pattern in agile organizations.
This can have serious consequences for the teams we work with as Scrum Masters.
Additionally, Product Owners that are spread too thin may not even have time to be in the Scrum meetings because they serve many teams or handle several products, or because they have so many other meetings with C-level, or other stakeholders. Missing critical Scrum meetings (e.g. Sprint Review, Sprint Planning, Grooming) will quickly lead to a de-motivated team, as well as lack of trust and potential conflict between the team and the Product Owner. In my own experience, when the Product Owner starts missing critical Scrum meetings, the team will quickly start asking: “why do we even do these meetings”, which quickly leads to the meetings being dropped.
How do we help our Product Owners overcome these challenges? Read on…