Red Flag: Combined Product Owner and Scrum Master

Red Warning Flag On Beach

Stuart Miles – FreeDigitalPhotos.net

Every attempt at transition can have issues. Some issues are fairly common regardless of who attempts the transition. No matter who tries to cross the Sahara there will be a lack of water available during the trip. These common issues are often called red flags.

Every desert crossing attempt is unique. The people and methods involved vary. Some may be making the trip over the course of week, others in just a few hours. In each of these circumstances the best way to address the lack of available water is very different.

In Agile transitions there are also red flags. Just as with crossing the desert each Agile implementation is different. As such there is not a proper way to address every issue every time. The more similar organisations are the more similar the solutions may be, but even that is not a given. Today we are looking at the Agile red flag of a combined Product Owner & Scrum Master.

Wait! Before you click away thinking “we don’t use scrum” think of this for a moment. In Scrum the Product Owner is kind of a proxy for the users of the product. Also in Scrum the Scrum Master is a servant leader to the Scrum Team. Even if you don’t use Scrum you probably have a person or group that you consider the product representatives. You probably also have someone who helps the team creating the product to succeed in every way they can. (If you don’t that’s a whole different issue not even related to Agile…) The concept is the same, but “combined people directing the product and people leading the product development” just doesn’t roll of the tongue.

For many organisations transitioning to Agile methods there is a problem. They have to figure out what to do with their project managers. Often they put them in a role where they are in charge of developing the product. It seems natural. They were about to be the PM over the project developing the product, so why not? On the surface, I agree. It is a natural place to put them. It needs to be better defined though. The red flag is there warning of doing all the same stuff with a new name and getting no benefit.

What happens is that the former PM settles in to their new role. If it’s Scrum being tried out this is generally as a product owner. They’ll then get in touch with, you guessed it, the tech team lead who is now Scrum Master.  They will then give that person a list of tasks and start holding them accountable for delivering on those tasks. Does this sound Agile? It doesn’t to me. It sounds like the PM and tech leads got new titles.

This gets even worse when the PM is a very task oriented PM. In these cases the PM will not only create this list of tasks, but they will then start assigning them. The daily stand up will become a place where the team members tell the PM, err sorry, PO what their status is on the tasks. Suddenly the PO is not only the one directing the product, they are also directing the product development team. Agile has probably been broken.

The problem lies in the inherit conflict between those that want the product and those that create it. There is a good reason to separate the PO and SM in Scrum. No, I don’t mean because the Scrum Guide says so. The PO is all about the product. Every decision they make is to get the most valuable product as quickly as possible. The SM is all about the team. Every decision they make is to help the team succeed to the best of their abilities. There is a subtle but important difference here. The easiest example would be short-term product value over long-term team health. A constant “death march” could theoretically deliver more product value more quickly but would demolish the team.

Is it possible for a single person to advocate for the product and the team at the same time and still be Agile? Sure. If the person driving the product is properly invested in the team, is an integral part of the team, and realizes that the team needs to be valued along with the product it can work. More often than not it is better to split the roles.

Have a person dedicated to the products success and a different one dedicated to the team’s success. Make sure they work well together. Watch as they deliver a more valuable product. The team will thrive with a person working to allow them the most success they can achieve. The long-term gains will usually be significantly higher than the cost of another person on the payroll.

Do you see these roles combined? Does it work? Would it be better if they were split?

Leave a Reply...