One day I was discussing with Josh (not his real name) a problem we have with the customer. The problem is a very common one: priorities keep changing, every day we receive new “urgent” tasks, we have lots of work-in-progress, and it’s difficult to get the customer to approve or give feedback on what we did.
Josh did not agree with me on the nature of the problem. He said that he respects our customer as Product Owner; he accepts the priorities, and any new task they give us is properly recorded in the backlog. But Josh, I said, I’m afraid that the day-to-day priorities they give us are not what the customer really needs. The boss of the person that gives us priorities may not be happy with the results we are getting. Josh replied, “if what we do is not what their boss wants, then let it be. It will come up at some point.”
What is Josh thinking? It may be that his reasoning is “it’s not the best course of action for us to rock the boat with their boss; your worries might be wrong, perhaps the priorities are right after all. And if you are right and the priorities are wrong, well, the best course of action is to let this problem emerge.” That’s my best interpretation of what Josh thinks.
The other interpretation is that Josh is delegating responsibility to the customer’s product owner. If the PO gets priorities wrong, we’ll fail, but it will not be our fault. It’s another way to say “You just tell me what I have to do and then I do it”. This goes against the principle of taking responsibility for the outcome of a project. The reasoning is that if the project fails, we can show that we did all that was required of us. But being “right” in a failing project is not a great outcome.
What’s my conclusion? I found two interpretations for Josh’s reaction. They are both valuable; I resolved to talk to Josh further, to see if there is anything else behind his words. And I resolved to discuss the issue of priorities with the POs.