According to the scrum theory, there are a limited set of roles within the framework: product owner, developer, scrum master and stakeholders. Of these roles the first three fall within the scrum team, and only the developer role and scrum master role can be found within the development team.
Sometimes in discussions the question does pop up whether you could actually assign multiple scrum roles to one person. My answer is that some combinations can work, and others are better not to combine. In my personal situation, I’m both a scrum master and developer within one team, and that is sometimes a bit complicated, yet I can make it work and wouldn’t want to have it otherwise (too much of a hands-on tinkerer I guess; INTJ if you’re interested).
Within this article I’d like to tackle why I think that you shouldn’t combine the developer and product owner role as one person. I’ve based my arguments on what others are also saying about the topic, looking at it from various perspectives.
Conflict of interest
The first thing I’m tackling is the conflict of interest that can arise between the product owner (PO) and a developer; the PO wants something done as fast as possible, and the developer wants it done good (I hope).
It is possible that a developer also acts as a product owner but I don’t think that it is recommended. Here are my 2 main reasons:
- It may create conflict of interest
- It will drag down your output as a developer PO has to prioritize the backlog (the what part) where as the team decides amount of work that can be delivered in each sprint (the how-much part). Similarly PO provides feedback on the sprint during sprint review meetings and decides to approve or reject the sprint which has been delivered by the team thus causing conflict of interest.
Being a PO needs frequent engagement with both the client and the team so that everyone has aligned vision of what needs to be delivered when. PO has to be available to answer questions coming from the team. If your time is divided between engagement and development it is bound to have a negative effect on efficiency for both dev and PO roles.
Aziz Shaikh mentions here that the PO represents the customer, and being both developer and customer can create issues.
An other angle to look at it is from ownership of technology, here’s what Nik Makepeace has to say on the same topic on Quora:
You would be denying your development team code ownership, because your technical arguments would hold undue sway simply by dint of your position as PO. If you totally subordinated your technical opinion to a tech lead, and acted merely as a gun for hire on the delivery team, then you would be denying your team of a technical voice. And anyway, could you, really, be a developer without expressing any opinions about the what you were developing?
You’re in essence becoming a lead developer - which isn’t a scrum role - within the team, and making decisions for the team. The product owner shouldn’t make those decisions, he/she should focus on what needs to be built, not how it should be done. The team might come up with a complete different solution than you as PO could think of.
Having the time to do your job well
In Scrum there’s nothing to stop a PO from also being a member of the Development Team.
There are risks to combining the roles, including the potential lack of time to do both jobs properly. The Scrum Master may also struggle to represent and defend the interests of the Development Team when the PO is also a member of that team.
And Ian Mitchell continues…
Of course there are also potential benefits, including the on-hand availability of the PO to the team, and perhaps a clearer demonstration of having skin in the game.
I think it is a very positive advantage is the PO knows about the technical challenges that a team phases, such as keeping up with security issues in the used platforms or with new versions of frameworks. This in order to take it into account in the backlog.
Yet could a developer be a product owner and do a good job in both roles? Based on the above I highly doubt that.
P.S. If you’ve enjoyed this article or found it helpful, please share it, or check out my other articles. I’m on Instagram and Twitter too if you’d like to follow along on my adventures and other writings, or comment on the article.