Becoming great at answering the wrong questions

"The right answer depends on the question"

This proverb has long guided me and I always strive to ask better questions.

This week, I evaluated some devops tools and felt oddly reminded on how similar the effectiveness of DevOps is to a product owner's story writing.

The wrong user story doesn't deliver the business value you're looking for.
Here are some of the highlights for poorly written user stories that I encountered while evaluating tools. Marketing makes these stories look like they are what you'd really want in your DevOps stack. But let's take a closer look.

As a DevOps, I want to see way back in time when certain error messages occurred so that I know how long it has been going on.

Yikes! If there are unknown error messages in the logs which nobody has been taking care of for months on end and nobody realizes - or cares - then either it's not important or your organization is in a mess. You don't need a tool that permits you to discover errors a year back in time, you need a strategy to effectively deal with problems as soon as they occur!
Let me rephrase that story for you: "As a DevOps, I want to be notified immediately when something abnormal happens so I can analyze and resolve the problem before it hits the customer!"

As a DevOps, I want to have a one-click solution which connects stack traces in log files with the corresponding source code segment so that I can analyze the effect on the user easily.

Good luck on that. I personally prefer to have robust, well-tested software, If your software is throwing significant amounts of stacktraces, then the effect on the user isn't your primary problem.
Let me slice this one for you: "As Sysop, I don't want any stack traces in production logs, because I don't want to operate a system that doesn't do what it's supposed to do." - and - "As a Developer, I want a software test that has sufficient path coverage so that I won't run afoul of undefined behaviours during refactoring." - and - "As application user, I expect the software to behave as intended in each and every circumstance so that my business outcome is predictable."

As a Security expert, I want to be notified in real time when user data is compromized.

Sounds great. But what are we really talking about here?  Why do you even care to know that in real time? There are predictable, controllable ways in which user data can be compromized. In this case, your strategy shouldn't be to introduce realtime notification, but prevention. Any minute you're investing in data theft detection would be significantly better invested in hardening your systems.
Let me rephrase that one: "As a data security officer, I want all known security loopholes closed so that we don't even have data security incidents!"

As a DevOps, I need data for every possible failure scenario so that in case of incidents, I have enough data.

Tools will give you a false sense of control when you ask the wrong question. Your question is not to have data for everything, but to eliminate root causes - so that you won't need data.

Your job as a DevOps is not to hoard a boatload of data that can't be humanly understood, your job is to eliminate operative risks within the software so that the essential monitoring data can be reduced to a manageable and comprehensible level.

Conclusion

Tools are not solutions unless you first define the problem.
Your DevOps Strategy will fail unless you first learn to ask the right questions.

Shared Vision over dedicated Product Owners

The first value of the Post-Scrum Manifesto states "Shared Vision over dedicated Product Owners".

To understand what this means, we must briefly glance at why we even have Product Owners in Scrum.

The role of the Product Owner

The primary role of the PO is to communicate the product vision with all stakeholders and maximize product value. When there is a misunderstanding or dispute, the PO facilitates the dialog. Moreover, the PO owns the Product Backlog. They decide what will be part of the product - and what won't. They set the priority and are accountable for making the right calls. Customer facing, the PO is responsible for what the team delivers. Team facing, the PO is responsible for what the customer wants.

What happens when you don't have a Product Owner

Let's just assume we have a textbook Scrum team, but the PO is missing. The first thing that will practically always happen is that stakeholders start bombarding the team with feature requests, everyone considering their own requirements top priority. The team now has the job of juggling all those requests while delivering working software. 

If the team is lacking a person who is capable of calling shots on either-or options, they run a great danger of implementing inferior solutions, dissatisfying the customer. 

On a more positive note, the responsibilities of the PO will typically be picked up somewhere, either through the customer side or the team. Unfortunately, there is no guarantee this will happen before the product failed.

Why having a dedicated Product Owner is bad

Having a dedicated PO communicate stakeholders on the product vision and making tough calls on value choices is good, but it's still a bottleneck. Since being agile is all about never ever maneuvering yourself into a corner, it simply doesn't make sense to enforce a bottleneck.

The need for a dedicated PO actually indicates symptoms for a number of problems:

Different levels of understanding

It's good if someone can explain the product vision to others, it's better if everyone shares it and product vision communication should never be a unidirectional process. 

Single Point of failure 

When someone needs to call shots, it means that this person is can singlehandedly cause an otherwise successful product to go awry. A good PO will never be a dictator, but since the PO will always filter information through their personal viewpoint, unsound decisions may be made. The more decisions PO doesn't need to make because the team has the knowledge and ability to make them, the lower the risk of having a SPOF actually failing.

Also, developers may become paralyzed or make wrong decisions if the PO is unavailable for clarification.

Stakeholders management over consensus

When someone needs to call shots, it means that different stakeholders set different priorities. This may always happen, but is a situation where one person has the final say really better than being able to come to consensus? 

Translate: Business-Developer, Developer-Business

The PO facilitates the dialog between team and customer, especially in situations where business expectations are technically unsound. In theory, this sounds good. In practice, we have an agile value "Customer collaboration over contract negotiation". Nowhere does it say customer collaboration is limited to the PO. If every developer collaborates with customers on a daily basis, the mutual understanding will be there without having a facilitator in the middle.

Assumption of incompetence or apathy

We get taught in Scrum classes that PO's understand the business value and know which increment is best to advance the product's value. Superficially, and in an immature organization, that is true: Oftentimes, developers have no understanding of business value. But that shouldn't be considered a given law of the universe. In Programmer Anarchy, there is a radical shift: Developers not only understand what is the best value for the customer, they are so closely interlinked with customers that they drive: They deliver working software and let the customer decide whether they're getting their money's worth. Sounds odd? Making developers business savvy, instilling them with a keen sense of where the money lies is sure better than simply assuming they're either idiots who know squat or who frankly don't care how their living is earned.

Just consider yourself as a developer: Which would you prefer? Having someone tell you that you have no sense of business - or having someone bring you to the point where you can do everything they can?

It is good if the team has a product navigator - it is better if everyone can read the compass to the pot of gold.

Summary

It is not wrong to have a PO. But don't focus on establishing and strengthening the role of the PO- Raise up the entire team to fulfill the responsibilities of the PO, and the dedicated PO will be superfluous.