There Should Be Only One Product Owner (Team)
- Hits: 1988
The Scrum guide states that “the Product Owner is one person, not a committee”. To my understanding this is mainly to ensure a project set-up where a development team has a single source of knowledge on a problem they are trying to solve. There should not be a committee because it is likely that there would be a conflict of interests and opinions among committee members. They would probably need more time to reach a consensus and if the differences are such, they might even start making favors to each other in a form of compromises, and making compromises, on the product features, is not the way to maximize the value of the end product. Different committee members might even start approaching the development team independently – that would lead to a circle of misunderstandings and a waste of time and effort. It sounds very reasonable to have only one product leader.
So, there should only be one Product Owner. He or she is a product visionary and a leader. That means that he or she knows where the product fits within the programme or portfolio and how that product will contribute to the organization’s strategic objectives. On the project level, this person is able to clearly define product requirements throughout the development process. He or she discovers and describes product features, refines them and constantly improves the content of the product backlog. He or she is available to the development team, answers questions on a timely manner and is generally committed to provide a constant stream of viable product descriptions so that the development team effort is not wasted but rather optimized. This person's job is all about managing/optimizing the value.
More to come. He or she is not just a captain Jack Sparrow, navigating the ship and giving overall directions. Driving the development process also means diligently testing the features developed on a daily basis. If the team is “fed” with correct and well defined requirements it is likely to expect that they will provide more than enough content to keep the Product Owner busy with daily functional testing, reviewing both the “happy path” and exceptions in the workflow, discovering improvement opportunities and providing feedback to the team. The Product Owner is one and Development team is three to nine.
It is obvious that the Product Owner needs help in performing all aforementioned duties. On the other hand, I work in the government sector and, like in many other non-software organizations, an IT manager/engineer is seen as the person who should not just be in charge for IT project management but also accountable for the product success. Obviously, the IT person is not necessarily a problem domain expert. Even if this IT person supports business for many years, it still doesn’t mean he or she knows the answer to every question. Authors usually say that the Product Owner is in a business of informed decision-making, meaning that he or she should go back and forth to developers, business stakeholders and users trying to grasp what business stakeholders and users want and what developers can do and what they suggests; and then make sound decisions.
This sounds OK, product development IS a highly collaborative effort, but if the responsibility for product success is not clearly attached to those stakeholders with whom the Product Owner communicates with; how will they actually perceive their role in the project? Probably more like a persons who are there to be consulted from time to time and when issues arise. They might not be motivated or see the purpose of attending every planning or review meeting (IT system is an IT person job, right?), especially over longer period of time. The Product Owner will probably not have all the answers for the development team and will have to revert back to the business and user stakeholders to clarify things and make decisions. At the end, such a Product Owner might end up incapable of delivering a continuous flow of viable features' descriptions and details which really kill efficiency of an agile development process.
My Product Owner Team Practice
What I have been practicing, quite successfully for a while, is establishing something I call a Product Owner Team. This team is constituted as the collective decision-making and product management body of a client organization and consists of:
- Head of Product Owner Team
- Business stakeholders representative
- Users representative
- Development team representative
In short, the Head of Product Owner Team is “the first among the equal” performing a role of the Product Owner, accountable for the success of the product. This person is the driving force of the product development, the main motivator and communicator. However, the responsibilities of the Product Owner are shared among all the members of the Team. Every team member appointed to the Product Owner Team understands that he or she is responsible:
- To provide knowledge that will help manage the value of the product.
- To participate in all planning and review sessions.
- To contribute to Product Backlog refinement and define acceptance criteria.
- To test developed features and provide feedback.
Most of the activities Product Owner Team performs is in the form of face-to-face meetings. All the domain knowledge and mandate is present within the Product Owner Team so decisions can be made at the spot. To be able to participate in the Scrum development process, Product Owner Team is continuously coached by the Head of the Team. So Head of the Product Owner Team performs as a Product Owner towards the Development Team and acts as a Scrum Master of its own Team.
Benefits I’ve noticed so far are:
- Decisions and clarifications are made during the actual meetings, rarely afterwards and that happens only if issues have to be escalated to the organization management.
- Development team appreciates the opportunity to ask questions and clarify issues, and later on present work done to the actual users and business representatives. They recognize opportunities to suggest and discuss better, optimized solutions for the customer.
- Working with a Scrum team helps business users understand and adopt relevant Agile and Scrum values, principles and practices, which contribute to smooth development process; and maintenance later on. In one product development case my internal users eventually took over product ownership so now they are agents at the Service desk, they identify issues and improvement opportunities, and with the little help from my side, communicate with the developers, evaluate estimates against the expected business value, approve work to be done and later on do the functional testing of developed features and make release decisions.
- Every new product development is a change initiative and change is much easier to introduce when those affected by the change (business stakeholders and users) are in fact designing the change.
What Do You Think?
What’s missing or is wrong or good here? If you're an IT manager in a non-software organization, how do you practice Agile/Scrum development with the outsourced development team and how do you engage business stakeholders in development process? Please share your thoughts in the associated LinkedIn blog post.
Note: People silhouette image is from Visual AGILExicon.