Questions like the following are coming up quite often when I do Scrum training:
Why should the Scrum Master and Project Manager roles be filled different people? (Quora)
Will a scrum master for a team of 10 be a full time position or can a programmer fill this position if highly trained in agile planning? (Quora)
The theory behind those questions is that the Scrum Master is not a full time job. Those questions askers speculate you’re saving money by combining two roles or putting the responsibilities of the two roles on a single person.
Scrum master newcomers, product owners, team members, executives, all sorts of stakeholders ask these questions. Everyone seems to immediately understand from the three roles in Scrum that being a team member is a full-time job – because it develops software all day long – and that being a product owner is a full-time job – because it develops the product all day long – but it seems far beyond imagination what the job of a Scrum master might be and why the heck would be a full-time job too.
Perhaps those who inquire don’t know what a Scrum Master does all day?
Here’s a list of 42 things that I would say are part of a Scrum Master’s job:
- 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 Scrum Master’s time in, including e.g. one click releases, continuous delivery, feature flags, and many more).
- Challenge team with Agile management innovations (e.g. FedEx-Days).
- Exchanging constantly with other Scrum masters in the organisation (e.g. through community of practice).
- Doing Gemba Walks.
- Facilitating meetings for the team. This includes:
- Holding retrospectives. Retrospectives are special meetings, therefore I count them separately.
- 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).
- 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).
- 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 (micro-blogging, 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.