Product Owners in a DevOps Setting

Devops is probably the biggest change to systems development in recent years. Oversimplifying a bit, devops can be said to be the practice of combining development and operations in teams, allowing one team to write the system, put it into production, and maintain it, while continuing to develop the system based on requirements and feedback from the users.

In a devops setting, the whole philosophy is aimed towards rapid feedback, allowing development to pivot quickly when needed. This results in devops teams trying to get things into production rapidly, preferably every time a significant change has been committed to the system.

Ever since devops was coined to describe the practice and principles of combining development and operations, it has been clear that this approach creates some challenges compared to the classic Scrum approach, especially relating to the product owner role. 

Product Owners in a Traditional Setting

Traditionally, product owners have been focused on maintaining a backlog for the Scrum team, ensuring that the most valuable tasks, be they in the form of stories or otherwise, are the ones that get produced first. Defining “valuable” carries its own problems, but it usually ends up as being whatever has the biggest monetary value, either in the form of income or in the form of cost avoidance.

The backlog is maintained through continuous contact with shareholders, business analysts, architects, and others who provide input on what needs to be built. 

Usually, the product owner tries to ensure that there are enough tasks in the backlog to ensure work for a couple of iterations.

The product owner is also usually the person in charge of making sure that the overall vision of the product is adhered to, and that the product does not divert too much from the vision. A tool often used for this is creating iteration goals to make clear what the purpose of the iteration is, rather than just what tasks should be finished.

In a non-devops setting, the product owner usually interacts with the Scrum Team either at the Scrum ceremonies, or when team members have specific questions. Most of the PO’s time is usually spent looking at future requirements and ensuring that they are described and broken out into tasks before they are needed in an iteration.

Challenges to the Traditional Product Owner Behavior

When working in a devops setting, the traditional product owner behavior faces some challenges.

The traditional approach of creating the backlog for the next couple of iterations, meaning perhaps a month or so, makes little sense in a world of rapid feedback, where the whole idea is to be able to pivot quickly. On the other hand, it is still relevant for all those times where there is nothing in the feedback that requires new tasks to be prioritized.

Most systems development doesn’t happen while maintaining the system in production. Either because it takes a long time before the system is deployed, or because the maintenance of the system is something that is handled by Operations or a special maintenance team. In a devops environment, the system is maintained by the same team doing the development of the system. This means that the development team must have time to correct bugs and other issues in production.

While doing Continuous Integration/Continuous Deployment and other important devops practices, several tools are needed. Depending on the setup, these tools are either used by all teams, and maintained by a core team, or have to be created or implemented by each team, depending on their needs. No matter what, this results in technical tasks for the development team, which the PO has to ensure are included in the backlog.

Due to the rapid nature of deployment and development, it can be hard for a product owner to ensure that the vision of the product is kept in focus. It can also be hard to ensure that the next important thing is done, rather than just whatever tasks are sufficiently ready for a developer to start working on.

Tips for DevOps Product Owners

There is no doubt that devops is here to stay. This poses some challenges as a product owner, but there are several ways to mitigate these challenges. I will make a few suggestions here, which I have found useful.

1. Finding the minimum production-ready product

First, try to make sure that you know what the absolute minimum that you can go into production with is. This is sometimes referred to as a Minimum Viable Product (MVP), but I find that an MVP often is bigger than the minimum necessary for the first release. E.g., if there is a workflow involved, you can sometimes chop it into pieces, releasing the first part, while preparing the next part. This means that you can gain feedback, and find bugs in the first part while working on expanding it.

Secondly, make sure that you understand what the main flow of the system is. The golden path, so to speak. No matter what system you are building, there will be one flow or another that the majority of people will use. This is the flow you need to keep in mind while finding out which parts can be built in what order.

E.g. a traditional online shopping system might have the following flow:

1. User navigates to website
2. User navigates to product
3. User adds product to shopping cart
4. Repeat steps 2 and 3 as needed
5. User navigates to shopping cart
6. User enters address and payment information
7. User clicks “Buy”
8. Order system receives order
9. Order system sends order to warehouse
10. …

