The Agile Product Owner
There’s a lot of talk about the ‘product-centric’ approach to DevOps but what does this mean for the role of the agile product owner?
Agile author Mike Cohn from MountainGoat Software says they act as a project’s key stakeholder:
“Part of the product owner responsibilities is to have a vision of what he or she wishes to build, and convey that vision to the scrum team. This is key to successfully starting any agile software development project. The agile product owner does this in part through the product backlog, which is a prioritized features list for the product. The product owner is commonly a lead user of the system or someone from marketing, product management or anyone with a solid understanding of users, the market place, the competition and of future trends for the domain or type of system being developed.”
Cohn’s definition is very project centric. The product owner’s role appears to be tied to the existence and duration of the project and their focus is on the delivery of features.
DevOps, conversely, asks us (in the ‘First Way of DevOps’) to use ‘systems thinking’ and focus on the bigger picture (not just features) and the product-centric approach says we need to focus on the entire lifecycle of the product, not just the delivery of a project/feature/phase.
Deconstructing the big picture into features is something we completely agree with, as features should be the ‘unit of work’ for your Scrum teams or ‘Agile Software Development Factory. However, this needs to be within the context of the product lifecycle (and the feature roadmap). So, the key shift here then is to start talking about the ‘product lifecycle owner’, not just the product owner, and systems thinking is a critical skill for the role.
Operational Requirements
The second big shift with DevOps is that non-functional requirements proposed by operations as being critical to the manageability and stability of the product across its full lifecycle from inception to retirement must be seen as equally important as the functional requirements proposed by the traditional product owner role.
In fact, we’d like to ban the term ‘non-functional requirements” (NFRs) completely, as the name itself carries an inherent negativity that we feel contributes to the lack of importance placed on NFRs in many organisations.
We propose the alternative term ‘operational requirements’ (ORs). This conveys the correct ‘product lifecycle-centric’ message about why these requirements are in the specification: “This is what we need to run and operate this product in production across the product’s lifecycle in order to maximise the product’s likelihood of meeting the business objects set for it”.
For those who are slightly more pessimistic or combative, the ‘OR’ could stand for “OR this doesn’t get deployed into Production…” .
Do We Need an ‘Operational Product Owner’
The unresolved question is do we need an ‘operational product owner’, or does the role of the traditional, business-focussed product owner extend to encompass the operational requirements?
You could argue that the operational product owner already partly exists as the ‘service delivery manager’ (SDM) within the ITIL framework. But SDMs rarely get involved in the software development lifecycle as they are focussed on delivery at the end of the software development lifecycle (SDLC). However, their role could be extended to include driving ORs into the SDLC as part of the continual service improvement (CSI) process.
That said, having two product owners might be problematic and confusing from the agile development team perspective so it would probably be preferable if the traditional business product owner was responsible for ORs as well as the functional requirements. This may require the product owner to have a significantly deeper understanding of technology and operations than previously. Otherwise, discussions about why ‘loosely-coupled session state management’ is important to ‘horizontal scalability’ might result in some blank faces.
In Summary
So, in summary a DevOps product owner needs to:
- Embrace system thinking and focus on the product lifecycle, not just projects or features.
- Understand the operational requirements (and just say “No to NFRs”).
- Ensure that the ORs are seen as of equal importance to the functional requirements in the product roadmap, and champion their implementation.
