The human load balancer, human message bus, the secretary, the project manager… A scrum master can be hired to fill many different jobs. But beware: they’re not all equally helpful.
A scrum master can be detrimental to a team when his or her role is misunderstood:
- The human load balancer is constantly looking for the right people to help out in getting the work done.
- The human message bus is constantly moving work from silo to silo.
- The secretary, taking care of all non-programming related tasks.
Such misconceptions can come from previous job experiences, bad presentation by management, or bad explanation by the scrum master his/herself. Of course, the scrum master can also mistakenly be seen as the team secretary (responsible for notes, bookkeeping and setting up meetings) or team manager (responsible for product delivery and HR). In that sense, organisations hire “scrum masters” for a wide variety of jobs, not all of which positively contribute to agility.
It’s easy to misunderstand the role of scrum master. It’s easy for teams, stakeholders and managers to project onto the scrum master those responsibilities they seem are neglected in the organisation. In that sense, a scrum master can work like a magnet of misunderstanding, wishful thinking and organisational debt. Therein lies both great opportunity and great risk.
Stay or go?
Is it better to get rid of a scrum master altogether? In a sense, yes. Having no scrum master around removes any doubt about the need for cross-functional, self-organising teams. To the wider organisation, there can be no mistake that agile software development is about teams, and not about giving old-style project managers fancy new titles. It also sets clear expectations to the team themselves: the organisation expects you to get stuff done, resolve your own impediments, and truly collaborate — both within the team, and without. Remove the scrum master and you’ll see the emperor has no clothes.
On the other hand, no: for many organisations, moving cold-turkey from old-style command-and-control management to self-organising teams with leadership on all levels — but without a single neck to choke when things go wrong — is just too big a step, both for management (afraid of things going wrong) and teams (not used to responsibility). In that sense, it might be better to have a scrum master around to at least get the ball of agility rolling, than to have nothing at all. The scrum master’s ultimate purpose, then, is to remove his or her own job.
What is the scrum master hired to do?
But the scrum master walks a fine line between being perceived as useful to the organisation (“what the hell do you actually do around here?”) and promoting learned helplessness and disempowerment of teams (“I just want to write code, the scrum master can deal with everything else”). All the more reason for any scrum master to critically assess his or her job: what is the job you were hired to do, and what is the job that actually needs doing to move toward business agility?
