BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage Articles Q&A on the Book The Professional Product Owner

Q&A on the Book The Professional Product Owner

Lire ce contenu en français

Bookmarks

Key Takeaways

  • Product Owners need to be more than scribes or proxies; they are true agile product managers
  • Scrum is a tool for agile product delivery, not for project management
  • The Professional Product Owner has an entrepreneurial mind set 
  • The Professional Product Owner is responsible for the Vision, Value and Validation of the product
  • Scale your Product, not your Scrum

The book The Professional Product Owner explains what Product Owners can do to become real entrepreneurs who initiate and drive products, and what teams can do to release frequently. It provides ideas and personal anecdotes for effectively applying the Scrum Product Owner role and activities.

InfoQ readers can download an excerpt from The Professional Product Owner.

InfoQ interviewed Don McGreal and Ralph Jocham about the different layers of planning in agile product management, product delivery, how Nexus supports alignment between multiple teams, what it means to be a Professional Product Owner, and developing Product Owner skills.

InfoQ: What made you decide to write this book?

Don McGreal: Ralph and I are both stewards of the Scrum.org Professional Scrum Product Owner course. Over the years, we worked with Ken Schwaber and the rest of the Scrum.org trainer community to redesign and modernize it. Ralph and I have taught the class hundreds of times and thought it’d be a good idea to write a book as a perfect companion to the course.

The theme we consistently see amongst our students and the industry as a whole, is that the Product Owner role is not well understood and many end up as requirements secretaries (scribes) or requirements traffickers (proxies). This book aims to fill that gap by bringing empowerment and entrepreneurship to the role.

InfoQ: For whom is it intended?

Ralph Jocham: Anyone who is starting his/her journey as a Product Owner. This book builds on and augments our Scrum.org PSPO (Professional Scrum Product Owner) Training with additional ideas, concepts and practices which cannot be addressed in a two-day class. 

McGreal: Like Ralph said, this book is ideal for new Product Owners, but it is also filled with ideas and practical techniques that experienced Product Owners may not have come across.

InfoQ: What are the different layers of planning in agile product management and delivery, and how do they build upon each other?

McGreal/ Jocham: This is straight out of our book:

At the core of any Scrum-based approach is a daily plan within a Sprint plan. Both these plans belong to the Development Team that is doing the work. They have autonomy in developing a plan on how to best meet the Sprint Goal and inspect and adapt that plan every day.

 

 

The two outside planning layers are the overall company vision and business strategy. Both are typically owned by an executive team or CEO, who establishes and communicates a company-wide vision and promotes an overall strategy under that vision.

In between the larger organizational goals and the work that Development Teams do day-to-day is a gap. We call this the Product Management Vacuum, and it is a major motivation for writing our book. The thing about any vacuum is that it has an innate need to be filled. If you are not careful, the Product Management Vacuum will get filled with meaningless busy work and extensive task management. All the layers of budgeting, project charters, handoffs, and tasks breakdown mask the true intention of the initiative. You run the risk of being busy without a clear direction.

We suggest instead filling this vacuum with the three Vs: Vision, Value, Validation.

  • Vision creates Transparency.
  • Defining Value provides you with something to Inspect.
  • Validation causes Adaptation.

Our book dedicates a chapter to each of the three Vs.

 

 

InfoQ: How can we know if we have a viable product?

Jocham: Customer happiness is the final validation, that is why we have to get as close as possible to our end-user by releasing frequently. The three Vs feedback loop (Vision, Value, Validation) needs to be closed as often as possible allowing us to validate value by observing predetermined metrics. We also talk about EBMgt (Evidence Based Management) as a way to measure value over time.

McGreal: It is key to form a hypothesis early on about the value we want to generate and then find a way to measure it. The only way to move that value measurement needle is to release. Product Owners that find ways to release something earlier will know if they have a viable product sooner. Sometimes an early release could be a simple proof of concept, a survey, or some other experiment to see if there is even a market. 

InfoQ: What is holding back teams from releasing? How can they deal with that?

McGreal: In my experience, there are three reasons:

  1. Nobody is even thinking about itThey’ve gathered some requirements and adopt a project mindset of “It’s done when the requirements are done.” A good Product Owner here is key. One that is constantly searching for the next MVP.
  2. Development Team is blockedTheir infrastructure and technical debt is so bad that they simply cannot get to ‘Done’ within a Sprint. It takes forever to regression test, deploy, merge. The only way out is to start paying off debt each Sprint until you can bring these activities into a Sprint. 
  3. No focus on ‘done’Development Teams sort of kind of finish items off the Product Backlog because there isn’t a clear shared agreement as to what ‘done’ even means, leaving a pile of work to do at the end.

