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.
It’s hard enough to deliver a small increment of a product, yet we often find ourselves and our teams in positions where they need to deliver a whole product, project or release in 1 go. No change for mistake. And you know what happens: when failure is not an option, failure is the only option!
About Ruben Betancourt
Ruben Betancourt is a computer systems engineer with experience in project management. Currently in love with agile software development methodologies.
You can link with Ruben Betancourt on LinkedIn and connect with Ruben Betancourt on Twitter.
We’ve often heard that teams should be long lived and stable. But what if the advantages or reteaming would be much larger than the disadvantages of changing team composition? In this episode we explore the topic of Reteaming and what Heidi has been developing and discovering that helps teams thrive when they change.
About Heidi Helfand
Heidi’s been in the software industry for 17 years and has a masters in teaching English. She has been a part of two successful startups. She was on the initial team that invented gotomeeting and gotowebinar at the first startup. She is currently Principal Agile Coach at AppFolio, Inc. where they create software for property management companies and law firms. She started there in 2007 hired as a Scrum Master – trained by Ken Schwaber and with Pivotal Labs for more than a year. She became a co-active coach along the way and is certified by the International Coach Federation and the Coaches Training Institute. She is currently writing and speaking about Reteaming – that is, how its valid and desirable to have changing teams as opposed to long running, unchanging teams.
You can link with Heidi Helfand on Linkedin, or connect with Heidi Helfand on Twitter.
You can also follow Heidi’s blog at: http://www.heidihelfand.com/writing/.
Retrospectives are one of the key ceremonies for teams. Well prepared and executed retrospectives can take a team from ordinary to extraordinary and can help teams avoid the anti-patterns that so often lead to difficult problems down the line.
One of the resources that Jiri uses when preparing his retrospectives is Getting Value out of Agile Retrospectives.
The Product Owner role can enable to make the work of the team very difficult. In this episode Jiri talks about how important the Product Owner role really is and how to help teams align. We also talk about aligning remote teams discussing some of the techniques that Jiri uses to have remote teams collaborate effectively.
Scrum has a foundational story that many of us know. The Pig and the Chicken story. Through that story we learn that in Scrum there are “insiders” (the Pigs, who are committed), and outsiders (the Chickens, who are merely involved). The role of the Product Owner is often looked at as a “chicken”, however Angel relates a different perspective. He talks about the critical role of the Product Owner in a Scrum team as well as the approach he used to bring the Product Owner role back into the team.
About Angel Diaz-Maroto
Angel is a seasoned and very energetic Agile coach and a frequent speaker at international conferences and Agile events in Europe and America. He is Certified Scrum Coach. Currently he is member of Agilar, one of the leading Agile coaching firms in Europe and Latin-America.
He is now at Agilar, but before he was the leader at one of the biggest Agile transformations in europe, including business and IT at the Spanish branch of a multinational bank (ING). He lead the transformation from the trenches and starting from scratch. He as more than 15 years of experience in many different roles and is a professor at ESNE (University School of design, innovation & technology).
You can link up with Angel Diaz-Maroto on LinkedIn and connect with Angel Diaz-Maroto on Twitter.
There are many pressures on the development teams, especially when the business has clear needs, and short term deadlines. Niko explains how they were able to achieve sustainable pace despite all the pressures to deliver more.