7348317140_e30eeda034

DevOps and the Product Owner

In a previous post we talked a lot about the “Product-centric” approach to DevOps but what does this mean for the role of the Agile “Product Owner”?

So what is the traditional role of the Product Owner? Agile author Mike Cohn from MountainGoat Software defines it thus:

“The Scrum product owner is typically 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” – Mike Cohn

The definition above 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 “feature-itis”) 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.

Whilst decomposing 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”, it 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 ensure that Systems Thinking is a critical skill for that role.

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” (NFR’s) completely, as the name itself seems to carry an inherent “negativity” that we feel contributes to the lack of importance placed on NFR’s in many organisations.

We propose the term “Operational Requirements” (OR’s) as we feel that 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”.

We propose the term “Operational Requirements” (OR’s) as we feel that this conveys the correct “product lifecycle-centric” message about why these requirements are in the specification.

For the slightly more pessimistic or combative amongst you the “OR” in Operational Requirements can stand for “OR this doesn’t get deployed into Production…” .

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 SDM’s rarely get involved in the software development lifecycle as they are focussed on the “delivery” part at the end of the SDLC. Their role could be extended to include driving Operational Requirements into the SDLC as part of the continual service improvement (CSI) process however.

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 also responsible for the operational requirements 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 trying to understand why “loosely-coupled session state management” is important to “horizontal scalability” might result in some blank faces!

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 NFR’s”!)
  • Ensure that the “OR’s” are seen as important as the “Functional Requirements” in the Product roadmap and champion their implementation

In future posts we’ll examine the impact of DevOps on other key roles in the SDLC & Operations. We’ve love to get your opinions in the comments section below!

-TheOpsMgr

image source: – CC  – CannedTuna via Flickr – http://www.flickr.com/photos/cannedtuna/7348317140/sizes/m/

About these ads

4 thoughts on “DevOps and the Product Owner”

  1. I completely agree about the need to ditch the term “NFRs”, and move to something like Operational Requirements. My suggestion was Operational Features, to try and move even further away from the up-front “requirements-gathering” mentality: http://blog.softwareoperability.com/2013/04/08/lets-talk-about-operational-features-not-non-functional-requirements/

    I’ve also been bleating on about the importance of software operability, most recently at the DevOps Summit events organised by Unicom: http://blog.softwareoperability.com/2013/11/16/slides-software-operability-and-run-book-collaboration/

    In answer to your question “do we need an “Operational Product Owner” or does the role of the traditional, business-focussed Product Owner extend to encompass the operational requirements?”, many people suggest from experience (me included) that only if the Product Owner has been woken up a few times at 2am due to ignored operational features/requirements will the operability of the software be taken seriously. In that case, the operational concerns need to be first-class alongside the ‘end-user’ concerns.

    Matthew

  2. The answer to the question “do we need an Operational Product Owner” depends how we define the “normal” PO:
    If “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” of course we need someone who is closer to the “technical” view of the developers beeing able to cover operational and architectural issues also, which must be part of the Backlog. Remember: “The Product Backlog is an ordered list of ***everything*** that might be needed in the product … The Product Backlog lists all features, functions, requirements, enhancements, and fixes that constitute the changes to be made to the product in future releases.” (part of the Scrum Guide).
    Based on that the role descrition of the PO in the Scrum Guide is very idealistic, describing the PO as a supermen (see page 14 in http://www.korn.ch/archiv/seminare/hoert-endlich-auf-herumzuSCRUMen.pdf) This may fit for small enterprises and projects, not for larger ones.

    So: Do we need two PO for each team? One “user & market oriented PO” and one “Operational Product Owner” (or “Technical Product Owner”, as it is already the case in some companies)?

    I think no. This will undermine the core principle: “The Product Owner is the sole person responsible for managing the Product Backlog” and “The Product Owner is one person, not a committee. The Product Owner may represent the desires of a committee in the Product Backlog, but those wanting to change a Product Backlog item’s priority must address the Product Owner”.

    A working solution is, to have a (= one) PO for each team who is:

    Solution/technology/team facing
    Colocated with, and reports into development
    Contributes to Vision and Program Backlog.
    Ownsteam backlog and implementation.
    Drives sprint content via prioritized Stories
    Establishes story acceptance criteria, accepts stories into the baseline

    And – on the Program level – a Product Manager (sometimes called “Chief PO”) who is:

    Market/customer facing
    Colocated with, and reports into marketing/business
    Owns Vision, pricing, licensing, ROI, and Program Backlog
    Drives release content via prioritized Features
    Establishes feature acceptance criteria

    This is proposed by SAFe, see http://scaledagileframework.com/product-owner/

    If we understand the PO (for the teams) in this way, such a PO is able (and have to) to take care for operational and architectural issues also, which in many cases are derived from “architectural features” http://scaledagileframework.com/architectural-feature/ and “architectural epics” http://scaledagileframework.com/architectural-epic/

    Changing the name from “NFRs” to “Operational Requirements” IMHO does not cover all what we mean in a better way. It may focus too much on “operation” only, not on issues like supportability, testability and usability. Looking at fig.1 in http://scaledagileframework.com/nonfunctional-requirements it is hard for me to find a much better name than NFR for this…

  3. At times, prioritizing operational requirements can be challenging. It is, nonetheless, important to the business and a worthwhile exercise. In keeping with the spirit of this article, I’ve been working on changing terminology around Agile projects, too. Most notably, I’ve been shifting focus from being “done” to being “ready”. All of the coding and QA and deployments a team completes may lead to a release (incorrectly labeled as “done”), but a release is only the beginning of the customer experience. Therefore, in the interest of delighting your customers, focusing on production readiness (via operational requirements) is critical to the success of a project. So, shifting focus from “done” (released) to “ready” (operationally supportable) sets up the whole team for successful lifecycle management. Without this cultural shift, production issues will lead to infighting while the customer suffers. With the shift, production issues are a link in the feedback loop, serving to strengthen the team and the product on which they are working together…

Give us your thoughts!

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s