Why an Agile Project Manager is Not a Scrum Master

A reader asked why the lifecycle in Agile Lifecycles for Geographically Distributed Teams, Part 1 is not Scrum. It's not Scrum for these reasons:

  1. The project manager and product owner start the release planning and ask the team if the release planning is ok. The team does not generate the initial draft of release planning itself. In Scrum, the team is supposed to generate all of the planning itself.
  2. The checkin is different from the Scrum standup and the objectives of the checkin are different. I did suggest to the teams that if you want to create a cross-functional team where the functions are separated, if you ask people how they are working together, you might help them work together. Sometimes those questions work, and sometimes they don't. It depends on the team and whether the people want to work together.

I didn't mention retrospectives or backlogs in my examples so far, because I took them for granted. Yes, both examples of these teams do perform retrospectives and have product backlogs. They also have agile feature roadmaps, which are on my list to blog about.

The real difference is the difference between a Scrum Master and an Agile Project Manager. A Scrum Master is not a project manager. A scrum master does not manage risk by him or herself. A project manager will take on the risk management responsibility without asking the team.

A Scrum Master has only allegiance to the team. A project manager has responsibility to the team and to the organization. That means that the project manager might feel torn when the organization pressures the project manager to do something stupid. (Although, I just downloaded the Scrum Guide, and the Scrum Master's responsibilities have grown considerably since I took my CSM with Jeff way back in 2006.)

But agile provides transparency when the organization asks the agile project manager to do something stupid, so it's easier to retain your integrity as a project manager.

Want to move a feature higher in the backlog? Change the feature roadmap with the product owner and then change the backlog with the product owner. I expect the agile project manager to collaborate on the feature roadmap and the backlog with the product owner.

Want to change the velocity of the team to please some crazed manager? Both the Scrum Master or the agile project manager protects the team in these ways:

  • Explain that velocity is not a productivity metric
  • Say No and explain why
  • Play the Double Your Velocity schedule game
  • Or choose some other way to remove this management obstacle.

Agile makes it easy to protect the team. The question is this: does the Scrum Master have other responsibilities in addition to protecting the team or is the Scrum Master full time? An agile project manager tends to be full time on a geographically distributed team. Even on a geographically distributed team, a Scrum Master is not seen as a full time position. Bless their tiny little hearts, managers don't seem to understand that transitioning to agile, especially for silo'd distributed teams with different cultural norms is non-trivial. They will make room for a project manager, but a Scrum Master? Oh no. Makes me nuts.

Cut corners on quality? I don't see how. The team doesn't meet the acceptance criteria on the stories and doesn't meet their criteria of done for an iteration, and can't show a demo. How does that serve anyone?

Help a team go faster? This is the one place where a project manager may have an edge over a Scrum Master, and that's only because of education. An agile project manager is a project manager. That means he or she is actively studying project management, which means he or she is studying lean also, looking into work in progress. (I realize many project managers do not actively study project management.) I have high expectations of an agile project manager, and that is to limit WIP, work in progress, to measure cumulative flow. But, Johanna, that's a lean project manager. Yes, that's correct. Why not use all of the tools available to us at all times? This is not to help a team actually go faster, but to provide feedback to the team about their WIP. If everyone takes a story at the start of the iteration and everyone always works on their own story, it's likely the team is at the slowest possible velocity. It's worth knowing that, or at least retrospecting about the data. A project manager will gather the data. A Scrum Master, especially one who was not a trained project manager, may not know to gather the data.

I have nothing against Scrum Masters. Some of my good friends are CSTs (Certified Scrum Trainers). However, they are not all project managers, and have not been project managers, and have not studied the field of project management. Some have been. And, the real issue is this: In a two or three day workshop, they cannot convey to a person who may or may not have been a practicing project manager all of their project knowledge.

Organizations do not always pick project managers to be Scrum Masters. And, with good reason. Some project managers are command-and-control project managers. I suspect back in my long-ago past, I was. I gave it up long ago because it didn't work. Some people never gave up command-and-control project management. Those people are not good project managers for agile projects. They are terrible project managers for geographically distributed projects, where you must work through influence.

You can have self-managing teams that are geographically distributed. You can have self-directed teams that are geographically distributed. But, they don't start that way. They evolve into self-directed and self-managing teams. They start as management-led teams.

And, especially when they are silo'd teams, they need the coordination of a project manager, someone who will manage the risk between the silos, and someone who has the organizational backing, and yes, someone who has the allegiance to the organization to say, “We need to do this project” to write the project charter.

In a geographically distributed team, the agile project manager writes the project charter either with the team, or as a strawman for the people to edit and approve. Shane and I recommend that the people get together to write it together. We like it if people get together in person. We know how rarely that happens. (Penny wise, pound foolish.) So we teach people how to write a project charter when they are divided in space.

Because until there is a project charter, there is no organizing principle for the silo'd teams. Those developers in France, testers in Belarus, product managers and project manager in San Francisco, they all need something to coalesce around. The charter, which includes the project vision provides that. The iterations provide the project heartbeat.

So, that's why I don't think Agile Lifecycles for Geographically Distributed Teams, Part 1 is Scrum. It's close, but no cigar. I respect Ken and Jeff's work too much to call it Scrum when it's not.

Now that I'm mostly recovered from my cold, I can continue the series about lifecycles.

10 thoughts on “Why an Agile Project Manager is Not a Scrum Master”

  1. Pingback: Can Anyone That Old Know Anything? | Hiring Technical People

  2. Hi Johanna,

    I’m sorry to say, but your post makes very little sense to me and it seems to point to very deep misunderstandings about the ScrumMaster role. First, a ScrumMaster does not only focus on the team. This is, in fact, a very common mistake in the ScrumMaster role. Already in Ken’s very early material, there was always an organizational change agent part of a ScrumMaster. This is also reflected by Michael James’ ScrumMaster Checklist (which you can find at http://www.scrummasterchecklist.org).

    Second, most experienced Scrum Trainers I know recommend the ScrumMaster to be a full-time job, especially in larger organizations. So, stating that it isn’t seems very odd to me.

    Last, because Scrum is based on self-managing teams, keeping a Project Manager is often very harmful for organizations as the responsibilities will start conflicting with a Product Owner and the team. So, I do promote organizations who adopt Scrum to remove the Project Manager role or at least not let that person be involved with the Scrum project. This, in my experience, has always led to better results.

    So, your blog post doesn’t make too much sense to me 🙂


    1. Here’s an updated link to Michael’s checklist: checklist
      Bas, we can agree to disagree. My experience is different from yours. You have clearly seen command-and-control project managers. I have seen facilitative project managers. All project managers are not the same. Nor are all Scrum Masters. We can leave it at that, agree to disagree, and still enjoy each other when we meet at conferences. How about that?

  3. I appreciated both of your posts. I think both roles are necessary, and Joanna agree with your perspective, not just because I am a PM too, but because they roles and responsibilities are very different; both are necessary.

  4. Johanna, I actually have a suggestion here. Why don’t we have managers (not project managers, the actual supervisors, people with positional authority) to take care of the below – “need the coordination of a project manager, someone who will manage the risk between the silos, and someone who has the organizational backing, and yes, someone who has the allegiance to the organization to say, “We need to do this project” to write the project charter”. After all, if we say that managers should become truly servant leaders, then those managers would be best positioned to manage cross-team risks, help coordinate work between silos, etc. And those managers definitely would have organizational allegiance. I actually witnessed a scrum team that had a manager like that (all the people on the team reported to that manager HR-wise). He was very instrumental in managing across teams, enterprise-wide, outside of team control risks and also was a a great liaison between the team and the rest of the organization (including other teams). That team had a scrum master and had a product owner. It worked really well. Appreciate your thoughts on the subject. Thanks.

    1. Alex, if that manager was managing across teams, then that manager was a program manager. Managers can do that. It depends on what else they have to do. Who manages the project portfolio? Who manages the product roadmap? Who creates communities of practices? Is the team totally self-managing? I wrote an article about what agile managers can do, Agile Managers, The Essence of Leadership a few years ago. I had not realized about the communities of practice part there.

      I’m big on the team writing its own charter, but it doesn’t have to be that way. Just because I haven’t seen a successful project with someone else writing a charter doesn’t mean a project can’t be successful with someone else writing its charter. (Was that too many nots??) I’m willing to say that a team can be successful if a manager writes a project charter. I think it has to be more difficult, but I’m willing to give that project, that team, that manager the benefit of the doubt.

      I don’t have all the answers. It really does depend on each team and each organization. There is no one size fits all.

      1. Johanna, thanks for your reply. I just read the article you mentioned. In the beginning of it, you talked about managers being organizational leaders and “setting strategy, managing the project portfolio, removing organizational obstacles, building trusting relationships with technical staff, coaching, providing feedback, assisting with career development, leading the hiring decisions and process, and building the capacity of the organization”. I see an overlap here between what managers would do and what program (or project) managers have been doing. In an Agile environment, do we really need that many different managers? If one person would fulfill things you mentioned above (in quotes), can we “marry” Manager and a Program Manager to flatten the organization a little bit, thus simplifying communication? If our managers no longer carry day-to-day management burden, would they start to act more like Program Managers? I am looking for ways to simplify the structure, decrease the number of communication channels, remove un-nessasary middlemen… I have seen organizations with both Managers & Program Managers trying to “manage” Agile teams (that all had Scrum Masters and Product Owners) and I thought it created an overhead. In my opinion, it had a lot to do with those managers and program managers trying to redefine their roles and value they bring to the table since the those organizations changed the way they worked (transitioned to Agile). I am just curious what would you think of such idea? Thanks!

        1. Alex, One team does not need a program manager. Two teams might not need a program manager–the teams can either agree on how to manage the risks or one Scrum Master can take on the intra-team risk management or the two Scrum Masters or the project managers can agree on how to manage the intra-project risks.

          However, once you get to three teams, you need someone. I think that someone should be a dedicated program manager, someone whose job is not managing people or the project portfolio or building trusting relationships with people or building communities of practice or anything else that managers do. A agile program manager’s sole purpose in life is to collaborate across the organization to ease the way to release the product. (I have not completed my definition of agile program manager, that’s my working definition. Wait for the book, please!)

          I don’t believe in overloaded operators. I don’t believe in overloaded people either.

          Can you have managers do the work of a program manager? Well, maybe if it’s only three teams. I don’t know too many three-team programs, so I can’t say. I only know of larger programs. The last time I was a program manager inside the organization, I had to stop being a Director-level manager and be just the program manager. I could not manage just three people, do the strategic work at the director level and manage the program. And, I had already managed several programs before then.

          Remember, a program manager is not part of the management structure, so I’m not sure why you think it’s part of the management overhead.

          There is no reason for Managers, Program Managers, Scrum Masters, and Product Owners to manage an agile team. That’s just Wrong. I have some suspicions about what’s happening. I’ll ask you privately and then maybe I can blog about it. I am collecting horror stories of programs gone wrong.

Leave a Comment

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: