The reality of the SM role is that companies hire it for the same reason they hire everyone else – i.e. to deliver more value than it actually costs. In other words, people in this position have to get paid and this is hard to justify when neither the company nor the person themselves know what the expectations are, what they realistically have to achieve (to get “paid”) and how that will be measured. This leads to Scrum masters (especially more junior ones without adequate guidance) finding their value in the company on their own and slipping (naturally, without negative connotations) into all sorts of support roles (e.g. SM as assistant or happiness manager of the team).
Yet the reality (in my perception of today’s world) is that such a role is extremely necessary in a company and there is more than enough work for it, independently of the degree of adoption of agile methodologies. It can be, for example, change management at the level of the development department and beyond, feedback and assistance to development teams, mentoring leaders, setting up collaboration with the product managers, facilitating key discussions and workshops in the company (even for top management), conducting retrospectives of projects and entire departments, supporting innovation, guiding the company culture and many more.
Somewhere at the top of the whole issue is the notion (perhaps sometimes even the belief) that the SM/AC is firmly assigned to one or more teams (forming a long-term stable team) and their job is to elevate the agile or other maturity level of that team. The SM then often “settles in” to the team and gets used to it. This long term relationship is the crux of the problem, because over time the SM accepts even problematic areas as status quo and its continued benefit is questionable. Completely absent from this system is asking key questions about contribution, such as if I only had a few hours a week to work as SM or if I only had one month to spend on this team – what would I commit to? And what would I use to determine what to focus on next?
My alternative suggestion (backed up by several years of functioning in the proposed role position) is to change the functioning of the SM role to a more project/contract level. In other words, start thinking of the SM role as a consultant – the contract, its cost, the value delivered. What this might look like in practice:
- Break all the tight ties between SMs and teams and create a new SM team, if we are talking about the development/engineering department then directly or indirectly reporting to the head of development.
- In a joint brainstorming session (attended by the Scrum Master team, their supervisor and possibly other stakeholders), create a prioritized list of topics that are worthy of SM intervention (“contracts”). They can be in development teams, they can be in teams from other departments, or any other – e.g. a change project at the engineering level.
- Determine the time constraints-in other words, what your budget for the contract is and spell out the assignment and how you will evaluate the contract.
- Agree who will take which assignment. The first solution offered may not be the best fit- as a team, consider areas such as investing in SM development or kicking out of the comfort zone (team and SM).
- Periodically (e.g. once a week) refer back to the prioritized list of contracts and update it. Both reactively and proactively, e.g. based on engineering-wide retrospectives.
- When you’re nearing the end of your dedicated time on a team/other engagement and you see the need to continue there, compare it to the prioritized list.
- Once the engagement is complete, it needs to be evaluated – against the success criteria of the engagement and e.g. feedback from relevant stakeholders.
As a result, the perception of the value of the SM role should rise significantly after adaptation to the new system, as there will be limited time available from the teams’ perspective. The goal will be a truly (not on paper) development team that does not need the SM and this will determine the SM approach. It will no longer organize teambuidings and plan different meetings, but will e.g. show the facilitation of retrospectives, then pass on its know-how and finally give feedback to the team members who will themselves lead the retrospective. This may be the end of a job defined by the development team itself and the SM moves on to other work that has been prioritized (perhaps for the first time consciously working with priorities for the role). By rotating teams, the SM has significantly better context of other teams, can transfer working practices or better design solutions. At the same time, this approach improves SM’s skills through different types of work and frequent feedback.
Examples of orders for the SM role:
- helping to stabilize teams when a leader changes or part of the team is new
- mentoring the new team leader on leadership and management skills
- Aligning the team and Product Owner/Manager
- help with the topic of estimating and sprint planning
- facilitating the creation of team vision and values
- “just checking in” with the team after some time to observe and give feedback
- find out the details of something that works in a team, support it, share it with other teams
- facilitating a project retrospective
- deliver training on the basics of feedback to newcomers in the company
- helping to introduce Kanban methodology in another department
- learning Lean approaches and delivering training to the SM team
- …
Whether Scrum Masters get paid or not after that depends on the “value” of the jobs in their backlog. In most cases, they fall organizationally under the head of the development department and primarily work with development teams where they have a direct or indirect impact on their deliverables. Most of the examples of contracts from the above list can then be related to the value delivered by the development teams or the effectiveness of the department as a whole.
The first steps to measuring the value of the SM role can be a very simple evaluation of the teams. Just a traffic light type visualization for each team bulleting what the team is missing to green. Scrum Masters can then focus on these areas in their assignments. An extended version can include a traffic light for defined areas of each team, such as the planning process, collaboration with PO/PM, quality of the continuous improvement process, managerial and leader competencies, and more.
Obviously, some types of engagements are more “cultural in nature” (e.g., from the list above, facilitating a workshop on team visioning or training on feedback basics for newcomers) and their value will be difficult to quantify in exact terms. Here, then, it depends on what (perceived) value the company sees in investing in the company culture and whether it sees it according to the quote “culture eats strategy for breakfast” or not.
To conclude, a few thoughts on what a person in such a grasped SM role should fulfill:
- the ability to stand up to the fact that from the team’s perspective, they are the unpopular one who comes in to change something or has to deliver negative feedback. This requires self-confidence and awareness of one’s own value and contribution
- the ability to observe and deliver feedback accurately
- an endless appetite to learn new things, because in the way of working described above there is something new about every job
