The Art of becoming and being a “Scrum Manager”
Yes, this is not a slip of the tongue - the intended term in the title is in fact “Scrum Manager”. So what could potentially turn a Scrum Master into a Scrum Manager, something which most Scrum Masters don’t even realise they are slowly becoming? Is it the things that managers are traditionally tasked with that Scrum Masters are now expected to undertake in order to fulfil their role? Let’s break this down.
If one researches what a Scrum Master is responsible for, one will most likely encounter the following terms:
- Agile process manager;
- One who lives and breathes agile values and principles;
- Servant leader;
- Protector of the team;
- Remover of barriers;
- Change agent;
- Improving the efficiency of the team;
- Encouraging collaboration;
- Coaching on all things Agile.
However, if you were to inspect some of the current roles and responsibilities Scrum Masters are being tasked with you will most likely find a plethora of different things that do not coincide with the traditional list. Let’s investigate what some of these might be:
- Being responsible for the team’s Sprint deliverables;
- Explaining why project deadlines were missed (this is wrong on so many levels!);
- Mitigating (project) risks;
- Managing relationships with stakeholders;
- Approving team members’ leave;
- Being constantly aware of team members’ working hours (clock watching?);
- Scheduling and coordinating of meetings, not just the Scrum ceremonies;
- Being the communicator of any and all requirements (even technical ones) from external sources. As in, “Send this notice of the server decommission to the Scrum Masters and they’ll make sure whatever is required will happen”;
- Being the secretary for the team; i.e. getting any team requirements, be it hardware, software, stationery, refreshments and food catering fulfilled, arranging for office moves, taking minutes at meetings, arranging functions/celebrations, etc.;
- Raising complaints with the relevant parties, and ironing out conflicts between team members, or between teams;
- Ensuring compliance of team members with HR policies such as ensuring that leave is submitted when a team member is not in the office, etc.;
- Managing and communicating production deployments - i.e. arranging all activities around a deployment and communicating relevant info to stakeholders before, during and after those deployments;
- Keeping and communicating up-to-date schedules regarding any kind of required dev standby or testing roster.
I’m pretty sure many Scrum Masters have found themselves doing at least one or more of the above tasks. Also, there are presumably many more responsibilities and tasks which Scrum Masters around the world are currently finding themselves saddled with. These roles may not necessarily be within the scope of what they usually would have perceived or accepted as part of a Scrum Master’s role.
One can clearly see that there is a mismatch between what a Scrum Master traditionally is supposed to bring to the table, and what they are slowly, and probably unknowingly, becoming: managers. The question needs to be asked: should this be allowed, is it healthy, and should Scrum Masters accept these responsibilities even though it may inevitably mean that they will have less time, bandwidth and focus to concentrate on the things that really matter? The things which help their teams continuously improve and become better at being agile? Though one could argue that having the Scrum Master undertake these tasks does, in fact, make their teams more efficient, enabling more flow and should be done.
We all know, and research confirms, that there is a definite difference between project managers and Scrum Masters. There is a reason why people choose to become the one and not the other. One focuses on the project and its delivery, while the other focuses on the team, trying to improve efficiencies and turnaround. Do organisations really believe that taking a Scrum Master and giving them (project) managerial responsibilities is the equivalent of “being agile”? Moreover, are they not selling themselves short of what they really deserve, jeopardising their noble intent of becoming agile and garnering all the benefits? Can those organisations honestly tell the world, their stakeholders, their shareholders, their own people, that they have embraced Agile, simply because they have employed Scrum Masters, yet continue to assign typical project management tasks and responsibilities to them? Or is this an evolution where an organisation aiming to become Agile naturally progresses through? Is the final destination a place where Scrum Masters come into their own and do what they were always supposed to do – incrementally and consistently improve the team’s performance via inspect and adapt?
On the other hand, one could also argue that a Scrum Master should simply accept that they will do whatever it takes to help the team perform at their highest level, whether that includes any of these “managerial” tasks or not. Perhaps we should just ignore this discrepancy between the roles and simply accept that it’s “part of the job”. Maybe the role of Scrum Manager is, in fact, a legitimate one which has evolved out of necessity. If improving our teams’ performance and our organisations’ adoption of Agile means that we will do such managerial-type tasks, then so be it! Let’s give the benefit of the doubt and ask why not? Yet if so, we cannot avoid asking ourselves the following question: are we doing ourselves, our teams, our organisations, and our profession a disservice? Is there a price to pay for becoming and being a “Scrum Manager”?