This week we start a new Friday question. We explore examples of Product Owner anti-patterns as well as great product owner practices and examples.
Kristopher shares a story of how a Product Owner’s personality can derail a team, and sometimes, even an organization.
We end the week by talking about examples of practices that a good Product Owner can have, and how to help the Product Owner take on those practices.
Are you having trouble helping the team working well with their Product Owner? We’ve put together a course to help you work on the collaboration team-product owner. You can find it at: bit.ly/coachyourpo. 18 modules, 8+ hours of modules with tools and techniques that you can use to help teams and PO’s collaborate.
About Kristopher Stice-Hall
Is the co-owner of Digital Maelstrom, a consultancy specializing in custom software, DevOps, managed cloud services, and information security. He has been doing Scrum Master work for over 10 years. He has worked with fortune 500 companies to companies less than 15 people. He also has been doing software development for 17 years.
After running a survey of product developers, I collected the following 3 top challenges that product developers face in their work.
Unclear specifications with missing information like acceptance criteria, and that require large amounts of rework after we start developing a particular functionality
Finding out critical use cases too late (via bugs, real-user feedback, etc), which leads to long delays in the project.
We don’t have a clear and measurable definition of value, therefore it is always a fight of opinions where the HIPPO (highest paid person’s opinion) prevails most of the times – even when it goes against survey results.
A toolbox to solve these problems
Given these 3 main findings, it is easy to understand why delivering on time is hard for many teams. No matter how much goes into planning and estimating, when the agreement on value is missing, and the specifications of what to do are too fuzzy, we will inevitably find big gaps that lead to massive scope creep and delays.
But it does not need to be like these. There are simple tools I collected in my product developer’s toolbox (#PDevTOOLBOX) that can help alleviate or remove these problems. Based on your input through the #PDevTOOLBOX survey, I’ve created a booklet (15 min read) you can download and read while on the run in your mobile phone or tablet.
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.
There are many learnings we collect along our journey as Scrum Masters. However, transformative lessons are not that common, except for Jeff in this particular job. Listen how he learned 2 lessons that totally changed how he looks at his job as a Scrum Master.
About Jeff Campbell
Jeff is an Agile Coach who considers the discovery of Agile and Lean to be one of the most defining moments of his life, and considers helping others to improve their working life not to simply be a job, but a social responsibility. As an Agile Coach, he has worked with driving Agile transformations in organisations both small and large. He is one of the founding members of www.scrumbeers.com and an organiser of www.brewingagile.org in his spare time. He is also the author of an open source book called Actionable Agile Tools, where he explains how he uses 15 of the tools he uses in his daily work as a scrum master and agile coach.
You can link with Jeff Campbell on LinkedIn, and connect with Jeff Campbell on Twitter.