Traditional roles vs Scrum roles

Ok, you have an "ordinary" organization with traditional roles, and you want to do Scrum.
You have someone with “Project Manager” or “Producer” written on their business card. Maybe you have someone who’s “Technical Project Manager” too. You have your team, obviously. And last but not least you have some Customer. In our company we do our own products, so we don’t have external customers in that sense. We do have users who are extremely important of course, but I regard them as end-users rather than assigner in the sense of who’s ordering work from us in production. In our case the assigner is the person with "Product Manager" written on the business card – she’s the one making the business calls and the one outmost responsible for the direction and the result of the product. In the world of consulting the customer is obviously the external party who orders and pays for the work done. Anyway, the team does the work. The Project Manager is usually responsible for the high and the low; from high-level planning and risk management down to resource allocation, problem-solving, task assignment & follow-up, etc. The customer makes the order and expects delivery. Below you’ll see a schematic of the traditional roles.

Ok, so we’ve ironed out how things usually look. The above would apply to organizations with external customers (like consulting companies) as well as organizations with internal customers (like us, who own and distribute our own products) – it’s just a question if the Customer is an external or internal role.

Now, one simple approach when introducing Scrum is to put the Scrum Master-hat (SM) on the project manager. He’s the one doing many of those duties anyway, like helping the team move forward, keeping track on who’s doing what, the one controlling the status meetings, etc. Let’s say you do that, so then what roles are left to figure out? Yeah, the Scrum Product Owner. Ok, that sounds simple enough, at least in a company like ours where we already have someone internally who’s “owning the product” and making the business decisions: the Product Manager becomes the “Scrum Product Owner” (SPO hat). Even the name of the Scrum role suggests this construction. Now, in a consulting company, with external customers, I’m not sure it’s as easy as that. I’ll leave that open for now. Anyway, here’s how it would look:



Wow. You now have a team, the person who used to be “project manager” who is now called “Scrum Master” instead, and the person who used to be Product Manager is now called Scrum Product Owner. Sounds alright, right?

Wrong! But what’s wrong with this picture?

A lot of things. One of the most obvious things with this setup is that the Scrum Master isn’t someone within the team. The ever-so-important purpose and work of the Scrum Master is missing or at least the efficiency will be lower because of it. See previous blog post below about why the Scrum Master shouldn’t be a formal leader and needs to be someone within the team. Another factor here, if you have some history in your organization, you’ll need to remember that the project manager has been the one putting the strain on the team, the person who’s been breathing down the team members’ necks. The one with the whip. So it’s a person that the team will most likely never see as “being on their level”; a fact which will make it hard to perform the duties of the Scrum Master to any meaningful extent. So what can you do to change that? Maybe what you want to do is give the Scrum Master hat to someone in the team? Voila, you have your roles. And the project manager is out of a job. Or?



But wait, so far we haven’t discussed the appropriateness of giving the product manager the SPO hat. We just assumed it’s best because the names of the roles are similar :-). I argue that you need to carefully consider whether or not the product manager should really be your PO. In fact, I think that instead the project manager is very suited to take on that role. Because what happens is that the “project manager duties” are smeared out across (A) the team and the Scrum Master, and (B) the SPO. The daily stuff, the things that have to do with who does what, when and why, is handled by the team and the Scrum Master, and the planning, prioritization, risk management and so in is done by the PO. And so, the product manager in this scenario (or in the case of a consulting company – the customer) is perfect for being regarded simply as “Customer”, nothing else.

Now, I know there is some people arguing out there about whether or not “Product Owner proxies” should be used. Here's a link to a Swedish article by Tobias Fors on that subject. As I understand it, the argument from those opposing it is; if the person with the outmost responsibility (e.g. the assigner – the customer) for the product is not deeply involved with the team and instead those duties are taken over by the former project manager – now called the PO – then the PO becomes just a “proxy” for the real product owner. And a key point in Scrum is to involve the stakeholders early, with the team, and get the feedback directly and quickly. Hence, relying on a proxy for it will negatively affect that. So the argument is to forget about proxies and instead let the real product owner be the one with the Scrum Product Owner hat. Well, I have to agree with that. But there’s a reality too, where the product manager is loaded with business decisions, meetings, research, spreadsheets, budgets, administration, etc. In an ideal world I would change all that and remove all those things from the product manager’s back so she could focus on the important parts; what goes in the product – and thereby give the Scrum Product Owner role to her. But we don’t live in an ideal world and I will have to make do with what I can get. And the next best thing is a really engaged project manager (who I call “Scrum Product Owner”), who has the direct link to the product manager (who I call “Customer”).

So, finally, my recommended setup is as follows;


With this setup, some of the advantages are (not in any particular order);

• The Customer/ProductManager can focus on other things too, and does not have to spend all his/her time on helping the team get the job done. He/she still has to be around on a regular basis and provide feedback early, at least on or around every sprint review.
• The Scrum Product Owner is a full-time role who's job it is to (a) know the customer and (b) know the team. The challenge here lay (among other things ;-)) in how well this person understands what the customer wants, and how well that understanding is reflected in the prioritization of the product backlog and the breakdown into stories.
• The Scrum Master is someone within the team, not a formal leader. Also, with this construction the Scrum Master can really focus 100% on being the one sweeping a clean path for the team ("the curling parent"), without any specific further responsibilities outside those of the SM and those of the whole team as a collective.

In an ideal world, if I practically had the choice (e.g. if I were to build up a new organization from scratch and got the power to decide every aspect of it) then I would try and let the "Product Manager/Customer" have the SPO hat. In that sense I do agree with the concerns about "Proxy Product Owners". But if that is not possible - which I don't see that it is in our case, and probably in many other cases - then I chose the pragmatic approach. I think the above is the better than... Well, what's the alternative? To have a Scrum Product Owner or a Scrum Master that for various reasons aren't focusing 100% on their roles.