Scrum hoax #3: Project managers should be Scrum masters

Scrum hoax #3: Project managers should be Scrum masters


How natural is the move from project manager to Scrum master role

While adopting Scrum, many organizations are facing difficulties to appoint the Scrum master. This role has a scope and mission that is disrupting the status quo of the hierarchical organizations, and one particular role: the project manager.


On the other side, Scrum is extremely often seen as a project management methodology, while it is clearly documented as a product development methodology.


From these situation, many organizations choose to appoint project managers as Scrum masters and believe their agile transformation is done. But is it a valid option? Let's have a look.

project manager as scrum master

What is a project

There is no occurrence of the word project in the Scrum guide, so it sounds awkward to see the problem persist. If we can understand the confusion from non-agilist, it is a little more disturbing to hear it from Scrum coach and evangelists.

To give this question a rational answer, let’s review what is a project. No fancy definition here, let’s reuse the key elements of definition from the Project Management Institute[1]. So a project:

    • is temporary in that it has a defined beginning and end in time
    • has a defined scope and associated resources
    • is unique in that it is not a routine operation, but a specific set of operations designed to accomplish a singular goal
    • often involves people who don’t usually work together


Why Scrum is not a project management methodology

If the uniqueness of the work to perform is usually valid for Scrum, it is not the case for the others three statements.

    • First statement: a project is temporary in that it has a defined beginning and end in time

No, Scrum is not temporary. It obviously has a start date, and can have an end date, but it is not necessarily the case. Moreover, it is by design indefinitely sustainable. This is already a pretty strong misalignment.

    • Second statement: a project has a defined scope and associated resources

The scope of a Scrum product is meant to be aligned with user expectations with each iteration. Even if the team should start from an idea of scope or an initial problem to solve, there is no notion of fixing the scope. Once again Scrum differs largely from the definition of a project.

    • Third statement: a project often involves people who don’t usually work together

Most Scrum experts agree to the fact that Scrum gains in predictability and quality when gaining in maturity. Mature Scrum teams are in essence productive teams. Even if at first it can group various skills, a good practice is to share knowledge as much as possible so that most team members are able to work on most items. In short, no, we cannot say that in Scrum people are not used to work together.


Scrum does not fit with most the key concepts that define a project. It could be the end of the story but from another perspective, you can very well setup a Scrum team in a context in which the items above are all true. It is actually pretty common.


When Scrum can be seen as a project management methodology

On principle, as defined above, Scrum is not a project management methodology.

However, if as a company you decide to fix a global scope or vision and a time-frame to try out a new idea, it is a project. And among the different methodologies you can choose from, Scrum is off course a valid option.

This creates confusion for many. I believe this is the source of many misunderstandings.


Why is it a problem

Well, is it only a wording question? After all, it does not matter much to decide if yes or no Scrum is this or that. As long as it helps to get value delivered, who cares?

While valid, this has a drawback: mindset.

Scrum is great but requires a deep change of mindset. It is the #1 failure of Scrum transformation: missing the mindset shift.


Back in the 90s and early 2000, projects were the way to go. Companies run projects for any kind of purpose. Consequently we have a large part of the workforce that believe projects are the way to innovate, and that the project manager is The head, the person who is accountable. If the whole organization expects the same from one person in the Scrum team, there will be disappointment. It will create issues like Scrum master seen as useless or all power. Product owners that can lack some skills as coming from the “project” team. Same applies to “one-year roadmap”, change control boards and all the structures and practices that arose from a project-oriented organization. If those may have had benefits, they will only create impediments on the adoption of Agile and Scrum.


It may as well suggest that project managers are best suited to become Scrum masters, which is not necessarily the best idea.


Project managers as Scrum masters

Now here is the main point. In an organization oriented towards projects, an easy take is to appoint all project managers as Scrum masters. It has the merit to be easy and fast, but that is all.


Obviously, some project managers can accommodate to the new role, but again this will be all about a change of mindset. Scrum is based on team self-organization and autonomy. It is about team and collaboration over one-head syndrome. That may not fit with the temper of some project managers, that have a habit to micro-manage and control all deliverables in their areas.

There are a number of qualities that makes a good Scrum master, and some that are explicitly important for project managers.


Key qualities to move from project manager to Scrum master role

  • Belief in Scrum: this one seems obvious. By experience it is not. Many project managers do not easily accept agile transformation. An example is project managers that think Scrum comes with lack of transparency and predictability, like we discussed here;
  • Involving the team with process definition: Project managers may have a tendency to decide how things are done. For a part Scrum masters has a strong role in in the process. In the end the team needs to like the Scrum process; An example is the Scrum branching model;
  • Belief in self-organization: that is the point of Scrum, and its main value. A project manager needs to have faith in this model to avoid being himself an impediment to it;
  • Recognizes and acts on team conflict: Pretty important and not always the work of project managers. Read our article on Scrum master role on conflict;
  • Encouraging to take ownership: if the Project manager believes that being a Scrum master, he will still be owner of the product or the team, that should be a no-go;
  • Sensitive to the question of sustainable tempo: A fundamental change between a standard project methodology and Scrum is the question of tempo that the Sprint brings. It is potentially difficult for a project manager to accept this change of temporality. That is how we come up with product increments sent to the users every three sprints and milestones in the roadmap…
  • Facilitator: last but not least, Scrum master is about helping the team to produce value. The tasks that he has to do may be surprising to some project managers that precisely avoided this kind of low-level impediment to look at the global picture. Ask your project manager if that is really what he wants.