Jocham: It is all about being “done”, meaning there is no work remaining in order to release. Scrum is over 22 year old; it is everywhere. However, most don’t manage to get to “done,” but they keep on working in order to make progress. Progress can mean a lot but it can also mean nothing - forcing them into planned major releases which surely are not agile and carry high risk.

As a fix, many companies have different definitions of “done” for various stages toward a release. At first this seems like a viable idea, but in the end you just mask your inability to get to “done”, and thereby lose transparency.

The question about reaching “done” is about timing. When do you reach “done”? Once every couple of months with a major release? Once a Sprint? After the completion of a single Product Backlog item? Even more frequently? Getting there means improving your game by updating your technology, minimizing dependencies, automating everything (tests, integration, deployment, etc.).

InfoQ previously interviewed Ken Schwaber about the Nexus guide, a companion to the to the Scrum Guide that facilitates employing three to nine Scrum teams in an integrated effort to develop software. InfoQ also interviewed Patricia Kong in March 2018 about the updates in the Nexus guide.

InfoQ: How does Nexus support alignment between multiple teams?

Jocham / McGreal: Scale your product, not your Scrum. Instead of breaking your product into many smaller components, consider it as one large product with one Product Backlog and one Product Owner. We have seen this scale up to nine Development Teams. With nine Development Teams you have quite some manpower for fairly large products.

Nine Development Teams pulling work out of one product leading to one “done” increment requires a well coordinated cross-team collaboration. This cross-team collaboration is successful if you have integrated working product every single day. Before the regular Daily Scrum there is a Nexus Daily Scrum where representatives from every Development Team check if the increment is “done”. If yes, all is good, if no, then they investigate the cause with possible action items and bring this information to their individual Development Team where it can be addressed in their Daily Scrum. By priority, fixing the broken product always precedes any other work and thereby ensuring a working product.

The team coming together for the Nexus Daily Scrum is called the Nexus Integration Team (NIT).

This also affects other events like the Sprint Planning, and Sprint Retrospective, as well as how Refinement is coordinated.

InfoQ: What does it mean to be a Professional Product Owner?

McGreal: In short, a Professional Product Owner needs to understand the big picture and realize who they are building the product for; whose lives are being improved by what we are building and who has the most to lose if we don’t do things the right way?

Sure, we can get this thing done on time and on budget, but who will feel the pain if it’s not the right thing? Sure, we can get this out the door without paying attention to maintainability and total cost of ownership, but who will pay for it in the end?

Jocham: In order to be a Professional Product Owner you need to initiate and drive the product. Too many Product Owners are on the receiving side of requirements, they are being told what to build. They don’t own the product; they are more like traditional project managers. 

 

 

A Professional Product Owner understands the business for which the product is being developed and also manages the budget of the product, being in power to make trade-off decisions when needed. Even better, a Professional Product Owner has an entrepreneurial mindset and treats each Sprint like they are spending their own money.

InfoQ: What are the skills that Product Owners need and how can they develop them?

Jocham: In our trainings, we have one exercise where we ask the students to describe the skills of a great Product Owner. Over the course of hundreds of trainings with thousands of students, we collected some interesting data. Foremost, the Product Owner needs strong domain and business knowledge which is closely followed by strong communication skills. The other top skills are negotiation, analytical, engaged, and stakeholder management. 

Overall, the Product Owner needs to feel ownership and pride for the product and the value that they’re providing their stakeholders.

About the Book Authors

Ralph Jocham spent the last 20 years collecting professional software and product development experience in Germany, France, the UK, the USA, and now Switzerland. He became an Agile evangelist in 2000, he is a Scrum.org Professional Scrum Trainer and has taught thousands of professionals around the globe. When not busy running his company, Effective Agile, or helping all kinds of enterprises in Europe, he enjoys teaching at universities. Jocham is a course steward for the Scrum.org Professional Scrum Product Owner course taught around the world.

Don McGreal, in his role as VP of Learning Solutions at Improving, is a hands-on agile consultant and instructor. He specializes in agile coaching at the enterprise and product management levels within larger organizations. McGreal is a Scrum.org Professional Scrum Trainer who has authored and taught classes for thousands of software professionals around the globe. He is also co-founder of TastyCupcakes.org, a comprehensive collection of games and exercises for accelerating the adoption of agile principles. McGreal is a course steward for the Scrum.org Professional Scrum Product Owner course taught around the world.

Rate this Article

Adoption
Style

BT