Product Owner or Scrum Master

Share!

It is common to meet people who are both Scrum Master and Product Owner certified. As confusing as it may be to me, it's not uncommon to talk - in person or through social media - with people who for some reason have been certified as both Scrum Master and Product Owner. Does it make any sense to try to specialize in both roles? This article presents arguments to understand the difference between the roles and how you can support your growth as a Product Owner or Scrum Master.

The first and most important thing is to define which role is best for you. And the answer is: depends. Of course, as a good consultant, the most common answer I give is "it depends". Although if you've read my previous articles, you know that I don't like middle ground and I like to provide some insight to people who are still undecided or confused about the Scrum Master and Product Owner roles.

Here's some key information to help you distinguish between the two roles and better understand the potential of each. Moreover, if you're thinking about strengthening your capabilities or hiring someone in either role, this article is sure to be very useful.

Scrum can do anything

Although Scrum is very good, it breaks me a bit to see that they try to apply Scrum everywhere - a bit "a la maldita sea" would say a Colombian like me.

Scrum is not new and is very similar to its agile cousins and brothers. An iterative management model that, through certain activities and roles, promotes, among other things:

• Alignment
• Transparency
• Better communication

However, in our time - as with all fads - Scrum is our new "Maslow's Hammer".

Scrum: Maslow's New Hammer

Maslow popularized this idea, also known as "The Law of the Hammer" or "The Golden Hammer", in his book The Psychology of Science published in 1966 that said something, more or less like this:

It's easy to assume that if the only tool you have on hand is a hammer, you can treat anything as if it were a nail.

Abraham Maslow

Scrum Master: The Almighty

In this sense, if Scrum can do everything, then the Scrum Master must be a lucky one. Dungeon Master whose power is unlimited.

In my opinion, it is quite the opposite. If your dream is to become a Scrum Master, the first and most important thing is to understand the power of the role, the opportunities it represents for you and, of course, the context in which it puts you.

So let's take it one step at a time.

What does a Scrum Master do?

Although the Scrum guide is, IMHO a poor and ambiguous document with little content, let's use it out of respect for the fathers of the model - who unlike their guide that looks more and more like a pamphlet, have dedicated their lives to interesting things and outstanding projects.

Scrum Master as ambassador

So, let's break down the description of SM in the Scrum guide:

The Scrum Master is responsible for^[1]The translation of accountable by responsible not only seems inappropriate to me, but it can also confuse the reader. That is why it is important that you reflect on the differences between what "responsible" and "accountable" mean. to establish Scrum as defined in the Scrum Guide. They do this by helping everyone understand the theory and practice of Scrum, both within the Scrum Team and the organization.

Taken and translated from the Scrum 2020 guide - https://scrumguides.org/scrum-guide.html

In short, the SM is an ambassador of the model. Something similar to the PMBOK fan boys of a few years ago who went around with their inputs and outputs, their processes and tools as if there was no tomorrow and nothing beyond the standard.

The SM is then circumscribed to the Scrum Team and the organization where that team works. So, if your dream is to lead many teams or large groups, be an IT manager or something "a bit broader", being SM is not going to get you there.

Opportunities for SM as an ambassador

1. Nowadays there are many job offers for Scrum Master - although it is not clear what they expect from the role, all or almost all of them demand a current certification.
2. It is a role where you can develop your people skills and improve your negotiation and conflict management skills - on a small scale.
3. The Scrum framework - and more so the Scrum Guide model - is a childish and innocent read. You don't need years of study to understand the role. The agile community is very active all over the world and you will certainly be able to join groups where you can discuss, learn and experiment.
4. It's a broad role and, if you're passionate about it, you can expand your skills beyond Scrum, into managing teams and motivating people.

Risks of the SM as an ambassador

1. The Scrum Master is confined to the Scrum Team within an organization. If you have ambitions to grow or have more power - like leading an area or large teams, the SM does not leverage you for those roles. Even their small-scale thinking can be a real hindrance if you want to lead a large team - I'm talking here about many people, tens or hundreds.
2. If you like to have control over requirements or work, you are definitely going to suffer as a Scrum Master. You are not a boss, you are a facilitator, some even talk about "catalyst".
3. If you need more than Scrum - which you probably do - an SM course or certification is half of the first step. Unfortunately many courses and certifications only explain the guide and do little or nothing to help you with the experience.
4. It's a broad and somewhat generic role. If you're not passionate about facilitating and supporting, you're going to learn a lot of things that the guide doesn't help you solve in your day-to-day work.

Scrum Master builds on an open framework

The Scrum Master is responsible for the effectiveness of the Scrum Team. He achieves this by enabling the Scrum Team to improve its practices, within the Scrum framework.

Taken and translated from the Scrum 2020 guide - https://scrumguides.org/scrum-guide.html

Well, the Scrum Guide is, as I've said several times, somewhat simple... rather incomplete.^[2]And it's not just me saying that. The 2020 guide itself says: "The Scrum framework is purposefully incomplete, only defining the parts required to implement Scrum theory". For many it can be wonderful. For others, a real headache. Somehow you have to fill in the blanks. So if you have a lot of experience, Scrum is an excellent base file, if you don't, you are lost in the space of ambiguity and "nice ideas".

FS opportunities within an incomplete framework

1. Not having a prescriptive framework is good and avoids "trolls" who try to do everything "by-the-book". At the same time, it expands the potential scope of the framework to projects beyond SW - where Scrum was originally created.
2. Empirical thinking is powerful if taken seriously. Empiricism is not synonymous with "improvisation".

Risks of SM within an incomplete framework

