The SM is a glue and improvement role… it’s a little difficult to define with bullet list of job requirements. The SM isn’t about scheduling meetings, but actually helping the team get better at those meetings, at delivering and making progress. Often though, scheduling meetings is a useful way to help. Some teams don’t need that help and schedule and prepare for all of the meetings themselves.
The SM doesn’t have the answers (to technical questions or how the team should organize). These answers are for the team to self-organize and figure out. But, the SM should have the right (and sometimes tough) questions that are important to ask. This requires a tremendous level of insight into the whole team, the individuals of the team, and the work.
Facilitate: to make easier, help bring about, Merriam-Webster
The definition of SM I use now is: “To continuously help make easier the teams execution”.
Notice I don’t say how to do this… that’s the trick the SM needs to figure out. Maybe the team needs more story definition, maybe less. Maybe it’s the team needs to learn more frequently, maybe the team is spending too much time in “discovery”.
It is the whole team (the PO, SM, and developer/contributors) that make a prediction/commitment. The PO is focussed on who/what/why both on the horizon and articulating these to the team during sprints. The developer/contributors are focused on the how, right now and with an eye towards the future. The SM is keeping the focus and momentum aligned, within and outside the team, to enable continuous improvement.
Who’s responsible for execution? In Scrum the PO is ultimately responsible for the value delivered, by being responsible for the definition of the work and prioritizing is effectively. The team makes commitments (now called predictions) together. The SM isn’t responsible for “delivering”, but rather for enabling. The SM doesn’t have the authority to command, but must balance and negotiate.
Here is how I would distinguish the role of SM in a few examples:
1) Ensures the team is ready for the meetings, and the team is setup for success in the meeting.
The SM helps to ensure both the PO and the developers/contributors are ready for meetings. This can be a gently reminder or canceling a planning meeting if the PO and/or team aren’t actually ready. During the meeting the SM is helping to make sure the whole team is clear what’s being asked and what decisions are being made, this is the who/what/why/how questions. If something isn’t going quite right (i.e. a Story that isn’t clear enough) then it’s the SM who usually suggests that it be taken out for future review.
2) Tracks and manages the resolution of an issue (like a problem implementing a story).
When something is going awry, it’s the SM that either tracks it or the SM works with a team member who is primary on the issue. The SM should know about all of the issues that are either a) touching outside of the team, b) involve communication with the PO, and c) are internal to team but serious enough to risk a sprint deliverable. Also, the SM should be able to effectively discuss the issue with either the PO or the team – most of the time being able to represent either if the full group can’t talk.
3) Team retrospective and improvement.
During the retrospective it is the SM who sets up the right questions to ask the team so that they can learn the most from the reflection. I call this “holding a mirror” up to the team. This is an example of the SM not having answers… but rather the hard questions. An example might be (relative to a story that was really hard to finish) “Isn’t this the third story in that subsystem that we’ve struggled with?”, or perhaps “Should we review and estimate <future story> because it seems similar to this tough one?”, and then “What should we start doing to help avoid this type of problem in the future?”.
What if the team is failing to deliver? I’d ask the SM what is going on, and I’d expect them to have an answer (at least partial). Then I’d ask the SM what we should do about it (a plan for change that addresses the situation). That plan might not be a solution to deliver everything asked up front, but it should be based on the reality of the team and context. The SM might recommend the team should work on cross-training more, or increase work on test automations, collaborate with another team more, or possibly recommend individuals be removed from the team. The SM would work first to help the team get more reliable/predictable, and them help to enable the team to go faster easier.