Jim Bird

About Jim Bird

Jim is an experienced CTO, software development manager and project manager, who has worked on high-performance, high-reliability mission-critical systems for many years, as well as building software development tools. His current interests include scaling Lean and Agile software development methodologies, software security and software assurance.

How Product Ownership works in the Real World

Scrum continues to insist that a single person play the role of Product Owner on a development project. One person sets the team’s direction and priorities, defines what the system will do, manages the backlog of requirements and decides when work is done. But like many other organizations, we’ve found that this doesn’t work.
There are too many functional and operational and technical details for one person to understand and manage, too many important decisions for one person to make, too many problems to solve, too many questions and loose ends to follow-up on, and not enough time. It requires too many different perspectives: business needs and business risks, technical dependencies and technical risks, user experience, supportability, compliance and security constraints, cost factors. And there are too many stakeholders who need to be consulted and managed, especially in a big, live business-critical system.

A Single Product Owner doesn’t Scale

Roman Pichler says that one Product Owner can support one or at most two feature teams. What do you do on large projects, complex products with tens or hundreds of people involved? You’ll need to put together a product ownership team, with a hierarchy of product owners reporting up to a product manager or program manager. Or find some other way to spread the product owner’s responsibilities across more than one person, splitting up some of the work between a product manager and one or more business analysts to take care of the detailed work, or try Customer Pairing, or some other Customer responsibility pattern.

A principle of Agile development is that you get the best results from people working together: better understanding, better designs, better code. So why ask one person to make all of the important decisions about what needs to be built?

Who’s your Product Owner?

In our shop, each system has a sponsor: a business executive with day to day operational responsibilities and the authority to make strategic business and product decisions. The sponsor sets overall direction and goals for the system, and finesses any politics, arbitrating conflicting demands and priorities from different stakeholders: customers, partners, sales, ops, compliance, development. The sponsor makes go/no go decisions for major initiatives and trade off decisions on risk and cost when the stakes are high.

The other responsibilities are spread across development leads, developers, testers, customer service and other people in the organization.
Development leads take care of most of the work of managing the backlog and detailed planning and prioritization of features and fixes, working with the sponsors, developers and QA and ops and other stakeholders to set development schedules. This gives the development team more control over managing technical dependencies and technical risks in deciding how will work will be done and what work can be done together.

Development leads and developers fill in the requirements, writing and reviewing specs, building prototypes, holding workshops, discussing and arguing out alternatives and clarifying details, running experiments, working out the design. They know when to go to the sponsor or other stakeholders when they need clarification or other help. They can take care of this because everyone on the team has been working in this business area for 5, 10 or more years, and have the necessary insight and experience.

Dan North explains in “Accelerating Agile: Hyper-performing without the Hype” that the key to hyper-productive Agile teams is to have people who really understand the domain, so that everyone can contribute, fill in details, make suggestions, question assumptions, assess risks, and make decisions when they need to. Fill your team with people who have worked on the same kinds of systems before, get everyone training or hands-on experience if possible.

Deciding on Done

Deciding when work is done – which for us means that the code is ready to be released – is also shared across the team.

Developers write their own unit tests and test their own changes. All code has to pass the automated regression test suite and static analysis checking in Continuous Integration.

Development leads review all code check-ins for to make sure that the code is correct, safe and maintainable – that it is done properly.
QA engineers test each feature or change or fix, including integration testing and exploratory testing to verify that the feature or fix does what it is supposed to. They also review usability, bringing in other stakeholders like customer service or ops as they need to.

Before changes are released, our release manager (who is also the head of our QA team) checks that all of the reviews and demos are done and all tests are passing, assesses risk, decides which code is ready for release, and then calls a release meeting with the sponsor, development, ops and other stakeholders. The sponsor looks at all of the steps and checks that were done, reviews major changes (especially changes that have regulatory impact or carry operational risk) and gives the ok that the release can proceed.

This is how Product Ownership should Work

Having multiple people share product ownership responsibilities lets us get more work done. We also do a better job: more viewpoints and more knowledge and more opportunities to catch mistakes. It creates more opportunities for everyone on the team to participate and contribute back to the business. And all of this becomes self-reinforcing. The more that more people get involved in product ownership, the more that they will learn. The more that they learn, the better job that they can do and the more that they can contribute back. The organization gets better, the product gets better. Why wouldn’t you want that?

 

Do you want to know how to develop your skillset to become a Java Rockstar?

Subscribe to our newsletter to start Rocking right now!

To get you started we give you two of our best selling eBooks for FREE!

JPA Mini Book

Learn how to leverage the power of JPA in order to create robust and flexible Java applications. With this Mini Book, you will get introduced to JPA and smoothly transition to more advanced concepts.

JVM Troubleshooting Guide

The Java virtual machine is really the foundation of any Java EE platform. Learn how to master it with this advanced guide!

Given email address is already subscribed, thank you!
Oops. Something went wrong. Please try again later.
Please provide a valid email address.
Thank you, your sign-up request was successful! Please check your e-mail inbox.
Please complete the CAPTCHA.
Please fill in the required fields.

Leave a Reply


five − = 3



Java Code Geeks and all content copyright © 2010-2014, Exelixis Media Ltd | Terms of Use | Privacy Policy | Contact
All trademarks and registered trademarks appearing on Java Code Geeks are the property of their respective owners.
Java is a trademark or registered trademark of Oracle Corporation in the United States and other countries.
Java Code Geeks is not connected to Oracle Corporation and is not sponsored by Oracle Corporation.
Do you want to know how to develop your skillset and become a ...
Java Rockstar?

Subscribe to our newsletter to start Rocking right now!

To get you started we give you two of our best selling eBooks for FREE!

Get ready to Rock!
You can download the complementary eBooks using the links below:
Close