A Developer Can’t Be the Product Owner
The Product Owner on my team is also a developer on the team. Do you have any advice on using Scrum in such a scenario?
LONG ANSWER: In a healthy Scrum Team, each person fills only one Scrum role at a time. Having someone be both a Product Owner and a member of the Team, i.e. a developer, is not allowed because combing two roles into one person violates commitment, a core Scrum value, as well as reduces the Scrum principles of focus and accountability.The Product Owner has a crucial responsibility to understand the needs and priorities of the product from the Stakeholders and communicate this information to the team. The Product Owner spends the majority of their time working to understand “the what” – what sort of outcomes are desirable to the Stakeholders, what are the priorities, what are the various trade-offs that need to be made for the product to be an economic success. In my experience, defining “the what” is more than a full-time job for most Product Owners.
Team members, on the other hand, have the responsibility to decide how these outcomes will be implemented in the product. All the various outputs associated with software development – designs, requirements, features, tests, estimates, acceptance criteria, etc. – fall within the control of the self-organizing Team and define “the how”. Again, in my experience, mastering the details of “the how” is a full-time job.
When the Product Owner is a developer on the Team, they are not fully committed to being the Product Owner or being a Team member. As a result, neither role is fully inhabited. This usually results in crappy products, dissatisfied Stakeholders and unhappy Team members. Because this person exist in two worlds, the focus of the developer acting as Product Owner is divided between setting business direction and making technical decisions. This violates my general guideline (based on the Planning Game) that on software teams, business people make business decisions while technical people make technical decisions.
Additionally, accountability in this scenario becomes extremely murky. When the Product Owner is also a developer, are they making business decisions that are best for the organization or just best for the technology? Or are they making technical decisions that limits the Team’s self-organization and commitment to the best technical solution? I am not looking to find the single-wringable neck (Agile Bob is right – this is another concept that needs to die), but we need to ensure that role owners are staying within the boundaries of what is described in Scrum. When the developer and PO roles are blended, it is really hard to tell if that is happening so it is best not even to go down this path.
In the end, this scenario boils down to a lack of prioritization and courage within the organization. If the organization is committed to doing Scrum well, they need to prioritize the importance of finding the right person to fill this role If not, someone needs to have the courage to say, “Being the Product Owner is a crucial role for our success with Scrum. It is not side job for our developers and we are not going to use Scrum until the business provides us the right person to do the job.”