Help Center | Print Page | Sign In | Register
AgileCareers Blog
Blog Home All Blogs
Get the latest news on AgileCareers! AgileCareers.com is dedicated to connecting Scrum and Agile organizations with qualified, passionate Agile professionals. We strive to Transform the World of Work by offering a platform that has the resources and technology to help build those professional synergies.

 

Search all posts for:   

 

Top tags: agile  hiring  scrumpractices  agilepractices  interviews  job posting  scrummaster  leadership  scrum  talent  talent acquisition  bonus  compensation & benefits  culture  digital age  employee engagement  eyholzer  future of work  HR  human resources  learning  people operations  practices  principles  product owner  Recruiting  reward  Technology  transformation  values 

Can the Scrum Master also be the Product Owner?

Posted By Meghan Robinson, Thursday, June 30, 2016
Updated: Tuesday, June 28, 2016

AUTHOR: JEREMY JARRELL

If you’ve experimented with scrum, you’re likely familiar with the Scrum Master and Product Owner roles. But just in case you’re not, here’s a quick breakdown: The Scrum Master is responsible for ensuring that the team follows the Scrum process, while the Product Owner ensures that the team spends time building things that bring the most value to the organization. These roles sound so deceivingly simple that sometimes a single person will try tackling both.

This can happen in a ground-up implementation of scrum when a Product Owner is never officially assigned to the team, leaving the Scrum Master to fill these responsibilities. It can also happen when the team’s Scrum Master is also an individual contributor, and simply too overwhelmed to focus on the scrum process. In these cases the Product Owner may try to step up to lead the process, in addition to their own responsibilities.Regardless of the reason, when a team attempts to combine all responsibilities into a single role, it almost never ends well. Let’s look at some of the ways this can go awry, and how to fix it.

Scenario 1: Scrum Master acts as Product Owner

Most commonly, when these roles are combined, it results in the Scrum Master also wearing the hat of Product Owner. While it sounds logical, the Scrum Master may not have access to the customers to gather valuable feedback. Without actionable feedback, the team simply breaks an un-validated product down into smaller and smaller pieces delivering each incrementally. While incremental delivery is an improvement over a single large delivery, the reality is that it’s really just a more efficient way to deliver the wrong product.

When the Scrum Master acts as Product Owner, it’s easy to miss out on a coherent vision for the team, resulting in the delivery of low-value work. This can happen when the Scrum Master, lacking customer access or a true vision for the product, simply stacks the backlog with the items they find most interesting or familiar. This results in the team dusting the app by making minor enhancements to existing features or cleaning up low-priority bugs, but not accomplishing any meaningful work. In this case, low-value shouldn’t be confused with low-quality: While the team may be producing high-quality work, it doesn’t mean it’s making a meaningful impact on the product.

Scenario 2: Product Owner acts as Scrum Master

Product Ownership is a full-time job. This means that it’s easy for responsibilities outside of this role to slip. When the Product Owner acts as a Scrum Master we usually see the less tangible pieces of the scrum process slowly start to wane. Retrospectives are often the first casualty, as their outcomes can (incorrectly) seem less relevant to a busy Product Owner. While the Product Owner may not officially cancel a Retrospective, they may view it as most relevant to the development team and, therefore, leave the scheduling to them. These meetings appear unimportant to the organization and eventually die out.

Alternatively, the symptom may not be as blatant as a missed meeting. In some cases, regular meetings will still occur but you’ll start to notice that their focus subtly changes. For instance, daily standups still occur but rather than acting as a chance for the team to plan their work for the day, they slowly morph into a status meeting in which each team member reports their progress to the Product Owner. Likewise, sprint-planning meetings will still occur, but rather than the team arriving at estimates and a sprint plan together, they may find themselves bullied into uncomfortable commitments as the result of  an overzealous Product Owner.

How to fix it

Both Scrum Master and Product Owner, for the most part, are full-time jobs. When the same person attempts to fill both roles disaster almost always ensues. In the cases where the Scrum Master is filling the Product Owner’s responsibilities, the simplest solution can be to free the individual of their Scrum Master responsibilities, allowing them to focus on the Product Owner role entirely. Many Scrum Masters eventually gravitate toward the Product Owner role and, as of late, this has become a very popular career progression for those with a taste for Product Management.