Scrum is not a project management methodology. Persistent teams should align to a product mode in which Scrum will be well seated to provide its best value. This ambiguity becomes a major issue when we try to transform project-oriented organization into the adoption of Scrum.


Project managers may be good candidates for the role of Scrum master, but the recruiter will need to verify the alignment with Scrum values before.


See what's next

Download our guide "How to grow your agile team"
Scrum hoax #2: a Scrum Master is useless – Conflicts

Scrum hoax #2: a Scrum Master is useless – Conflicts


The role of Scrum master regarding team conflicts

Any activity done in group may create conflicts between individuals.

Scrum, by proposing self-organized teams synchronized by ceremonies and pair-reviews, may bring to the surface conflicts within the team and outside the team. A common thinking is that it relies on the Scrum master to solve these conflicts.  In this article we will review where the role of Scrum master lies regarding conflict resolution.

Many people believe the Scrum master is useless. On the other side of the spectrum, some people believe that he is kind of a manager of the team. Where is the truth?

Last week, there was a conflict between two members in a team that I coach. Apparently the organization, including the team members, were expecting the Scrum master to take care of that conflict. He was not so sure about his role into it. So we discussed about that question: is it the responsability of the Scrum master to solve conflicts in Scrum?

It is common for organizations to miss the soft skills required by the job of the Scrum master. Conflict management is an opportunity to review this part of the role and to see if it is useless.

Conflicts within the team regarding the work to do

This first situation occurs when several people in the team cannot agree at all on a subject that relates to the work to be done.

It can occur on a very large set of topics, from trivial like code formating, to more in depth subject like architectural style, aesthetics, columns definition of the sprint board or branching strategies.

See our article on branching strategies in Scrum if you are in this case.

Under these circumstances, the conflict can block the team to progress. It is then an impediment. It is the role of the Scrum master to help fluidify collaboration and solve the conflict.

Many tools, not specific to Scrum by the way, can be used for this, depending on the situation.

Here are a few techniques, more or less sophisticated:

  • - rediscussing roles and expectations. No, a senior developer should not assign work. Yes, a PO should write understandable, coherent and scoped stories...
  • - getting back to the actual need. Many architecture discussions can be solved by reviewing non functional requirements or product vision with the PO
  • - the technique of the three amigos to add a new perspective to the topic
  • - one-to-one coaching session can be helpful
  • - rationalize the conflict is as well a top priority. Easier said than done, but still required
  • - the help of an expert can be interesting in some cases

In that area, the role of Scrum master as facilitator, oriented towards maximizing team collaboration, will play a key role. Not so useless indeed !

To establish mutual respect and active listening within the team may require sharp soft skills and emotional intelligence on the Scrum master side. It is crucial to get a happy and high performing team.

Scrum ceremonies speed up conflict emergence (and resolution)

As we mentionned, Scrum strongly relies on interpersonal communication to build a product. Many ceremonies are made to enable autoregulation within the team, with peer-to-peer discussions on a very regular basis. It is efficient but if not properly handled, it can lead to bad situations.

Take the example of a newcomer that is not motivated because he feels completly lost in the product. He is not working very efficiently so he does not progress much on what he is working on.

On a regular V-model project, he may have the opportunity to hide a bit the lack of progress. He may keep the problem to himself as he does not feel comfortable in sharing its difficulties. Result is that he will leave the team or that few weeks or months later, someone will realize that planning is at stake.

In Scrum, he will have to stand in front of the team and answer the question of what he did the day before. That again and again every day up to the end of the sprint, ie between 10 and 20 times! This will for sure catch his mates' attention as that situation endangers the team's objectives. And that is great if the setup is good: the team can quickly move to the resolution of the problem and improve the situation of that newcomer: let's work in pair on your story!

In that case, the conflict can be resolved by the team itself thanks to the framework.

When conflicts between team members become toxic

Helping to resolve conflicts that arise during the crafting of the product is one thing. But when toxicity steps in that is a totally different story.

Team members can have strong incompatibilities, far beyond a temporary divergence on the best solution.

This kind of conflict is not only a timebounded impediment of the team, it is a fundamental long term issue in the team and beyond.

In such a situation, the role of the Scrum master is typically to:

  1. Identify the situation as a conflict
  2.  Try to solve with various conflict management techniques (see this good article for example)
  3. Diagnose that the problem goes beyond temporary impediments
  4. Hand-over the problem to a role in the organization that is typically fit for people management (People Manager, HR, ...)
  5. Follow-up the situation and mitigate the impact on the team

Hopefully by applying this simple method the Scrum master will manage to minimize the damages such a conflict may create in the team. Preserving team coherence under these circumstances is a real challenge.

Wrap-up: the Scrum master role facing conflicts

To summarize, we can say that no, the Scrum master does not have to handle all conflicts within the team.

As a facilitator, he has to take care of the potential difficulties team members have to collaborate in the day-to-day life of the team. For that, he has to demonstrate extensive soft skills and should continuously work to setup a good atmosphere.

When things goes beyond the resolution of temporary conflicts, the Scrum master should raise alarms within the organization that a recurring and potentially toxic situation is in progress and should be taken care of.

See what's next

Download our guide "How to grow your agile team"