Skip to main content

Mixing Product Owner and Scrum Master roles

The Scrum Guide says that the Product Owner and Scrum Master roles should not be played by the same person. Given below are some reasons why this is not recommended in Scrum and the possible consequences of not following this recommendation.

- Conflict of interest - The two roles may have conflict of interest in certain situations. Product Owner is concerned about maximizing the RoI and Scrum Master protects the team from external distractions and helps remove impediments. Scrum Master works closely with the team in doing this, and the product owner provides the customer perspective to the team.

- Bad mix - If the same person plays both the roles, the scrum master role can take a back seat. The person playing both the roles may find it very difficult to balance the needs of the customer and the commitment that the team can make. It is highly probable that s/he may burden the team with ever-so-frequent over-commitment of results and intra-sprint scope changes. This in turn can impact the team results and morale.

- Bandwidth constraints - It may not be possible for one person to play both the roles due to lack of time. Product Owner role requires understanding the needs of the business. Depending on the project landscape this can become a very time consuming activity leaving little or now time with the person to help resolve team impediments.


Issues:
- What if team size is small: For Scrum the ideal team size in 5 to 9. But for any reason, even if the team is smaller than 5, it would still be better to have different people playing the two roles than letting one person play both the roles. In this situation, the role conflict becomes even more apparent.

- What if organizational structure does not provision for a Product Owner role: Different situations warrant different solutions. For example, the Product owner could come from IT or Business. There could be a proxy Product Owner within the team who interacts closely with the Business or Customer. Since the Product owner takes the ownershiop of the priorities (and thereby the project direction), it is important that s/he has the ability and the authority to say "No" when required.

Comments

Popular posts from this blog

14 Essential Software Engineering Concepts for Engineers and Managers

There are many terms and concepts that are important for an engineer to be familiar with, in order to effectively build software. This post includes some of those terms. I will continually add to or update this list. Agile. A flexible and iterative approach to software development that emphasizes collaboration, customer feedback, and adaptive planning. My experience and success with agile development was the inspiration behind starting this blog. DevOps. A set of practices and tools that improve efficiency, speed, and reliability of the product through automation and optimization of the software development and delivery process where operational efficiency is part of the development process. Continuous Integration and Continuous Delivery/Deployment (CI/CD). A set of practices and tools that result in faster and more frequent releases, through automation of building, testing, and deployment of software. A key part of CI/CD is to deliver software to production frequently and using tec...

Forget Onboarding, do Alongboarding!

Alongboarding, an agile onboarding approach Alongboarding: We’re in it together! Organizations hire new people every day. A great first impression can make a tremendous difference in retaining employees. No one gets a second chance to make a great first impression, not even the best companies. An onboarding experience is an essential part of making that first impression on a new employee. Agile has been around for many years and has gained vast acceptance throughout the community. Yet, I find it disappointing that its tenets are not used well in most companies and most onboarding approaches follow a waterfall approach.  Alongboarding is an agile onboarding approach that applies agile tenets to onboarding new employees and makes the experience richer and more fulfilling. When I joined AppFolio as an agile coach, I experienced this approach during my onboarding. It felt like the team owned my success as much as I owned the team's success. It was a welcome change from some of m...

Make onboarding fun with Onboarding Canvas!

The Onboarding Canvas is a tool that can be used for onboarding a new team member . We derived this tool from Spotify's adaptation of the Toyota Kata . I like this tool because no one can tell you precisely how your onboarding should be like in order for you to be effective at your new job. This is a tool for continuous reflection and adaptation. It puts the newcomer in the driver’s seat, makes the onboarding process agile through continuous collaboration with your team. Four quadrants The onboarding canvas has four quadrants: Now: It defines where the team is now, what is going on and how is the new team member adapting to the change? Definition of awesome: With the addition of the new team member, how would the team like itself to be? What would be awesome for the new team member? Next target: In order to move towards "Definition of awesome" what outcomes should be achieved in the next x weeks? Next steps: What are the immediate next steps for the team...