Why should the ScrumMaster and Project Manager roles be filled different people?

Will a ScrumMaster for a team of 10 be a full time position or can a programmer fill this position if highly trained in agile planning?

Behind those questions is the assumption that the ScrumMaster is not a full time role. The askers of those questions form an opinion or supposition on the basis of incomplete information that you save money by merging two roles or by placing the duty of the two roles on a single person.

The questions are asked by ScrumMaster beginners, by product owners, by team members, by managers, by stakeholders of any kind. From the three roles in Scrum, everyone seems to immediately grasp that being a team member is a full time job – because she develops software all day – and that being a product owner is a full time job – because he develops the product all day, but it seems far beyond imagination what a ScrumMaster’s job could be and why the heck that would be a full time job, too.

Maybe those who ask don’t know what it is that a ScrumMaster does all day long?

Here’s a list of things I’d say are part of a ScrumMasters job:


  • Facilitating meetings for the team. This includes: preparing, moderation, postprocessing
  • Holding retrospectives.

Team Dynamics

  • Coaching team members (e.g. with one-on-one coachings)
  • Mediating through conflicts.
  • Helping the team to make decisions.
  • Fostering the developer team’s self organisation.
  • Mediating the general conflict of goals between development team (high technical quality) and product owner (more features)


  • Continuing learning regarding everything Agile (e.g. visit user groups, attend conferences, read books, write blogs, etc.).
  • Consulting team members regarding everything Agile.
  • Helping the team to create information radiators.
  • Giving feedback to the team.
  • Encouraging the use of Agile Engineering Practices within the development team (this is a huge field to spent a ScrumMaster’s time in, including e.g. one click releases, continuous delivery, feature flags, and many more).
  • Challenge team with Agile management innovations (e.g. FedExDays).
  • Exchanging constantly with other Scrum masters in the organisation (e.g. through community of practice).
  • Doing Gemba Walks.


  • Helping to write or split user stories.
  • Helping to write or adapt product visions.
  • Helping to order product backlog items.
  • Helping with the release planning.
  • Being familiar with the team’s work (i.e. the product).

Big Picture

  • Bringing people together who should talk to each other.
  • Keeping in touch with every stakeholder regularly.
  • Helping the team to report to management.
  • Helping to further the Agile community within the organisation.
  • Organizing exchange events like Open Spaces or World Cafés for the team, its stakeholders, and its organisation.
  • Sharing insights throughout the company (microblogging, blogging, internal conferences, etc.).
  • Being a contact person for everyone in the team and their stakeholders regarding Agile.
  • Giving learning opportunities to people in the organization (e.g. talks or workshops) and letting them learn important Agile concepts like e.g. technical debt.


  • Helping the team to get rid of impediments.
  • Suggesting new metrics for the team as catalysts for change.


  • Reflecting Agile and Scrum values to the team.
  • Reminding the team of their arrangements (e.g. policies).
  • Helping the team to continuously improve their process.
  • Reflecting issues to the team through observation from outside of the team.
  • Asking open questions.
  • Checking all the models the team uses (e.g. Sprint backlog, metrics, etc.) and show them differences between the model and the real world.


  • Helping the team to keep focus (e.g. by acting as a buffer between external distractions and the team).
  • Helping the team to maintain their Scrum tools (Story board, Action board, charts, backlogs, etc.).
  • Helping team and product owner to find a suitable:
    • definition of done
    • definition of ready.


  • Envisioning the future (how the team wants the work to work, next month, next year)
  • Building and articulating a common goal (aka common purpose) for the team (which may morph or change from time to time)
  • Surfacing team values and ethics
  • Helping everyone inside AND outside the team understand the role of mindset in team performance
  • Helping the team improve its social skills, especially wrt constructive conversations.
  • Keeping the team together: protecting the team as a cohesive unit (e.g. from other parts of the business wanting to poach people, or people’s time), even from complete dissolution (aka teardown)

If you’ve are a ScrumMaster & done and/or considered everything mentioned above? Take a break, you must be very exhausted.