Hero Illustration
Project Manager, Scrum Master, Software Development

Project Manager vs Scrum Master – Unscrambling the Egg

Having decided to build a piece of software to either improve the productivity of your business or to sell into your target market (or both), you will be assembling your development team. Whether that team will be built within your organisation or in conjunction with your Software Development Partner, you have some decisions ahead of you regarding its composition.

Some of these decisions are more straightforward – how many developers with what skillsets will be needed to produce your solution in the timeframe necessary? You will also probably have decided that newer Agile development methodologies like Scrum are the way to go, and to a large extent that will likely be true. But considering the effective management of your Scrum team, you will probably find that there is something of a “holy war” being waged in Software Development circles right now between proponents of “traditional” Project Managers and others committed to the newer role of Scrum Master.

This is essentially a philosophical argument that can quickly become very technical in nature, but is often based on ideal implementations of methodologies (that rarely exist). The aim of this paper is to take a step back from the theoretical, to try to define the Project Manager and Scrum Master roles in the real world, and contrast their aims in your project.

Project Managers

The Project Manager (PM) role existed well before Software Development was even a job, and the responsibilities and knowledge areas required by a qualified PM are very well defined within internationally accepted frameworks such as the Project Management Body of Knowledge (PMBOK), overseen by the Project Management Institute and recognised as standards by the American National Standards Institute and the Institute of Electrical and Electronics Engineers (IEEE).

PMs are generally responsible for applying their knowledge and skills to leading a project all the way from its earliest inception to a successful conclusion. To do this, they apply skills in 10 specific knowledge areas:

  1. Integration Management
  2. Scope Management
  3. Schedule Management
  4. Costs Management
  5. Quality Management
  6. Resource Management
  7. Communication Management
  8. Risk Management
  9. Procurement Management
  10. Stakeholder Management

A PM’s sphere of responsibility obviously overlaps considerably with that of general management but is constant regardless of the particular development methodology/tools employed in a certain development project. PM’s can also have technical software development backgrounds and skillsets, and may even have experience and certification in particular roles associated with one or more methodologies, but in essence, their overriding goals are to maintain the momentum and management (and, therefore, success) of one or more projects and act as a proxy for and conduit to the key project stakeholders.

Scrum Masters

In contrast to the PM role, that of Scrum Master (SM) is a very specific to the development framework known as “Scrum”. Like Project Managers, Scrum Masters have a prescribed training and certification process administered by recognised bodies such as the Scrum Alliance.

Rather than specify knowledge areas, Scrum concentrates on defining the role of an SM within a Scrum team. It is clear, though, that the architects of Scrum did envisage SMs operating with knowledge of project scope, quality (and, perhaps, HR) that would be in common with PMs. According to ScrumGuides.com, a Scrum Master has the following roles within the Scrum team:

  • Leading and coaching the organisation in its Scrum adoption
  • Planning Scrum implementations within the organisation
  • Helping employees and stakeholders understand and enact Scrum and empirical product development
  • Causing change that increases the productivity of the Scrum Team and,
  • Working with other Scrum Masters to increase the effectiveness of the application of Scrum in the organisation.

Strictly interpreted, the Scrum framework has the team operating as an entirely independent unit. The SM is defined as a team member responsible for guiding the team through the processes, but without any level of authority within the team beyond that of the other team members, and certainly none outside of the team. There is no Project Management role for the SM, and no specific responsibilities for cost, risk, schedule etc. The only interaction between an SM and a PM discussed within the Scrum framework is at Sprint Reviews.

A Mix

It is clear that PMs have a much higher-level management role within a specific project (or group of projects) than a SM, but that the SM’s purpose is much more finely targeted at ensuring the operation of the Scrum team and the evolution of the associated processes.

While “pure” Scrum has the SM interacting with the team and Product Owners without the support and authority of a PM, such team structures are still relatively rare in the real world. Scrum teams do not exist in a vacuum, separated from the organisations involved, or business in general.

What is more customary at the current stage of software development is the concept of Agile Project Management. In this mode, the PM still works with key stakeholders to select the correct tools, processes and techniques at the outset of the project, and retains the roles and responsibilities inherent in a PM role. Once Scrum has been selected as the right option, the PM facilitates the creation of a Scrum team, encompassing all of the roles mandated by such a methodology. In this configuration, the PM might select a suitably qualified SM to undertake the roles prescribed under Scrum. They may alternatively elect to directly ensure that the project deliverables are implemented using an incremental, iterative method (like Scrum). This would be perfect in a situation where the PM was also a qualified SM, for example, where they could also assume the role of SM.

For larger undertakings, there is also the option for a single PM to work in a co-ordination role, with a number of Scrum teams working on individual parts of the project. Each team would have its own SM, and, sometimes, even its own Product Owner.


All of this can be a source of significant controversy amongst proponents of differing development philosophies, and some will argue that Scrum is a self-sufficient framework that should not be mixed with other project management approaches without risking its efficiency.

However, others will argue that Scrum is just one of the techniques available to software development organisations and is therefore, a subset of the tools that a PM has available. If the latter is true, then Scrum does not rule out the possibility of integration with other processes and can be implemented in as “pure” or customised way as needed for a particular project.

Mitrais believes that the ideas behind Scrum are powerful. It is a potent framework for getting a team onboard, focussed and creating software. We very much support teams that aim to create Scrum environments for themselves. However, Scrum cannot be learned effectively on a 2 day Scrum Master course! There are a lot of books on Scrum and how to follow Scrum practises, and they all describe how to do it. But they don’t necessarily say how to know if you are doing it right, how to change it to make it right for you and how to evolve it into your environment.

It’s a bit like learning to parachute out of an aeroplane. You don’t care about the theory of aerodynamics, you want to know what to pull and when! Many novice Scrum Masters do just this. They follow the prescribed practises but don’t really know why they are doing it.

Remember “No Rules are Universal (except this one!)”. Every rule requires a context. For example, it is generally a rule that you don’t go round sticking knives into people’s throats. Unless you happen to be a doctor performing a tracheotomy to save someone’s life! All rules are contextual.

Any book (or expert!) that tells you “This is how you develop software” is probably wrong! Because unless that book was written for your team, in your company, doing your project at this particular moment in time, it doesn’t know how you should develop software!

So, given the above, how do you know what to do? You can’t buy in a poundsworth of Scrum! Well try this:

  • Take a small step forward
  • See where that got you
  • Revise your plan
  • Rinse and Repeat


The concept of Scrum is excellent, but in our experience, many implementations of Scrum fall very, very far short of that. Mitrais is often called in to Unscramble the Egg! (hence the title of this article). It takes courage to implement Scrum. It takes courage to say “I know I’m going to make mistakes.”

But that’s the only way you are going to find out what needs to be done. You are going to have to work hard to make sure that those mistakes are small and correctable. It takes courage at the individual level, at the team level and probably most importantly at the organisational level.

Agile is not what you do. Agility is how you do it. When selecting a Software Development Partner, look for one with a practical background in both PMBOK and Scrum, and who is consistently delivering projects using successful blends of these valuable approaches.

Organisations such as Mitrais feature a significant team of experienced Project Managers, another of certified Scrum Masters, and several who are both. This provides the maximum flexibility in creating a team that will provide a successful outcome for your needs.

Contact us to learn more!

Please complete the brief information below and we will follow up shortly.

    ** All fields are required
    Leave a comment

    James Void
    3 years ago

    too long, cant it be explained with more with illustration? pls