Technical Product Owner

June 2, 2009

So here’s the problem: Some teams have stories that are very “technical” in nature. By technical I mean that these stories are usually development oriented (in language, and in subject matter) and they are hard to relate to direct customer value. Often these stories are related to maintenance activities that have a strong perceived need to be done by various stakeholders, but are not explicitly requested by our external customers. Some examples include:

  1. Stories requested by operations
  2. Stories that have to do with infrastructure improvements
  3. Stories related to technical debt

In some cases product owners have a real problem working with these stories. They complain that the stories refer to technologies or acronyms that they don’t understand. They maintain that they are a customer advocate and don’t care what the details are – just fix it. They don’t know how to judge when these stories are done.

To address this problem we have created a sub-category of product owner that we call a “technical” product owner. If you are starting to feel a bit squeamish at this point, I don’t blame you one bit. So who is a technical product owner? In this case it is usually the development lead for the team – or perhaps a director of development.

The solution is a well intentioned one, but there are consequences. The problems with using a “technical product owner” that I see in practice:

  1. The technical PO has no connection with the rest of the Product Management/Business/Customer organization. This basically sets the team up to operate without having to deliver value that the rest of the organization recognizes. It seems to aggravate silos within an organization.
  2. The Product Management (PO) team gets to ignore important decisions regarding the maintenance and upkeep of business systems. When you buy the car, you need to be responsible for it’s upkeep. All too often I know PO’s who refuse to address technical debt when it is brought to them. Instead they prioritize new features higher – sooner or later it comes back to haunt them.
  3. Teams get out of the habit of working with user stories that customers can relate too. Or they take perfectly good user stories and break them down into “technical stories”. There are all sorts of reasons this happens to teams – but we don’t want to codify the practice by creating a special “technical PO”.
  4. It can reflect an organization’s unwillingness to organize projects that are aligned across the organization rather than within technical silos.

Personally, I think that we should be able to put all stories – regardless of where they originate into terms that anyone can understand. Failure to do that may lead you down a path that leads to the “Technical Product Owner”. Watch out.

Trust Your (Bleep)ing Team!

July 20, 2008

Here is an issue that has come up over and over again – scrum masters and product owners that don’t trust the teams they work with. I’ve struggled with this problem myself over the years, so I can definitely relate to the mistrust. Here’s my favorite example:

Sandbagging: The team is not delivering 100% of their stories each sprint. The team is not pulling as much work as you would expect each sprint. Everyone is coming in late and leaving early. No one is staying late nights to make sure that stories are absolutely done before the end of the sprint.

There you are as the Scrum Master, tearing your hair out in frustration, trying to figure out how to get the team to step up and deliver. Well, if this goes on for very long, you end up not trusting the team. After all, their commitments seem to mean little, they just go through the motions, etc. Of course, here’s a news flash – they don’t trust you either. In my experience, teams can almost always read you like a book. They know it when you don’t trust them. They know it when you think it’s “their” problem. They aren’t stupid. This just further increases the sense of alienation between the two sides. It further limits your ability to be an effective member of the team.

I think that often times when we get to that place of mistrust we are doing something very fundamental and very destructive to the relationship with the team. We are making the problems, what ever they may be, someone elses problem. It’s the team’s problem, not yours. It is something that is inherent in their nature – they are somehow flawed. If they would just somehow, “Get it” then our problems would be solved. Of course nothing could be further from the truth. The fact is that everyone plays an important role in this dance of trust. If you really want to address the problem, you have to be ready and able to take responsibility for your part in the problem. Because as scrum master or product owner, you are part of the problem, like it or not.

So what is the solution to this problem? Trust your (bleep)ing team! That’s right, get that mistrust monkey off of your back – take it from me, that particular simian has nothing constructive to offer. Let the team know that you trust them completely – 100%

You’re never going to make significant progress as long as you and the team distrust one another. Guaranteed.

Then start looking for the impediments that are holding them up. Maybe the first and most difficult impediment to remove is any mistrust we may have with the team.