Many things can fail when we work with teams. But one critical anti-pattern that leads to problems is the lack of a good Product Owner. In this episode, we explore what are the consequences for our teams of having a Product Owner that is unable to filter input from many stakeholders or even to politely say “No!”. Listen in to learn about the many anti-patterns that can come from a poor Product Owner.
Featured Book of the Week: any book by Gerry Weinberg
What happens when the Product Owner and the team can’t collaborate? When the team just takes orders from the Product Owner and stops contributing to the planning and content of the User Stories? This was the situation that Peter had to face. Listen in to learn how he tackled this relationship problem.
Featured Book of the Week: Search Inside Yourself by Chade-Meng Tan
In this book, Peter found an approach that helps him as a Scrum Master. In Search Inside Yourself, Chade-Meng tries to offers a method for enhancing mindfulness and emotional intelligence in life and work.
About Peter Zylka
Peter is a freelancing Scrum Master who really loves what he does.
Peter is passionate about Agility and loves supporting teams and organizations on their way into the agile world. As a Scrum Master his goal is to enable each individual in the team to perform the best possible way and to actually understand what a team really is all about.
He starts every day with the goal to make the people around him better.
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.
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.