In the scrum world there are various roles. There are team members, a scrum master, a product owner and stakeholders. Each of these have their own specific aspect to deal with and all serve a distinct purpose. Obviously, it’s pretty essential that each of these roles is filled with people…and that’s where it gets tricky.
Often, there is no straightforward mapping between a role and a person. I’ve written my vision on good product ownership earlier on this blog, and even though over time I may have changed some of the accents I still stand by what I wrote back than. Let it be clear I was writing about the role of a product owner… . I think you’ll find it very hard to find a person with the right blend of capabilities. So let’s open up the question: “Should we have not one product owner?”
I’d like to argue that you need at least 2 people doing this. (not necessarily 2 full-times). One person who is more aware of the technical side of things (let’s call him the technical owner) and one person who is better at the business side (business owner). Somehow it is very hard to find a combination of these 2 in 1 person.
Now I can see all of you wonder:”That doesn’t jive very well with the concept of a single wringable neck”. And indeed, it doesn’t at fist sight. The problem with this definition of single wringable neck is that it is founded on the principal of accountability. The product owner (part of “the business” in the strict sense) needs to step up, deal with stakeholders and direct the team. He is accountable, he needs to step up. The fact it is “single” is because that makes sure that this person can’t hide behind others. He and only he is accountable for the project. Now there’s a pretty heavy burden
. I like to believe that part of this movement for accountability of the business is based in the dark and evil times where engineers were making decisions based on their interpretation and afterwards pretty much shot in the head for taking the wrong decision. (it happened to all of us, I’ll explain some other time why engineers shouldn’t make business decisions most of the time)
Either way, the accountability movement explains the single, let’s not get stuck on that. I believe that a team of 2 can be held equally accountable than a team of 1.
Since product ownership is a role and not a person let’s take a look at combining jobs. Earlier (on my old blog) I argued that product owners shouldn’t have another job. This is one of the areas where I have refined my ideas in the meantime. I can see cases where it would be possible that a product owner (technical owner) goes head first in a discussion with the team on architecture or feature design. Even though, strictly speaking, product owners (the role) shouldn’t get involved in dictating implementation detail, having your product owner (technical owner person) guide you might be very beneficial for both team and owner. The owner will better understand the system and the tradeoffs made, the team will probably better understand the requirement and direction that the business wants to take. It really all depends on the skills you have available within the people.
Summarizing
- Having 2 product owners is often a compromise born out of necessity for mapping an extensive role to people with the right mix of skills
- It doesn’t go well with the “single wringable neck”, but that statement needs to be seen as a child of its time. It’s about accountability of the role, not about the singleness of the person
- Making optimal use of the skills of every person can perfectly well lead to a bit of fuzyness and combination of certain roles (or parts of them)
In the end…Agile, much like the pirate code, is not a strict code but more a set of guidelines. In the end we’re dealing with people, not with roles. The roles only help us grasp the concepts. Agile is still about common sense.
FYI: Most Pirate Captains had a sidekick/right hand man that dealt with the business aspect of it all (e.g. Smee compared to Captain James Hook) … so your statement surely does make sense