This flow (including the many steps I left out) is the main flow for the shopping system. But in order to get something into production, you might only have to produce steps 1 to 7, as long as you ensure that you don’t lose the order until the order system is ready to receive it.

A good technique for finding this flow, and the tasks necessary for each step, is story mapping, a technique developed by Jeff Patton.

After finding the main flow for the system, all the tasks necessary to create it should be added to the first backlog of the product. This backlog should include any technical tasks for getting the main flow into production. The tasks for the minimum product ready system, including any technical tasks necessary for getting it into production, should have the highest priority in the backlog.

2. Reduce task sizes

In order to practice frequent production deployment, it is necessary for tasks to be of a reasonable size. They should also be defined in such a way that they can be deployed on their own without causing problems.

For large tasks where this is difficult, it should be considered if they can be broken down into smaller tasks, using feature flags to ensure that they are not visible to the end-user until all the necessary tasks are ready. This will allow deploying the code into production, finding unforeseen side effects, without the end-user being exposed to half-finished features.

3. Prioritization

As stated earlier, one of the core principles of devops is rapid feedback. Both to the developers about bugs, but also to the product owner and the Business about the features that have been released into the wild.

In order to take advantage of this, it is necessary for the product owner to continuously follow up on feedback, and to ruthlessly prioritize tasks based on the feedback. Any non-trivial bugs in production are as a general rule unacceptable and should be prioritized first, but just after that, any feedback from users should be taken into consideration.

In the shopping example, it might be that the users find the functionality useless because they can’t edit the shopping cart. In this case, a task about editing the shopping cart should be created, and prioritized above the tasks further along the flow.

In a devops setting in which deployments happen at least weekly, I highly recommend that the product owner keeps prioritizing the backlog as least as often as there are deployments, never letting developers start on anything that is not the highest priority.

While doing the prioritization, the product owner should keep the product vision firmly in mind.

For this to work, the product owner must have a real power to prioritize, or in the case this isn’t possible, direct access to someone who has it.

Related Articles:

• What Is Product Backlog Refinement?
• 6 Tips for Improving Product Backlog Refinement

4. Minimize the iteration backlog

Unless you keep your iterations the same length as the deployment cycle, it is necessary to consider how much should be initially taken into the iteration when it starts. As I mentioned above, prioritizations change a lot due to the feedback received after putting things into production, which means that it is hard to plan a whole iteration upfront. On the other hand, it is also necessary to ensure that core functionality and valuable add-ons are implemented, so it is necessary to do some sort of planning.

The solution for this is simply to reduce the tasks that the team commits to at the start of the iteration and instead, leave some space for bugs and tasks that are the result of feedback.

A way of doing this is to find the most valuable feature set that can be developed at this time, and make it the iteration goal to implement this particular feature. Thus, the team commits themselves to the tasks necessary for this particular feature, but not to anything else, making it possible to shift new tasks into the iteration, as needed.

For this to work, the backlog has to be continuously re-prioritized, and the team and product owner have to be in continuous dialogue about what other tasks should be taken into the iteration backlog.

5. Ensure a feedback loop between the team and the product owner

Since the development team is the one that maintains the system, they can gain insight into what does and doesn’t work, by observing users’ behavior (e.g. through logs). In order for the product owner and the stakeholders to use this input, it is important that a feedback loop is created from the team to the product owner.

This can either be through a formalized process, defined as tasks, or through a more informal channel. While the latter can be effective, I do recommend considering the first, since informal channels can easily break down and leave the product owner without valuable and necessary input.

Conclusion

While devops provides some challenges to the traditional product owner role, these can be addressed by adjusting the behavior of the PO, allowing the project to take advantage of devops. It requires commitment from the product owner, as it usually carries an extra workload. On the other hand, it also makes it easier for the product owner to understand the end-users, and take their behavior into consideration while working towards fulfilling the product vision.

Looking for more product owner resources? Subscribe to get curated articles and videos right in your inbox. 

====

About the Author

Kristjan Wager (CSM, A-CSPO) is a Danish consultant at Nine A/S. He has worked in agile projects since 2015 and has been a product owner for close to 10 years, mostly in projects in the public sector.