Help me reconcile my title of project manager with performing roles of a scrum master

Question

I am a PMP and I have been assigned to a software development project and given the title of Project Manager. There is no technical project manager for this project and this is a balanced matrix organization where I have a portfolio manager above me and my team is assigned full-time to this project where I am acting as their functional manager (though technically my boss is their boss).

I am doing typical PM stuff like managing scope items, reconciling work items with the BRD/SRS, submitting change requests, and ensuring that we're meeting deadlines. However, we're working in an agile fashion with two-week sprints and the team is trying to behave as "scrum-like" as possible. This means daily scrums, prioritized backlog, sprint planning meetings, etc. However, in scrum the role of project manager does not exist, and in some ways a PM role is antithetical to the idea of scrum as a lot of the PMI-isms are built around the concept of a waterfall model. We also do some very non-scrum things, like loosely assign backlog storied a few sprints ahead to "know what's coming" and give management a plan for the future.

How can this arrangement be described? What happens when a PM is placed on a scrum team? Is this really just working in an agile manner since we're not adhering to the exact rules of scrum so we can't call it so? (like a sparkling wine made outside of Champagne, France)

Answer 1

I have worked as a Project Manager, as a Scrum Master and as a Project Manager on what has loosely been described as Scrum.

As you rightly mention, there are big differences between how you work as a Project Manager and as a Scrum Master. Probably the most important difference is that a Scrum master is not a manager, they are a servant leader. This is a fundamental and irreconcilable difference.

Having said that, it is possible to have the title of Project Manager, but assume the role of Scrum Master. The biggest challenge will not be with the team, but instead will be with your relationship with management and those outside of the team. There will come a time when management will ask for something that they rightly expect from a Project Manager but that a Scrum Master would never do.

One possible approach is to assume the role of Scrum Master and spend some time coaching managers and those outside the team on how Scrum works. If you do this and you have an open-minded management then it is possible to run a successful Scrum team.

Answer 2

If we focus on roles and not job titles, with PM also being a role with activities, then you realise that Scrum splits the traditional team PM into the PO and the SM. The PO manages the Product while the SM manages the process.

There is no role of Project Manager where the team is concerned but the project manager may work for the Product Owner and help them organise customers and delivery.

As soon as you put the Project Manager role with oversight of the Team then you are going to kill the benefits that are the value of Scrum.

If you are a PM who is trying to deliver with an Agile team you need to choose what you care about, process or product. It can't be both...

Answer 3

I think you need to remember that a Scrum Master is a role, not necessarily a title. You could in theory be called the Project Master Manager Guy and still do the role of a scrum master.

In my previous position my title was IT Project Manager, but my daily role was scrum master.

Why so focused on the title and not the job?

Answer 4

Some other answers have mentioned this, but there's a difference between your title and role. Your title in the organization may be Project Manager, but you could have different roles on a scrum team. You can see elements of the Project Manager in both the Scrum Master and Product Owner roles. Since you also mention that you are the functional manager to the Development Team, you may be interested in this question that suggests that there are problems with that arrangement.

The specific tasks that you mention tend to map to Product Owner responsibilities. Managing scope items, reconciling work items with the BRD/SRS, and submitted change requests isn't that different than managing the product backlog by adding, removing, and prioritizing stories and working with the Development Team to make sure the stories. Meeting deadlines is also partly the role of the Product Owner, since part of the job of the Product Owner is to ensure that value is delivered to the user when it's needed.

You don't say how big your Development Team is. Scrum only has three roles - Product Owner, Scrum Master, and Development Team Member. It's not inconceivable that a senior member of the Development Team (preferably with some working knowledge of Scrum) can move into the Scrum Master role while still functioning as a member of the Development Team, leaving you to take on a full role of the Product Owner, which would align with your current responsibilities. If, for some reason, you are under-loaded after this adjustment, consider taking on some work in testing (primarily acceptance testing) or as a domain expert (assuming your team doesn't have domain experience already).

As far as your "non-scrum" things, I wouldn't be too concerned with those. Your specific example, of giving management an idea of what stories may be assigned to upcoming sprints may be a good idea. This can help them in a transition from plan-driven methodologies where every task has a firm date to more agile methods. The key here is to ensure that everyone realizes that everything is tentative outside of the current sprint - priorities can and do change, which is why there aren't excessive amounts of firm commitments too far into the future.

Keep in mind that Scrum is a framework. There are some purists out there, but you do need to keep in mind that you are transitioning from plan-driven methods to agile methods and it takes time to learn the new approach and fully roll it out - it's not just flipping a switch. You should also tailor the framework where appropriate, while considering the lessons learned from people who have made the transition before you.

Answer 5

Don't try to stick with names, roles and methods. Pick up those that you and your team are fun to work with.

Answer 6

Two thoughts - 1. if you haven't check out getting CSM trained (e.g. Scrum Alliance) as that will provide the theory behind the Scrum delivery method. 2. recognize that a PM in Scrum means you are a coach and guide, not a leader. The leader role is with the team. It is a challenge for a PM not to be a PM - your role is to ensure the team have all the resources they need to get the sprint accomplished in the time. This includes access to SMEs as well as the technical stuff. It is also to ensure that the Scrum roles are clear to everyone - team and stakeholders. Product owner should be in the business. Scrum Master is with the team (could be you). In practice, I also think you need to see whether an architect role exists - having the architecture 'emerge' makes some people in the business / IT management nervous. Also providing boundaries (business architecture and technology architecture) is no bad thing - keeps decision making focused. Ideal - experiment! Try changing roles and see what improves. Ask the team what they need. Same for the product owner. It just might be fun!