Can the Principal Software Engineer Assume the Product Owner Role on a Scrum Team?

How the Right Questions Will Set the Tone for Effective Scrum Implementation in Organizations New to Scrum

9 May 2014


Last week, I got the question in this story title from an ex-colleague whose organization has recently started implementing Scrum.

My former colleague understood the theory that there is no such role as "principal software engineer" in Scrum, but his problem was a typical one that most organizations new to Scrum find themselves facing.

The organization had a profile with superior technical knowledge, experience, and intellect. The senior operational management of this organization wanted the principal software engineer to assume the product owner role.

But my ex-colleague felt that might not work well and so called me to seek my opinion. Here's what I said:

The principal software engineer is not a good choice for the product owner role.

Principle Software Engineer as Product Owner

While Scrum doesn't say that the principal software engineer cannot assume the product owner role, it is not a good fit for the skill set of a principal software engineer.

In Scrum, there are three roles: the product owner, who owns the product; the ScrumMaster, who owns the process of developing the product and works toward removing the impediments; and the team members, who carry out the development activities.

Consider what Roman Pichler writes about the chief duties of the product owner in this article:

"The product owner is required to closely collaborate with the team on an ongoing basis and to guide and direct the team (e.g., by actively managing the product backlog, answering questions when they arise, providing feedback, and signing off work results). In simple terms, the product owner sits in the driver's seat, deciding what should be done and when the software should be shipped."

Is this what a principal software engineer's core competence is?

It's not.

One of the most important points Scrum makes is this: Self-organize in a way that gets the value delivered, as fast as possible.

Will the optimum value be delivered if the principal software engineer is operating in another function (in our case, as the product owner), which requires a different kind of competence?

Typically, a principal software engineer would be biased toward getting the activities done, and he'd subconsciously take the "service" side, not the "direction" side.

While in theory there is no such thing as a "side" in Scrum, as human beings we are generally not good at unlearning -- so we bring our biases from past experiences into new arrangements without even noticing.

So, a principal software engineer, lead developer, or technical lead as a product owner is not a good idea.

Sure, there might be exceptions, and a few organizations might have seen some success with that -- but in principle, it should be avoided.

The key take-home point: If the person responsible for a particular task is not operating from his strength, from his core competence, then it's not a good idea to let the person perform that particular task.

What does your experience suggest? Have you observed a case where the principal software engineer acted as product owner and immense value was delivered? Let's open a dialogue and learn from each other's experiences.


Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.



Article Rating

Current rating: 5 (5 ratings)

Comments

David Lowe, CSP,CSM, 5/9/2014 2:12:21 AM
Great minds think alike: I posted this on the same day - http://scrumandkanban.co.uk/duplicate-roles/

I'm hearing more and more people trying to merge roles for various reasons: particularly worrying is the ScrumMaster/PO hybrid. Glad your with me on the fight against it.
Utpal Vaishnav, CSM, 5/9/2014 3:26:45 AM
Thanks David for sharing your piece of wisdom. Enjoyed reading it. The key question, the way I see it, is that in order to use a zen like thing as Scrum, one has to get to know what it is, not what it should be as per conventional operating patterns.

Scrum can be understood only when it's experienced. The problem with its management buy-in is that they "talk" and "discuss" about it but hardly experience it themselves and hence all such challenges.

Have a great time there!
Saji Pillai, CSM, 5/9/2014 6:37:41 AM
Who do you think then should be a product owner. I presume product owner own's the product. It is not just the product catalog. He is responsible for what goes in the product catalog and owns the final product( Which is of importance to the stakeholder not the catalog) . You have the answer in your own sentence. "The product owner is required to closely collaborate with the team on an ongoing basis and to guide and direct the team (e.g., by actively managing the product backlog, answering questions when they arise, providing feedback, and signing off work results". Collabrating is just one of the jobs he needs to do. "answering questions when they arise, providing feedback, and signing off work results" needs him to know the product throughly. New process can only be implemented if we can reuse the existing resources and not need new set of resource. I like scrum since it brings in collaborate in the role which is were traditional SDLC fails
Tim Baffa, CSM, 5/9/2014 9:01:10 AM
I agree with the article, but it seems to be missing the most important factor why a role like principal software engineer should never be placed in the role of a Product Owner on a Scrum team.

The Product Owner is in charge of the "what" - what can provide value to the business, and what can provide value to users and end-customers? The backlog is built with user stories (ex: "As A... I Want... So That...") that communicate this business value, and are prioritized according to the Product Owner to ensure the team is always focused on the most critical items.

What is critical to Scrum is that the backlog items must not be worded in any way technically that implies a potential solution in the story. The Product Owner is in charge of the "what", and the team is in charge of the "how".

Therefore, it is a difficult if not impossible proposition to believe that your most adept technical person (principal software engineer) can function in this role and communicate business requirements in a non-technical fashion.
Utpal Vaishnav, CSM, 5/9/2014 3:13:28 PM
@Saji Pillai: Thanks for stopping by and sharing your thoughts. Here's my point of view:

>> WHO SHOULD BE THE PRODUCT OWNER?
The Product Owner is someone who builds, shares and establishes the product vision and inspires the team to self-organize and make that vision take form of the product.

Please have a look at this post to find out more: http://www.scrumzen.com/who-should-be-the-product-owner

>> PRODUCT OWNER OWNS THE PRODUCT (NOT JUST THE CATALOG)
This is little tricky.

What is the "product" in a Scrum Project's context?

The product is something that Product Owner is accountable to create that potentially adds value. For example, if there's a huge CRM system called XYZ CRM and the Product Owner is supposed to create a feature wherein the end users can "edit" the structure of entry forms, then "Editing the structure of entry forms in XYZ CRM" is the Product.

Many people mislead that the whole CRM is the product that the Product Owner is accountable for.

There are scenarios where the whole CRM is owned by the Product Owner (typically his role in external, non-scrum world, would be the business owner, VP of Products or similar) or just a major feature (typically his role in external, non-scrum world, would be Manager, Consultant or similar).

So, yes. Product Owner "owns" the product but it is equally important to understand the definition of product in Scrum project's context.

>> ON NEW PROCESSES
I have an different point of view about if new processes can only be implemented if we can use the existing resources: When the organization is implementing Scrum, its objective is not to reuse the existing resources but to create business value through a different framework. If existing resources are utilized naturally, it's good. If they don't fit, the management will figure out a way.

(Here, utilizing resources has nothing to do with Scrum team - as it is self-organizing. Typically, businesses are led by people and not thoroughly self-organized and utilizing resources is a business problem, the management has to figure out a way)

>> ON SCRUM VS. CONVENTIONAL WAYS
My understanding of Scrum suggests that even Scrum (or any Scrum ceremony or artifact OR anything) should not come in way of creating value. I know this statement is zen like and hard to experience through words but that's what.

The effective Product Owner understands this: "Objective of Scrum is NOT to follow (or not follow) a new process but to create business value!"

When there's lot of uncertainty, an effective agile framework such as Scrum, when done right, can produce excellent results.

When there's lot of clarity and things are unlikely to change, Scrum may not be that effective.
Carlos Monroy Nieblas, CSM, 5/10/2014 5:32:02 PM
Based on our experience, the transition from developer to Product Owner is quite a challenge that will require special characteristics that not everybody posses; the function of the Product Owner is to define what needs to be done, not the how, which is responsibility of the team. It is quite easy for a former developer to try to impose a technical solution or a technology framework without listening to the team from a power position.
Phalguna Ramaraju, CSP,CSM, 5/11/2014 3:21:11 PM
@Utpal,

When organizational changes occur, people should standup to the needs of the organization and grab new opportunity of their interest, and should prove their best on the job. Usually they prove if they love and are passionate about their job!

First, the person has to have that ‘Can Do” attitude and the required confidence to take up any new role. The key to success is “a constant learner” on that job. It might take some time for the person to become expert in that role.

If my friend asks me the same question, I would only provide good amount of details on PO role to him and will ask him to decide. Did you notice your friend in this case has a greatest advantage to start with - the senior operational management support! What else he needs is, his own “Courage” and “love” to dedicate for the PO role! In my opinion, it should not be a “let me give a try” attitude, but a commitment to learn on the job and perform.

