Bradley Pohl: Evidence-based Product Ownership

Product Owners that have a command and control mentality can derail the team. We discuss this and other topics on this Product Owner focused episode.

The Product Owner pattern for the week

Product Owners that focus on command and control will quickly become too busy to be able to help the team, but that’s usually made a lot worse when the Product Owner has multiple roles. These are the 2 anti-patterns we talk about in this episode.

The Product Owner anti-pattern for the week

When it comes to good Product Owner patterns, we discuss the need to be open to learning from the team, the market and stakeholders. We also discuss evidence-based product ownership.

In this episode, we refer to The Professional Product Owner by Don McGreal and Ralph Jocham.

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 Bradley Pohl

Bradley is a young Scrum Master working for a mid-sized US bank that is currently undergoing an “Agile Transformation.” As a part of the Transformation, his training consisted of a 4 week Agile boot camp that was designed to build scrum masters from the ground-up. In his free time, he applies lean and agile principles to designing websites and providing social media advertising to local small business as Catch On, at catchontech.com.

You can link with Bradley Pohl on LinkedIn.

Jeremy Willets: The product owner that was the team manager

As usual on the Friday’s episodes, we explore Product Owner patterns and anti-patterns to help you work effectively with the Product Owner.

The Product Owner pattern for the week

This Product Owner was the manager for the team, but despite that, he was an effective PO. Listen in to learn how this PO stepped back to help the team contribute, and how he separated his PO responsibilities from his management responsibilities.

The Product Owner anti-pattern for the week

Product Owner’s personalities can have a big impact on the relationship with the team. In this episode, we explore what happens when the PO is self-centered and egotistical. We discuss the symptoms that indicate this anti-pattern and some of the things you may want to do as a Scrum Master to help the PO and team collaborate.

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 Jeremy Willets

Jeremy Willets is a Technical Writer turned Scrum Master/Agile Coach. He’s passionate about bringing Agile to all facets of his organization. He enjoys spending time with his family, making music, and drinking the finest craft beer the world has to offer!

You can link with Jeremy Willets on LinkedIn and connect with Jeremy Willets on Twitter.

Elena Popretinskaya: Scrum Product Owner anti-pattern and an example of a great PO

In this episode, we continue to ask the Product Owner question: examples of Product Owner anti-patterns, and examples of great Product Owners. We often get asked about what is a good Product Owner, and how to define the role so that success becomes clear. 

Elena’s example of a Product Owner anti-pattern is the “Solutionizer despot PO”, a Product Owner that always has the solution and replaces the team’s own thinking by proposing detailed solutions.

Elena’s example of a great Product Owner is someone that can bring Vision to the team. Help motivate and direct the team’s thoughts without imposing solutions.

Learn from Elena about how to tackle the anti-pattern, but also how to learn from the great Product Owner example to help your Product Owner succeed. After all, the team’s success depends on the PO’s performance!

 

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 Elena Popretinskaya

Elena considers herself a lifetime learner (she says, she absolutely loves having “aha!” moments). And she especially enjoys learning together with and from other people: her team and her friends. Elena is curious about everything: people, software craftsmanship and the world around. Elena is also a passionate hiker and a cross-country skier 🙂

You can link with Elena Popretinskaya on LinkedIn and connect with Elena Popretinskaya on Twitter.

Catrine Björkegren: the “my product is the most important” anti-pattern in the Product Owner role

In this episode, we introduce a new set of questions. Two questions that help us understand some of the most common anti-patterns in the Product Owner role as well what great Product Owners look like.

In this episode, we talk about a Product Owner anti-pattern related to the PO’s relationship with other PO’s in the organization. We discuss the “my Product is the most important” anti-pattern!

The Great Product Owner: When a Product Owner is able to bring in the business perspective and trust the team to find out what’s the best possible technical solution.

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 Catrine Björkegren

Agile coach and scrum master, Catrine has worked with agile for a decade in various areas like education, nuclear waste, government agencies, pharmaceutical and at the Royal Swedish Opera.

She believes that co-location is the key to building teams and that leadership is the key to successful agile transformation.

You can link with Catrine Björkegren on LinkedIn and connect with Catrine Björkegren on Twitter.

Kristopher Stice-Hall: The Self-Absorbed Product Owner Anti-pattern

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.

You can link with Kristopher Stice-Hall on LinkedIn and connect with Kristopher Stice-Hall on Twitter.

Top 3 challenges we face as product developers – #PDevTOOLBOX

After running a survey of product developers, I collected the following 3 top challenges that product developers face in their work.
  1. Unclear specifications with missing information like acceptance criteria, and that require large amounts of rework after we start developing a particular functionality
  2. Finding out critical use cases too late (via bugs, real-user feedback, etc), which leads to long delays in the project.
  3. 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.



2 major challenges I faced as a product developer

When I started developing software as a team member, and later as a project manager, I started to face some of the challenges that you are probably familiar with.

With the little experience I had, these challenges proved to be difficult to solve. During part of my journey, they even felt impossible to solve. I know better now…

The first and most important challenge for me was the need to meet a strict deadline.

We ended up calling it the Christmas problem.
Continue reading 2 major challenges I faced as a product developer

BONUS: Barry O’Reilly on What is Hypothesis-driven Development, and why that matters for Agilists

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:

  1. Leadership set an outcome (not a task!) Example: how to increase conversion by 10%
  2. Look for observations: where you try to understand what is happening in the product and to the product you develop.
  3. 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.
  4. Create simple experiments: actions that drive results, which you will compare with the hypothesis you created in 3.
  5. 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.

We go from investing in work to investing in learning. We might use Innovation Accounting, à lá #LeanStartup, or focus on creating Options and benefit from the concept of Optionality popularized by Nassim Taleb in his famous Black Swan book, but also referred to in Commitment, the book by Agile Coaches Chris Matts and Olav Maassen. This different focus will completely change your product development process to maximize the information generated and help you find new avenues for growth in your product.

We don’t do Projects anymore, we run Experiments!

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?

 

If you want to generate options you may try Teresa Torres ‘Opportunity Tree’ which is a great tool for generating experiment options to test hypotheses https://www.producttalk.org/2016/08/opportunity-solution-tree/

 

About Barry O’Reilly

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.

Barry is the co-author of the international bestseller Lean Enterprise: How High-Performance Organizations Innovate at Scale—included in the Eric Ries Lean series, and a Harvard Business Review must-read for CEOs and business leaders.

You can link with Barry O’Reilly on LinkedIn and connect with Barry O’Reilly on Twitter.

You can also contact Barry O’Reilly through his site, and sign up for his newsletter to get the latest news about Hypothesis-Driven Development.

EXTRA BONUS: to get 30% off Barry’s course you can go to www.leanagile.study  and use discount code THIRTYCPOFF before the end of December.

Jeff Campbell shares 2 transformative lessons he learned in the same company

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.

Karol Sójko on how Impact Mapping changed his way of thinking

Impact Mapping, a technique popularized by Gojko Adzic transformed how Karol thinks about software and product development.

About Karol Sójko


Developer, software architect and a team leader. Karol is a big fan of Behavior Driven Development and open source software. In his everyday work he tries to share his experience and actively participate in development and spreading a good word about open source projects like Symfony, Behat or PhpSpec. He is also fascinated by the process of making teams work better and tweak their productivity. After hours he is one of PHPers meetups organizers in Poland.
Karol is the author of To-Do: Team!: Simple productivity techniques for improving your team & making software that matters
You can connect with Karol Sójko on twitter, and subscribe to his helpful tips on how to get your team to the next level.