Mapping traditional PM role to Scrum
February 6, 2011 | In: Project management
Judging by the number of similar blog posts, I guess I’m not the only one trying to map traditional project roles to Scrum roles 
Situation: I’m a PM in a software development company. So far we practiced RUP but now we’re moving to a more agile approach. Like Scrum.
So naturally, I’m trying to understand where my PM role fits into Scrum framework. Yes, there are ScrumMaster and Product Owner but who am I?
Take a look here how Scrum Alliance defines roles and responsibilities of ScrumMaster and Product Owner.
First thing I noticed is that it’s impossible to define general mapping between PM role and Scrum roles because each company defines PM roles and responsibilities differently.
From my standpoint, as a PM in a strong matrix organization, traditional PM role covers not only ScrumMaster role but much of the Product Owner role too.
Having roles and responsibilities defined by Scrum Alliance, here is my attempt to map them to traditional PM role (in the context of a strong matrix organization where PM is ultimately responsible for project outcome):
It is generally accepted that, in a transition to Scrum, PM should become ScrumMaster. This means that PM should give up on many of her current (very important, I would say) responsibilities if she wanted to become ScrumMaster. Looking at the PM responsibilities that are now divided between ScrumMaster and Product Owner, I really cannot decide which are more important for PM.
There is also a very interesting post by Mike Cohn saying that one person cannot be ScrumMaster and Product Owner at the same time. Referring to that post, I as a traditional PM entering Scrum world would like to do more star tasks and less guardian tasks.
Does this mean that I map better to Product Owner role than to ScrumMaster role? I think not. I would like to be a ScrumMaster with some of the Product Owner’s responsibilities. If there was a slider control between SM and PO in terms of responsibilities, I would just like to push it a little bit in favor of SM. In that case there would be far less confusion with roles when moving from traditional approach to Scrum.