Project Manager or ScrumMaster?
It seems that there is a lot of confusion and even some controversy around Project Managers and ScrumMasters. I doubt I will settle that argument, but that won't stop me from adding my two cents.
Let's start with the basic premise that an Agile team is a small, multidisciplinary, cross-functional, self-organizing team of peers with interdependent and cooperating roles. We'll take these attributes one at a time, but before we do, I want to separate the concept of a role from a title.
A "role" is a description of what a person does, or a collection of the functions performed. A "title" is a convenient organizational name for a person who typically performs a certain set of functions. Job descriptions bundle those functions and put a label on them called a title. People play a role, but a title is given to a person. Over time, roles may change even though titles persist, regardless of the work being done.
The goal on any team is to make sure all necessary project functions are being performed optimally to make the team most productive. (Keep this definition in mind as we go through the attributes of an Agile team.) So, rearranging the functions based on the needs of the team, even if they are not aligned with the prescribed job title, would only make sense. After all, an Agile team is self-organizing (but I'm getting ahead of myself). Let's break it down.
A lot has been written about the proper size of a team, yet teams are successful and unsuccessful at all sizes, from 4 to 40 to 400. What really matters is not the size but the quality of the communication patterns and fluidity of idea exchange. Both are typically easier when teams are small. I won't go into a lot of detail here because most teams can sense when they are getting too big, if they are paying attention at all. Just keep in mind that bigger groups create more noise that interferes with effective communication. Hence, small.
Specialization creates functional silos requiring handoffs where information can be misinterpreted, changed, or lost. It also supports unintentional uniformity of thought. It is great for assembly line work, but not where diversity is needed to inspire creativity and innovation. Specialization also creates a risk of knowledge bottlenecks and can slow down production due to secular resource skill constraints. Strong teams have a lot of overlap and intentionally inject new ideas from those learning a new discipline or challenging the status quo. When each team member has a strong understanding of the functions of the others the silos break down and everyone is encouraged to take a more holistic approach to building the product.
In most organizations, job functions are typically attributed to a title more so than a role. However, if a function was restricted to a specific person because of their title, this could create bottlenecks as project work ebbs and flows. In most projects, the available work doesn't always line up with the available resources by function. When many of the team members can do many of the functions of the various titles, the team is better positioned for success on projects with variable work and high uncertainty. An added benefit of cross-functional teams is that team members are continually challenged and encouraged to grow and learn. Continuous learning is a hallmark of really good teams.
Teams are self-organizing when they take ownership for not only the outcome of the product of their work, but also how they go about working together to create that product. A self-organizing team takes ownership of who is going to perform which function, though they probably express it as someone's name rather than a title. This is where the confusion around roles and titles can start. Functions are typically aligned to a title, because for most teams in most environments on most projects that makes sense and works. And by works, I mean it achieves the goal of maximizing the productivity of the team. However, if functions are rigidly ascribed to a title and become singularly embodied in a specific person on the team, this can create a constraint. The self-organizing team needs the flexibility to do what is right for their project and environment. Self-organized team members need to feel empowered and in control of their destiny. For this reason, roles are a better framework than titles.
Team of Peers
I would like to think that this one almost goes without saying. Unfortunately, it may be the most insidious and difficult team quality to achieve. It is challenging because as humans it is our nature to compare ourselves to others and this can materialize as competition, insecurity, irresponsibility or any other form of dysfunction. This is where confusion between titles and roles creates the greatest issues. Program Managers trump Project Managers who trump Developers who trump QA who trump the new kid you send out for coffee. This hierarchy, real or implied, formal or informal, suppresses communication, stifles innovation, and erodes trust. Parity on a team is not about people being the same. It is about people being treated the same. Same respect, same challenge, same accountability, same collaboration. When you breakdown the organizational restrictions of titles, even if you leave the titles themselves, everything flows better, up and down.
Interdependent and Cooperating Roles
So, with that foundation, what is the difference between a project manager and a ScrumMaster? If you look at the functions that have to be performed for a team to be successful, I believe that they would all fall into three major categories: product management, project management, and execution. Product management is about making sure the right things get done. Execution is about doing those things right. Project management is everything else. If your project managers are doing product management or execution, that's fine (see the multidisciplinary and cross-functional topics above), but when they are doing that work they are not doing project management. They are doing product management or execution functions with the title of Project Manager.
Project Manager or ScrumMaster?
So, let's focus on the real project management work functions. I have read a lot of articles about the differences between a project manager and a ScrumMaster, and quite frankly I think most of them do a major disservice to really good project managers. A lot of Agile zealots think project managers are egotistical, political, bureaucratic control freaks who manage through their budgets and schedules. On the other hand, ScrumMasters are enlightened leaders who wear Mr. Rogers cardigans and wouldn't be caught dead using Microsoft Project. I disagree! That said, there is a lot of evidence to support their position on PMs, although there is little to support their second proposition.
Really good PMs and ScrumMasters lead people and manage work. That is worth repeating. Really good PMs and ScrumMasters lead people and manage work. If they are doing that, it will be hard to tell the difference.
The reality is that the constitution of today's workforce, the organizational culture of today's teams, and the nature of most of today's projects are all different, and therefore require different project management methods. Today's teams are better served by more facilitation, coaching, and mentoring—behavior that supports all of the attributes that are necessary for Agile teams. Both today's projects and Agile methods are better suited for participative and laissez-faire styles of leadership. What title people use is immaterial, as long as it is good for the team.
My daughters are grown and out of the house now, but that doesn't mean I am no longer a Father (title) even though my role sure has changed. Additionally, I am a Father-in-law (title) but at times I perform the same functions with my sons-in-law that I do with my daughters. Maybe it is just me, but I don't see the issue. Be who you are, do what you can to help the team. Your title is just window dressing, which only serves to alter the light.