Can a Product Owner be a developer in Scrum? In theory, yes, but is it recommended by Scrum?
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.
- closely collaborate with the team on an ongoing basis to guide and direct them
- manage the product backlog
- answer questions asked by the team
- provide feedback
- sign-off work results
This is a lot of work for a PO which would require undivided attention. For highly aligned and high performance teams, Scrum Master role may need less amount of time but a PO will still have to spend similar amount of time regardless.
While the Scrum Guide does not explicitly state whether the Scrum Master or Product Owner are, or are not part of the development team, they are part of the Scrum Team:
The Scrum Team consists of a Product Owner, a Scrum Master, and the development team.
Which infers that both the Product Owner and the Scrum Master operate outside of the development team.
Further, the Scrum Guide also states:
Scrum’s roles, artifacts, events, and rules are immutable and although implementing only parts of Scrum is possible, the result is not Scrum. Scrum exists only in its entirety and functions well as a container for other techniques, methodologies, and practices.
The Product Owner is also responsible for a lot of administration and backlog grooming, again from the Scrum Guide:
The Product Owner is the sole person responsible for managing the Product Backlog. Product Backlog management includes: Clearly expressing Product Backlog items; Ordering the items in the Product Backlog to best achieve goals and missions; Ensuring the value of the work the Development Team performs; Ensuring that the Product Backlog is visible, transparent, and clear to all, and shows what the Scrum Team will work on next; and, Ensuring the Development Team understands items in the Product Backlog to the level needed. The Product Owner may do the above work, or have the Development Team do it. However, the Product Owner remains accountable.
Based on the preceding information, I would say it is not recommended - and, if you were to do so you would not actually be doing Scrum (according to the document maintained by the founders). Having said that, is that inherently a bad thing - no, you just shouldn't call it Scrum.
Unfortunately not. A good product owner has a lot of coordination work with customers, support, management which takes a lot of time (and meetings). Therefore only a small amount of time remaining for development work and being with the team. Plus this small amount time will be interrupted by users, customers, managers, meetings anyway.
Additionally, if the product owner knows too much about the implementation details, he can drive the team to a certain technological direction and may be less open to other suggestions.
Product ownership requires a different kind of mindset. Even if one has a PO and a developer mindset, switching between them takes time and a huge effort.
Some answers are refering to the Scrum Guide when they say no. However, according to that reference I'd say it would be no problem for both the SM and the PO to develop, given the right circumstances:
The Product Owner and Scrum Master roles are not included in this count [the development team size] unless they are also executing the work of the Sprint Backlog.
Yes. PO is a hat just like any other. The only precluded combination is PO and Scrum Master.
Edit Knowing that the community would be vehemently against me here, I short-circuited the length of my answer as I didn't really relish the idea of yet another argument with a Scrum zealot. To them I will say this: the Scrum guide is very explicit in saying that it is very explicit (see the quotes in Josh Bruce's answer for evidence). The Scrum Guide very specifically does not ever say the PO cannot be a member of the Development Team.
That being said, if you're PO is only occupied 20% of the time and is a fully qualified developer do I really care if your going to make me stop saying I'm doing "Scrum" while I continue to deliver value to my customers? Nope, not in the least.
The Product Owner is responsible for the economics of the product. As long as he/she is fulfilling that role and their work in process is controlled, I see no reason why they shouldn't grab a keyboard.
If you're looking for anecdotes, I'm both a PO and developer/architect for a team. This is more out of necessity than choice. Personally I find it rather difficult, because it means I don't have an opportunity to provide the appropriate level of PO support that my team deserves. I am not able to devote 100% of my time to development and I'm not able to devote 100% of my time to being the product owner, so both roles suffer.
OTOH, my team is highly productive, arguably the most productive and happy team in the company. So, as a team we're able to make it work. At the end of the day, that's what matters most, right? A truly self-organizing team will do what it needs to get the work done.
That being said, I don't recommend trying it unless you have no other choice. As productive as my team is, I like to think we would be even more productive with a full time PO, whether it's me or someone else.
Let's look at the spirit of scrum
1) Focus on how to help, not on your "job"
2) Iterative Retrospective, to Change and Adapt.
So you can try it, and see how it works, reflect on it, and decide as a group if it is beneficial. Remember that the role of the Product Owner is to organize the backlog and provide direction, so ensure that is happening effectively and you should have no problems.
I can say that I run scrum independently on solo projects all the time. Is it some kind of blasphemy that I'm a team member, master of ceremonies and product owner? They are 3 distinct roles, but I just make believe that I'm 3 people and I do them all myself.
People who answer no are just zealots, the process defines flexibility and adaptation. You can do whatever suits you, which changes in situation to situation. You should try to make your first sprint pure, but after that the retrospective is meant to invoke improvement and change.
No of course the PO cannot be a developer and vice versa. Scrum is all about roles and different point of views on the same vision or goal. Additionally the task to be done by a PO are totally different to the task to be done by a developer.
To provide a good product it's good that team is challenged (I think that's why it's called Scrum) by the PO and vice versa.
By providing feedback the team can also make the PO to think about the product or about the features he wants to have implemented. So due to the different point of views all participants are evolving. If a PO would also be a developer you would not use this effect.
The PO usually has other responsibilities but of course if they believe they can make a contribution as a member of the dev team then hopefully the team will welcome their input. One risk is that the flat self-organising structure of the team may be compromised by having someone who may be seen as "first" among equals. I think a good PO would want to make a clear distinction between the times when they have their PO hat on and the times when they are working as just another developer on the team.
After thinking about this some more, I would say simply: "The answer is no."
The PO is the liaison between the business and the team, representing the business's perspective on what is going on (as an "input" to the team), as well as communicating status to the business (as an "output"). And that needs to be their full-time occupation. If you try to "also" be someone who writes source-code, you really can't hold on to that objectivity. When you're writing source-code, you inevitably begin to see everything in terms of source-code, and that's really why PO is formalized as a separate role.