Keep in mind, however, that your team still needs a Scrum Master. This is your opportunity to identify a team member who’s up for the challenge, and coach them into their new role. If successful, you’ll have a new, dedicated Scrum Master, brought up from within the team, and a new dedicated Product Owner with a background in the scrum process. That’s a pretty big win.

In situations where the Product Owner acts as Scrum Master, the solution is to find a new Scrum Master who can dedicate time to the role. Not only does this free the Product Owner from managing the Scrum process, but it also helps create healthy tension between Scrum Masters and Product Owners. Ideally, the Scrum Master and Product Owner act as opposing forces. While the Product Owner represents the interest of the customers, the Scrum Master represents the interests of the team. When a single person tries to fill both roles, this healthy tension is lost and the fulcrum inevitably tips too far in one direction.

This is often seen when the Product Owner attempts both roles, as the fulcrum may tip toward bigger feature sets and a rush to market, which not only sacrifices the team’s investment in quality, but can also take a toll on their overall well-being. Freeing the Product Owner to focus entirely on product ownership, while allowing a completely different individual to focus on the scrum process, helps restore balance and better serves the end result.

Takeaway

There are exceptions to every rule, and it is possible for one person to serve both roles successfully. Just keep in mind that this isn’t the norm, nor should it be a long-term solution. To give your organization the best chance for success when using scrum, allow two distinct individuals to serve these roles. Even if you’re struggling to find those with the right aptitude, you’ll be better off with two people who have a passion to grow into their respective roles, rather than one exceptional individual struggling to balance both.

Want to learn more about how agile really works? Check out Jeremy’s course, Agile in the Real World, for concrete strategies on making the best agile techniques work for your team.

This article was originally posted on PLURALSIGHT.

Tags:  Agile  product owner  scrummaster  scrumpractices 

Share |
PermalinkComments (0)
 

Product Owners and Scrum Masters: Partners in Adversity

Posted By Meghan Robinson, Tuesday, May 24, 2016
Updated: Tuesday, May 10, 2016

AUTHOR: ADAM MYHR

Despite their differing priorities a Product Owner (PO) and Scrum Master (SM) must be on the same team. More specifically, in a successful scrum team the PO must be a partner to the SM. Their adversity comes from the roles they play. The sentiment applies equally well to Agile Project Managers and Agile Coaches. That said, framing it in the context of Scrum makes the narrative easier.

Tug Of War Between Two Girls Stock Photo

meepoohfoto – FreeDigitalPhotos.net

The PO is beholden to the customer or end-user as well as the business. Their main function is to maximize value delivery. The SM is beholden to the team. Their main function is ensuring and enacting scrum through servant-leadership of the team. With no SM a PO might very well burn a team out by requiring too much of them. Without a PM a SM might hinder value delivery by shielding the team from more than they should or allowing more experimentation than the business can support. Hence a partnership must form between the PO and SM for a successful team to emerge. The adversity arises due to the difference in priorities between these two roles.

The PO and SM have to work together to find the right balance between pushing the team for higher performance and sustaining the team for long-term endurance. Together they need to know what level of change is tolerable by the organization, the user, and the team at any given point. Using this knowledge, they need to decide how much time the team can spend on self-improvement versus value delivery every iteration. In a solid partnership they might be able to discover ways to accomplish both improvement and value delivery at the same time.

Just as changing around a development team causes a reset of the teams developmentchanging the PO or SM does the same for their partnership. Having multiple PO’s on a single product exacerbates the problem, and is a bad practice to begin with. The PO is supposed to be the one and only person who can speak to what the most important deliverable is at any time. If there are multiple people trying to fill the role there will inevitably be a time where they disagree, potentially causing confusion when the SM is looking for clarification or guidance. Similarly, a dedicated SM can establish a relationship with the PO and continue through storming and norming to performing. Choosing to instead rotate the SM role among team members can result in that relationship never progressing beyond the storming phase.

When a PO and SM are on the same page it becomes easier for the team they are on to deliver the best value possible. If they are at odds then their conflict itself will become a value blocker for the team. Keep both roles dedicated, on the team, and in a partnership for the best outcome possible.

This article was originally posted on ouragilejourney.com/

Tags:  product owner  scrummaster 

Share |
PermalinkComments (0)
 

AgileCareers is dedicated to connecting Scrum and Agile organizations with qualified, passionate Agile professionals. We strive to Transform the World of Work by offering a platform that has the resources and technology to help build those professional synergies.