We often work within environments where the “vanilla” Agile approaches are insufficient. In this episode we explore what happens when more traditional organizations are adopting Agile. We talk about the role of the Product Owner in traditional organizations and the critical role that the Scrum Master plays in supporting the Product Owner.
In this episode we discuss the importance of Pilot projects in traditional organizations and what we can do to make sure they succeed.
About Darryl Sherborne
Darryl is an IT professional specialising in Kaizen (continuous improvement), Agile delivery and coaching, Lean Thinking implementations and more recently applications of DevOps and Data Science. Darryl can also be found singing in rock/pop choirs, and watching or reading anything in the realm of Sci-Fi / Marvel.
As an unlikely Scrum Master Jem went through a journey of adapting to a new industry, and a new role. In his eagerness to bring value to the organization and teams he worked with he focused on taking on more responsibility. But is that a good idea? What happens when the Scrum Master also takes the Product Owner role? Listen in as we discuss the anti-pattern of the Scrum Master that is also the Product Owner.
About Jem D’jelal
Jem trained to be a social worker, but ended up dropping out & joining the dark side instead : investment banking 🙂 In a funny way, Jem was led back to his passion – helping people. This happened when he was introduced to Scrum in 2006, and has been a career Scrum Master since. He calls himself “nomadic”, having had almost 30 roles in 10 + years. He does say that he will be searching for a home at some point. Some of Jem’s other passions involve running, a part time mentoring charity for repeating youth offenders in North London & callisthenics.
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…
The Product Owner (PO) is a tough role to fill. Product Owners are torn between users, senior management, team and other stakeholders that they need to attend to.
While the team is working on completing the backlog items, the PO is probably meeting with the Director of Product to agree on a roadmap; with the CEO to hear about the latest ideas he got from visiting a client; trying to meet with the user research group to understand better the customer; reporting status to the head of Project Management; and still needs to visit the Sprint Planning, Backlog Grooming, Demo and the occasional daily meeting to answer questions from the team. And let’s not forget the email backlog! With all of these tasks one has to ask: do we believe a single person can do this all alone? What I describe here is not even rare! We seem to collectively think that the Product Owner is a super-hero!
Given all of these tasks, it is little wonder that the PO’s end up struggling to even manage the JIRA tickets the teams ask them to review, give feedback on, and prioritize.
EXTRA BONUS: to get 30% off Barry’s Hypothesis-Driven Development course you can go to www.leanagile.study and use discount code THIRTYCPOFF before the end of December 2017.
Far too many companies act as if Product Development was a shopping trip: they get a list of things to “buy”, typically Features. Then they create documents explaining that shopping list: Roadmaps, Backlogs, PowerPoint presentations, Post-its on walls, you name it. And then they execute. Here’s the thing: if you act as if Product Development is a shopping trip all you will do is spend a lot of money and get lots of Features you don’t really need.
Barry suggests we treat Product Development differently. He calls it Hypothesis-Driven Development (HDD for short) and includes:
Leadership set an outcome (not a task!) Example: how to increase conversion by 10%
Look for observations: where you try to understand what is happening in the product and to the product you develop.
Set a hypothesis to validate ideas: where you make assumptions and write those down as assumptions. Assumptions should be about how to reach the goal set in step 1.
Create simple experiments: actions that drive results, which you will compare with the hypothesis you created in 3.
Gather the data, learn and repeat: the core process is LEARNING. Therefore, spend enough time on this step so that you generate new observations, insights. Then repeat the cycle.
A fundamental shift in product development
Barry claims that HDD is a fundamental shift in product development. The shift is from doing many things, many small changes, and switches to focusing on outcomes, on results to the business. This means that leadership is no longer accountable for the work, but for the outcomes. And this frees the teams to focus on self-organizing to reach those outcomes, instead of following a list of things that others have dictated.
As a result of the shift towards HDD, we stop focusing on big-bang, all-in projects and focus on running smaller experiments that drive the learning that will eventually generate the outcomes we defined. As Barry says in this episode: we go from 1 to 2 experiments per year (projects) to testing many more ideas every month.
But you can’t run that many experiments with the same approach to funding, and management that you used when you ran projects. So we focus on a different management paradigm that Barry explains further. The goal: learn and adapt faster, not produce more features.
As part of that, we need to get familiar with the concept of safe-to-fail experiments that can reliably generate knowledge without causing chaos or confusion in our product development process.
And it all starts with a simple change in product development: define the problem you are trying to fix, not the solution you are trying to create.
If I want to know more about the Hypothesis-Driven Development approach, where should I start?
Barry O’Reilly is a business advisor, entrepreneur, and author who has pioneered the intersection of business model innovation, product development, organizational design, and culture transformation.
Barry works with business leaders and teams from global organizations that seek to invent the future, not fear it. Every day, Barry works with many of the world’s leading companies to break the vicious cycles that spiral businesses toward death by enabling experimentation and learning to unlock the insights required for better decision making and higher performance and results.
Before reading the post, I wanted to share with you a great interview about how we, as Scrum Masters are always starting from Scratch (just like new year! 🙂 Here’s a Podcast episode as a new year gift from the Scrum Master Toolbox Podcast archive built over the last 3 years interviewing Scrum Masters from all over the world.
Podcast Topic: We start a new with every team (interview with Lucian Stroie)
Now for the list! 🙂
Here in the Scrum Master Toolbox Podcast, we share insights and inspiring stories from Scrum Masters every day of the week because we believe we need inspiration and ideas every day. Therefore we also visit sites and blogs for the same reasons. To end the year with a bang, I wanted to create a list of Top blogs / Sites for Scrum Masters. Was I in for a disappointment… read on to know why…
Product Owners have an impossible job! I know, I’ve been a Product Owner. And even worse, a Product Manager transitioning to Product Owner! And even worse! I was also the Project Manager. Geeez! When I look back I am amazed I survived that phase of my career.
Here’s the kicker, that was the best time of my Agile adoption journey. I got to see my ideas come to life so quickly! And have a concrete business impact (the product we delivered went on to generate 10 Million Eur in sales a little over 3 years).
My Product Owner journey towards Agile was not easy! Let me tell you how I survived that stressful time, and lived on to learn a lot from the experience.