The question was recently posed to me – What conflicts occur if the Scrum Master is also the Product Owner?
This can be seen as a workaround for not getting a dedicated Product Owner, which is dangerous as the key issue of not having anyone in a critical role is not being addressed.
There are many conflicts that will arise, the main ones I see are below:
a) Internal conflict within the individual – The Product Owner is focussed on getting value to flow through to the customer (usually through a deeper or richer feature set) and the Scrum Master is the sheepdog managing the framework and getting the team to achieve at higher level (better quality, more self-organisation, higher degree of cross functional skills, better engagement with the business). At times there will be a natural conflict between these two perspectives. This will cause an internal struggle within the individual when trying to balance these tensions. Within a young team, there is often an urge to focus on velocity, not extending the definition of done. This will result in technical debt and a slower long term velocity. This is where the Scrum Master would counsel the lower velocity for the long term outlook, whereas the Product Owner may be comfortable with the initial burst in velocity unless they understood the ramifications. Hence the reason that they are stated as 2 separate roles.
b) Time conflict – These are two full time roles, and having one person doing them will result in neither role being performed well. The context switching in the attempt to change between roles would incur waste. It would encourage the multi role person to not maintain a sustainable pace, leading to burn out.
c) Conflict between the Development Team and the Multirole Individual – In a manner similar to when I am training, when the Development team approach the SM-PO, they would need to clarify which persona they are talking to. In one conversation they may get contradictory
. It is very difficult to clearly separate the two perspectives in the one individual – we just aren’t wired that way. This results in a lack of clarity of the perspective (either PO or SM). There is a very high probability that the individual would slip between the roles, and may eventually not even be aware of the boundary. The confusion from this would result in stress within the Development Team as they have lost capacity of their Scrum Master Shield to protect them from the various demands on the time. The poacher and the game keeper are the same person.
d) Team Imbalance conflict – there is too much responsibility resting with one individual. The trinity works to balance the competing stresses and demands on the team – having only two roles available at any one time means there is an imbalance – resulting in vacillation, variation of decisions, and not all the conversations taking place and perspectives taken.
The image above shows a balanced perspective from the three perspectives of the scrum roles, which results in balanced discussions.
The imbalance is highlighted in the extreme, with a blurring of the perspectives, potentially resulting in only two of the roles being represented. This results in an imbalanced discussion – and not the full spectrum of conversations and view presented.
A tripod doesn’t stand too well on two legs!
e) Stakeholder engagement with Team – Due to the dual nature of the multirole individual, then uncertainty from the stakeholders/customers on the interaction with the Team would arise, for the same reasons as the Development team and multirole individual engagement.
Hey – We have that, what do we do?
The only thing to do is separate the roles to different people. All three roles are critical for successful scrum, and it will eventually cause a lot of friction.
First option is to get a dedicated Product Owner to represent the customer, and a dedicated Scrum Master to manage the framework. If there is an argument that neither is a full time role, share the role across teams. It is a compromise, but better to compromise than embrace a dysfunction!