The role of the Proxy Product Owner is to fill in the gaps in the implementation of agility. It is an important cog in the balance of the project and a step forward in the Agile transformation.
In recent years, a new role within agile teams has emerged: The Proxy Product Owner (also known as Proxy PO or PPO). Although the Scrum methodology doesn’t define this role yet, it is increasingly gaining ground.
What is the PPO’s scope of work? How sustainable is this role within the agile company?
Project teams have become accustomed to working remotely, on different company sites, sometimes even speaking different languages. This has become even more pronounced with the health crisis and remote work.
Despite the collaborative tools that facilitate remote work, teams are often facing the same problems:
- The Product Owner is hardly available to developers: he/she is often involved in the business part and not directly in contact with the Scrum teams.
- Scrum teams call for the PO to have a better knowledge of agility.
- Scrum teams lack visibility on future developments, even though this visibility could allow them to make better technological choices, including in the way they design the code.
So, what is the scope of work of the PPO?
The PPO can take on several roles:
- The PPO fills in for the PO when needed: in this case, the PPO is ultimately a "PO in the place of the PO" in the roles and missions he takes on.
- The PPO works in parallel with the PO: the PO can focus on strategic aspects and the PPO can work on more operational tasks in conjunction with the Scrum master.
In practice, the three roles are complementary and form a trio: PO/PPO/Scrum master.
In all these configurations, it is essential to define and communicate the precise role of the PPO: his operational scope and his responsibilities towards the stakeholders. In this way, the PPO will be able to define his place and gain credibility within the agile team.
Depending on how the PO/PPO/Scrum master trio is balanced, the following missions will frequently be fulfilled by the PPO:
- The routine tasks of the PO: feeding the backlog, describing business needs using collaborative tools (e.g., Jira/Confluence, etc.), writing and breaking down User Stories (US), monitoring progress,
- Clarification missions on certain subjects (clarity on a user story, and which customer need it answers, etc...): this will allow to quickly eliminate ambiguities and thus reduce the time wasted due to back-and-forth discussions between the PO and the Scrum team. This also helps to establish a framework of trust with the developers....
- The PO may also be responsible for analyzing customer anomalies and feedback following production releases (MEP)...
Whatever the role, the PPO will contribute to the creation of value and facilitate the success of the project.
And what about real-life scenarios?
As the role of the PPO is not precisely defined in the Scrum methodology, it is common to find in projects the same role organized differently and with other denominations.
For example, in the context of a project led by our teams, it was important to distinguish between "business POs" and "IT POs", to the point of forming a team of 6 POs.
Beyond the name used, it is once again the role description and the associated scope of work that is decisive for the team to function effectively.
Still within the framework of this project, the intervention of an agile coach was beneficial to allow each stakeholder to express their pains and collectively find solutions (here, the addition of new PO roles and the implementation of new features teams).
To conclude, even though the Proxy Product Owner role addresses dysfunctions in the implementation of agility, however it is an important component in the balance of the project.
It is also a driver to advance the agile transformation.
Some points of reference
Anti-Pattern: In software engineering, anti-patterns are common software design errors. Their name derives from the fact that these errors appeared during the design phase of the software, in particular by the absence or the bad use of design patterns.
By extension, the term anti-pattern refers to the various errors commonly committed in the application of a methodology (in our article, the agile methodology).