I have seen doctors becoming great servant leaders on projects! So, it is all in the intrinsic interest of the individuals, the success lies!

Your statement, “So, a principal software engineer, lead developer, or technical lead as a product owner is not a good idea”, is a generalized opinion that I read some books too; but it depends on the individuals in the context.

Referring to your statement, “Sure, there might be exceptions, and a few organizations might have seen some success with that -- but in principle, it should be avoided.”;

An organization’s success is always because of the successful work of the individuals in that organization. So, it is again that individual who has do decide, what he/she wants to be.
Utpal Vaishnav, CSM, 5/13/2014 10:38:19 AM
@Tim Baffa: Thank you for your remarks and addition of the "why" part which was described implicitly by the mention of Principal Software Engineer's core competence is different from Product Owner's.

I appreciate it.
Utpal Vaishnav, CSM, 5/13/2014 10:47:47 AM
@ Carlos Monroy Nieblas: Your experience is very apt.

Typically, the developers are left brainers. They operate from very logical point of view. Since Product Owner represents business's point of view, he is effective when he is a whole brainier and which is rare.

In principle, you're right that Product Owner's responsibility is to define "what" part but in practice, I've seen that Product Owners who have good knowledge of "how" part, although at a higher level, are more effective.

They are more effective for a simple reason - technical team understands them well and would want to collaborate with them more. This is an important characteristic for an self-organizing team.

You're right about some developers who try to impose the "how" part on the team which is not a good sign for sure.
Zach Bonaker, CSP,CSM,CSPO, 5/13/2014 12:47:53 PM
I've had plenty of experience with this assignment of "software architect" to "product owner". In my teams where this has been enacted, perhaps unsurprisingly, the backlog has rapidly deteriorated into a set of "programming tasks" and solutions. User stories have generally been replaced by "do this, do that" statements.

The backlog is geared toward the design of software solutions, not the user desired value of software features.

Good software architects are incredible and brilliant people. Based on my experience, organizations should let them assist teams by helping to architect great designs around a backlog... not drive the business value.
Warren Marshall, CSPO, 6/26/2014 10:47:37 PM
While it is clear that the usual skills you attribute to a product engineer tend to be far distant from those of the people who have the business need, it is not a universal truth.

In my case, I wrote the original software which is now being reengineered into the cloud. My original role as software architect, combined with very significant experience, understanding and client contact at the business end, was actually a very good base to learn and conduct the role of Product Owner. The team members and scrum master have found me an extremely effective product owner, not to mention effective as an occasional scrum coach.

There are certainly many pitfalls taking the Product Owner role from this perspective, but they may not be ones you expect.

For instance, one thing I realised quite late in the project, is that the team was relying on me for more technical expertise than they should have. In fact they were learning less because they were hanging on my coat tails for the ride. Once I realised this, I made a point of redirecting all technical matters, which could be answered by someone else, toward the scrum master for management of the issue. This has proved an effective way to keep my role "clean".

Of course, once in a while, my own technical knowledge is essential to the needs of the team. When this happens, I like to be treated like any other easily accessible external resource to the team.

Even so, it is nice to be able to guide less experienced developers in such matters as overcoming timing anomalies within a multi-user web-based database application (e.g. one person presses the delete button where another has already disabled the delete button on their view of the page). Clearly this has nothing to do with the Product Owner role but emphasises the fact that each of us brings unique skills into a team environment.
Warren Marshall, CSPO, 6/26/2014 11:15:52 PM
There is one thing which is certain. Someone doing the development cannot be the product owner as the signoff of a business user story (as distinct from a technical user story) cannot be done by someone who has responsibility for its coding or testing - it need to be done by someone completely independent of that process.
Warren Marshall, CSPO, 6/27/2014 12:55:05 AM
There is one thing which is certain. Someone doing the development cannot be the product owner as the signoff of a business user story (as distinct from a technical user story) cannot be done by someone who has responsibility for its coding or testing - it need to be done by someone completely independent of that process.

You must Login or Signup to comment.