16th Jan 2020

As Agile development and Scrum methodology become more commonplace across the industry, the role of Scrum Master is one that most of us will have come across in one way or another. Some of us will have worked in scrum teams, or attended Agile training courses where we established a good understanding of activities and responsibilities required of the role. Or, you may have come across someone who spent years carrying out their work under the familiar term of ‘Project Manager’, subtly change their email signature to ‘Scrum Master’, following either an invisible superhero-like instant transformation, or a sweeping job title upgrade from the powers that be to demonstrate to all and sundry that their organisation is now “Agile”.

You could try a similar tactic if you get bored of walking round the mean streets of your home town with the humdrum term of ‘pedestrian’ and decided on the somewhat jazzier title of ‘Tight-Rope Walker’ – how different could they be, right, it’s just one foot in front of the other after all? A short spell with the Moscow State Circus would probably provide a painful realisation that in fact there are a few key differences...

The jump from Test Manager or Project Manager to Scrum Master may not be quite as dramatic as average joe schmo street walker to fully-fledged circus performer, but there are still important distinctions. Identifying and addressing these will go some way to establishing a successful Scrum team and ensuring Agile principles become successfully embedded with those team members.

Agile Manifesto

Anyone who’s been on an Agile training course will be familiar with the Agile manifesto and the four main values which I’m fairly sure are: Removing all documentation, Stopping having meetings, Intense micro-managing and Working with constantly changing requirements. Or you may be more familiar with the actual Agile values, which you can find here: http://agilemanifesto.org/.

There are also twelve Agile principles which underpin those values, which will be fairly well-known from training courses, e.g. Frequent delivery of working software, Enable face-to-face interactions, Simplicity, Self-Organizing teams and so on (all found via the Agile Manifesto link above).

Where the Scrum Master earns their corn though, is ensuring those values and principles are present and maintained through the Scrum team’s software development work. It’s often easy to create what on the face of it, is a functioning Scrum team by just following a basic set of processes, such as;

  • Use a Scrum Board,
  • Have a Daily Progress Meeting, or
  • Have a Backlog of Stuff to Work On.

Those processes alone may well be based on Agile or more specifically Scrum thinking, but they don't in themselves make the team Agile if what goes on under those headline activities doesn’t follow Agile values or principles.

But Why?!?

As a father of a 3 year old daughter, I find getting her to adapt to a new form of behaviour can be something of a struggle, and is met with an initial reluctance which can manifest itself in a myriad of unusual and mildly irritating ways. Likewise, Agile or Scrum adoption can also be a challenging proposition, although I’ve yet to come across a scrum team member who repeatedly yells No at me at an ever-increasing volume, or stands arms-folded facing a wall while occasionally turning round to harumph loudly and show a petted lip. It’s still early days in my current workplace though, so I’m not ruling either out just yet.

I look forward to the slightly more advanced stage of being constantly asked ‘but why?’. Although this would seem like a childish attribute, in the context of an Agile/scrum team, this simple trigger for self-examination is an important starting point for assessing the effectiveness of the team’s working practices.

For example, the Daily Scrum; loved and hated in equal measure by developers/testers across the industry, but why do we have it at all? Couldn’t we just send a daily email? The daily scrum ticks a few Agile principle boxes, such as:

  • Collaboration
  • Face to Face interactions
  • Self-organising teams

Standing up, once a day round the scrum board, gives the ideal platform for the team to discuss or demonstrate progress, while agreeing among themselves how to deal with the remaining work in the sprint, and stay focused on the overall sprint goal.

The scrum master’s role is not to run the daily scrum (although they may do this initially while the team find their feet), but merely to facilitate, i.e. make sure it happens, keep it time-boxed to 15 minutes, help identify the issues/blockers and ensure there is ownership for them – either within the team or elsewhere.

Asking ‘but why?’ about any of the ceremonies or tasks within the scrum team should be an easily answered question. If it’s not easily answered, then perhaps that particular practice needs a bit of refinement, or maybe removed altogether. If we look at the main scrum ceremonies/sprint heartbeat meetings:

Why do we have a Retrospective?

– to allow reflection on how to become more effective = continuous improvement

Why have a Show & Tell/Sprint Review

– to gather regular and timely feedback from the Customer or Product Owner

Why have a Sprint Planning session?

- to agree a sprint goal/commitment for the team

Why do I have to wear shoes?

- Think we’re back to my 3 year old again, but the point is ‘Why?’ is a good question to ask, just maybe not every 2 minutes…

Servant Leader

“A servant-leader focuses primarily on the growth and well-being of people and the communities to which they belong. While traditional leadership generally involves the accumulation and exercise of power by one at the “top of the pyramid,” servant leadership is different. The servant-leader shares power, puts the needs of others first and helps people develop and perform as highly as possible."

- Quote from the (Robert K.) Greenleaf Center for Servant Leadership
(https://www.greenleaf.org/)

The key difference between a Scrum Master and the more familiar Project Manager role, can be summed up by viewing the Scrum Master not as a manager, but as a Servant Leader. One definition of Servant Leadership is of “a leadership philosophy built on the belief that the most effective leaders strive to serve others, rather than accrue power or take control”. Sound familiar? No, not to me either, so it’s a definite mindset shift from what most of us from the traditional project management/software development models are used to.

Traditional teams would be based on a structure where one individual would be responsible for planning resources, time/budget management, monitoring progress and reporting etc. In a scrum team, the ‘leader’ (Scrum Master) performs different roles, such as:

  • Representing management to the project
  • Being responsible for enacting Scrum values and practices
  • Removing impediments
  • Ensuring that the team is fully functional and productive
  • Enabling close cooperation across all roles and functions
  • Shielding the team from external interferences

So, the Scrum Master role is one of moulding/nudging/helping, and creating the right environment for success. Understanding these attributes, alongside the principles and values that guide Agile software development, will help anyone involved in working with the scrum methodology to become a more effective team member, and maybe even become a Scrum Master themselves.

For more reading on Scrum and the Scrum Master role, check out the following links: