A closer look into the world of the Product Owner that has to perform the required magic to get quality products out the door.
“The hardest part of building any software system is determining precisely what to build”
~Frederick Brooks – The Mythical Man Month
The primary purpose of product ownership is to maximize value to organizations, which is achieved by ensuring we meet our customer’s expectations and deliver a product which achieves the desired business benefits.
Product ownership is about the collaboration around requirements with various groups of people from various competency streams in the organization. On a small project in a large organization where only this one team is Agile, the Product Owner would be required to have small focused meetings with key representatives from within these specialized pods in the organization in order to assess the impact of the proposed changes to other systems or processes, the risk involved (compliance and risk advisories), whether what are we building complies with local legislation (legal advisory), whether the current infrastructure can host our changes (infrastructure representative) and if changes are required to other systems, by when can we have these changes done so that we can align etc. These representatives are the SMEs that together satisfies the characteristics of Value Management team.
In an organisation with multiple Agile teams, a product owner will be assigned to each team, and they would typically work together as a Product Ownership organism, or Committee. Let’s call it the POC (Product Owner Committee). The POC would be required to have a vision for various planning horizons, short-term planning, medium-term planning and longer-term planning. The output of this very high level planning are probably Epics at this early stage of their existence through the Cone of Uncertainty. These Epics are slotted onto the Product Road-map and serves as a navigational instrument as we iterate through the requirements to ensure we create a common vision in teams of when we expect what to happen. Not only does this help the POC, but it provides purpose to people working on the project, and guides their planning accordingly.
In large organizations it’s impossible for one individual to play the role of Product Owner effectively. Think about it, in unpacking a requirement, would your Product Owner know what systems are impacted by the requirement, what the legal consequences and requirements are to satisfy this requirement, whether the current infrastructure can support the change we are planning, whether we already have this functionality elsewhere that we can just re-use, is what we are dreaming up even possible in the current state of the application, and the list goes on for days. Well the answer is NO.
Effective product ownership therefore requires a team that has everything they need to identify and deliver the smallest increment of business value.
Product ownership embodies:
- Business advocates
- Customer advocates
- End user advocates
- Subject Matter Experts (or SMEs)
- Decision makers
The Agile Value Management Team
This team consists of a delivery team facilitator, Project management, Governance, Business Analyst and SMEs, User Experience experts and Graphic designers, User Acceptance testers and a Value Facilitator (Value Manager, Product Owner, Product Champion or a Steward). These are merely roles in Agile, and not titles.
The Agile Value Management team is a team that comprises all skills required to identify and prioritize business value in increments, scope the smallest Minimum Viable Product that would add value at the product increment and to do everything possible to ensure the Delivery Team has what it needs so that it can deliver at maximum velocity.
The Agile Delivery Team
The Agile Delivery team constitutes a Value Facilitator, Analysts, Testing, and Generalized specialists, Development, Architecture and a Team Facilitator (such as Scrum Master, Kanban Master or Steward.
The Delivery team has all the tools and skills required to enable them to deliver a working increment of product that is tested, documented and in a deployable state.
This is exemplary of an agile mind-set. If we look at a process to drive this thinking, we could look at for example Scrum as the execution method for these two teams. Dual Track Agile comes to mind, where Agile should be replaced with your chosen method of execution, be it Scrum, Kanban, ScrumBan etc.