This debate regarding skill set and reporting lines is common amongst new Agile teams. This topic was first addressed in Part 1 of this blog post which can be found here.
The Scrum Guide defines a the role of a Product Owner as follows: The Product Owner is responsible for maximizing the value of the product and the work of the Development Team. How this is done may vary widely across organizations, Scrum Teams, and individuals.
The Product Owner is the sole person responsible for managing the Product Backlog. Product Backlog management includes:
- Clearly expressing Product Backlog items;
- Ordering the items in the Product Backlog to best achieve goals and missions;
- Ensuring the value of the work the Development Team performs;
- Ensuring that the Product Backlog is visible, transparent, and clear to all, and shows what the Scrum Team will work on next; and,
- Ensuring the Development Team understands items in the Product Backlog to the level needed.
Pros and Cons of both approaches were identified as:
|Product Manager||Platform Manager|
|Skills: Market knowledge, strategy and vision, access to stakeholders||Skills: Technical delivery, vendor management, project management|
|Concerns: Lack of technical background, never worked with IT vendors, not enough time available to the team||Concerns: Not enough business savvy, would fall into traditional framework to manage projects. Would have to solicit requirements but wasn’t empowered or knowledgeable.|
The result of this specific debate was to have the Product Owner role report into the Business and be filled by an individual from the Product Management team. Since the Product Manager didn’t have enough available time to spend with the team due to the breadth of their responsibility, an Associate Product Manager filled the Product Owner role. The Associate Product Manager was empowered to make most of the major decisions about the product and when necessary they validated decisions with the Product Manager.
So how did this specific decision turn out?
One of the most significant and unexpected outcomes was that it encouraged the team to take ownership of all aspects of product delivery instead of relying on the Platform Manager to worry about the technical delivery details as they had in the past.
What we thought was an initial weakness (lack of technical project delivery experience on the business side) actually caused the team members to become stronger in the end by complementing each others strengths and allowing everyone to learn new skills. By having a unique mix of skill sets from both Business and IT working together the team advanced to new levels of performance.
With this story in mind, consider your own organization: How are your teams structured? Who is serving in the Product Owner role? And who does this role report to within the organization?
If your IT organization currently fills this role and you struggle with business representation and participation on your projects, I would challenge you to run an experiment for a few sprints: find someone with Product Management interest and skills from the business side of the organization and empower them in the Product Owner role instead. After a few sprints or a release cycle evaluate the decision in the retrospectives and make additional adjustments if necessary based on how the change is working for you.