1. If you're just starting out, not having a detailed framework is a headache. The challenges and problems you will face will require a lot of study on your part and, in many cases, support from experienced people.
2. Empiricism is quickly confused with improvisation. Don't be seduced. Even if the agilistas radicals hate predefined recipes, sometimes to learn to be a great chef it is necessary to learn a few recipes from the drawer and then, give them your particular and special touch - I recommend you to take a look at the concept Shuhari.

What is the purpose of the Product Owner?

The Product Owner is responsible for maximizing the value of the product resulting from the Scrum Team's work. How this is done can vary widely among organizations, Scrum Teams, and individuals.

Taken and translated from the Scrum 2020 guide - https://scrumguides.org/scrum-guide.html

The PO, as you can see, has a fundamental role in delivering value. I have always thought that the role of the PO is easily confused with that of a business analyst or even a "documenter". And, although they share some basis they are not the same.

Maximizing product value means that the Scrum Team's work has a clear focus on results and business benefits. And this involves incremental thinking.

The Product Owner's responsibilities

The Scrum framework defines the role of Product Owner, PO, or Product Owner. This role is a business-minded person - and only one person. This person must be a profit or business value oriented thinker. And in this sense, it is a person whose responsibilities also include listening to the customer or consumer, the organization, and in general the market for "opportunities and threats" to generate value within the context of the product or service under development.

Beyond the Scrum framework, the role of the PO fulfills certain key functions within any initiative.

• Identify opportunities and threats to the business - within the context of the product or service under development.
• Explore new and/or improved functionalities to strengthen the product or service.
• Establish the development path of a product or service.
• Manage the backlog
• Consider requirements or needs beyond business value to mitigate technical debt^[3]This function has its detractors. However, in my experience, the PO cannot just prioritize the business over the technology that enables product delivery. Even without being a technical expert, he or she must learn to balance product advancement to mitigate products that are functionally wonderful, but are not able to scale to exponential demand, or that cannot coexist with other products and services from the same company.

The power behind the PO

In my opinion, the role of the PO is much more strategic and key to the success of an agile evolution, even beyond the Scrum Master. In other words, a transformation of the work and management model. can only be considered successful if a good business value stream is established. and, therefore, if the chosen base model is Scrum, then the role of the PO is essential. Conversely, in the absence of a Scrum Master, it is still possible that the desire or need for change will lead the team and organization to a successful agile model - the SM in theory reduces resistance to change.

The PO manages the Product Backlog and negotiates the Sprint Backlog with the team. In addition, according to the Scrum 2020 guide:

1. Develops and explicitly communicates the product's purpose
2. Creates and clearly communicates the elements of the Product Backlog
3. Order - although I like to prioritize - the elements of the product backlog, and
4. Ensures that the Product Backlog is transparent, visible and understood by all stakeholders

The role of the PO in a project or organisation

The PO is circumscribed to the development and operation of a product or service. If the product is new, surely we speak of "project", if the product or service is in progress, perhaps the PO is associated with an area or unit of the organization.

In this sense, a good Product Owner sees the opportunity to consolidate, unify, prioritize and detail all the ideas, opportunities, threats and challenges that a product or service in development or operation has.

Likewise, he understands the importance of keeping technical debt low, even if he doesn't understand the technical detail. So let's go with a hypothetical example:

Suppose I have decided to build a rest house. I, an engineer from a family of architects would like to have control over the requirements, functional and even some design requirements. However, I am not an architect and must balance my desires with the technical constraints available to the architect, a structural engineer and, of course, the available budget.

As a PO, I can't just fill the backlog with ideals or functional issues, ignoring the constraints of the product development context. I must keep the focus on value and benefit.

Opportunities for the OP

• If you like to design, define and detail products or services. The PO role is for you.
• Not everyone is good at "structuring products" incrementally, so there are many opportunities and a good and recognized PO will always have excellent projects.
• You are the bridge between business and development. This connects you very well in the organization.
• You see and control the outcome. It's in your hands how successful a product or service is.

Risks to the PO

• If you don't have power over the requirements and other elements of the backlog you could become a documenter, and thus, the bottleneck of the process.
• If you are not good at structuring products, the concept of incremental can be very painful and you will end up defining "incomplete" products that always depend on "something else" to be functional.
• If the organization you work for doesn't see value in your role, your hands are probably always tied in proposing or structuring. The political-organizational game can be challenging in some conservative business contexts.
• A large technical debt undermines the PO's ability to propose valuable functionality. Many times your job can become "fixing" and not "proposing".

Never unify Scrum Master and Product Owner

If you know about agility you know that what you have just read is nonsense. But it does happen, and it happens a lot. Many organizations do not understand this game of checks and balances, nor do they see value in giving focus to certain roles and responsibilities.

I have never been an advocate of a dedicated 100% Scrum Master and I faithfully believe that the last thing a mature team needs is a SM or a full time facilitator. A coach that drops in from time to time is more than fine. Well, that's what I think.

However, the Product Owner is a key role and many projects stop or slow down because there are no good inputs to advance the work. There are no priorities or no one has thought about how to deliver incremental value.

In this sense, I have always defended the importance of the role of PO.

SM vs. PO Comparison

Final Considerations of the Product Owner and Scrum Master Roles

1. Never try to unify both roles
2. They are different and complementary roles that exert a pulse of forces - natural and healthy for organizations.
3. The PO is oriented to the details of the product or service under development or maintenance. The SM is oriented to the team and the "good manners".
4. The professional projection of both roles is different
5. The key skills for success in both roles are different in some cases

Do you have any comments, experiences or suggestions, let me know in the comments your opinion.

Share!