Effective Scrum Masters

I make no secret of the fact that I’m a strong agile advocate; I don’t believe software can be developed any other way. In the interests of full disclosure, I should highlight that I said agile, not Scrum, not Kanban, not Crystal Clear in fact not any single process. For true agility in your development process prêt-à-porter is not your friend, you must go bespoke (to use a fashion simile). You build your process based on your business context, and you make sure that it meets your specific business needs and aligns to your business goals.

What’s a Scrum Master for anyway?

That said, there are key elements that I believe must be in place to ensure the effective functioning of your process, one of which is the oft maligned Scrum Master.

Most of the material that I encounter around Scrum Masters are some variation on the ‘Servant Leader’ philosophy. I love this philosophy and would argue that its core principles are pertinent far beyond the role of the scrum master, but I digress.

So far so good, maybe this isn’t going to be one of those contentious posts.

Well, yes, except that in many cases, when I work with organisations their scrum masters have been taught the servant leadership idea with the focus on servant to the detriment of the leadership part. Actually, I get pretty het up about it as it seems to largely end up as an excuse for trainers to educate prospective scrum masters in the policy of ‘non-interference’. Seriously, if you’re going to do the work then do all the work. Scrum Masters, and indeed anyone adopting the servant leadership philosophy, understand that there is a time to facilitate, support and mentor and there’s a time to lead. The diluted form does you a disservice and in no way helps anybody make progress.

Scrum Masters must quickly evaluate the team that they are working with. The agile manifesto, which I’ve spoken on elsewhere, highlights the need for a skilled, mature team. But what if that’s not the case? What if the team is just forming? Or it’s a start-up? Or you’re dealing with an outsource team? In these and innumerable other scenarios a ‘servant only’ scrum master will be weak, ineffective and, in my mind worst of all, will deliver no value. In this situation, you must be the leader until such time as you can be the servant.

Imagine if Alfred let young Master Wayne be the leader when he was young! That’s right, no Batman, just a spoilt child in adult form.

For me, the Scrum Master must:

• Understand and manage the process
  • Also adapt the process to ensure the best outcome
• Ensure team keeps the rules
• Protect the Team
• Create a safe environment for the team to operate
• Encourage productive debate within the team
• Mentor the team to be the best they can by
  • Being accountable to themselves
  • Establishing and meeting Commitments
  • Producing effective, value adding, defined outcomes
  • Don’t allow the team to overcommit where possible
  • Don’t allow the team to under commit
• Remove impediments for the team
• Facilitate meetings leading as necessary, supporting where possible
• Help the Product Manger structure the backlog

With all of that in hand, the Scrum Master must always be conscious of the fact that they have no authority over the team, that they must constantly move the team to self-organise rather than taking over and that, ultimately, they help the team solve their own problems rather than doing the work for the team.

Key Interventions

The Scrum Master is effective every day as a guide and mentor. Strong scrum masters know when to push, when to pull, when to stand back and when to lean in. They do this naturally, usually as a result of hard won experience, but always for the good of the team.

For me, there are three ‘key moments’ where the Scrum Master is at their most effective. Three key meetings where the Scrum Master intervenes with the team to guide them to the most successful outcome. The sprint planning session, the daily stand-up and the sprint retrospective.

Sprint Planning

Through the sprint planning meeting the Scrum Master helps the team build the foundations for a successful sprint. To achieve this goal the Scrum Master must combine their duties of protecting the team and encouraging and mentoring the team.

They protect the team by ensuring that the proposed work is ready for the team. Specifically, has enough work been done leading up to the planning to bring this work in line with the ‘definition of ready’. Has dependent work been planned or already completed? Has enough work been done to explicitly clarify what the team are expected to deliver? Where the Scrum Master is working with a less mature or new team that is not yet strong enough to push back on poorly prepared requirements then the Scrum Master must be the voice, and sometimes the hammer, for the team.

In parallel, the Scrum Master encourages the team to ensure that they are committing to sufficient work to fill their capacity. The Scrum Master must be the voice of reason within the development team, mentoring the team at all stages in the planning process to ensure that the planning session doesn’t overrun the time allocated to the process; that the team is not overcommitting on the work it can realistically deliver nor under-committing resulting in the velocity of the team being questioned.

Daily Stand-up / Scrum

The Daily Scrum, sometimes called the Daily Stand-up meeting is the point in time where the team internally synchronise their efforts. The Scrum Master’s primary responsibility is to ensure that the meeting happens and that everyone has shown up. Remember that this meeting is intended to afford the team members an opportunity to communicate and synchronise with each other, not report to the Scrum Master.

The Scrum Master should facilitate the meeting, ensuring everyone on the team is heard and not interrupted, but also ensuring that the team stays focussed on finishing the meeting within the time-box. During the meeting each participant should answer the three questions: what did I do yesterday; what do I plan to do today and what is in the way of the work being done. The Scrum Master must ensure discipline in the meeting; nobody should be allowed dominate the meeting, no outside parties should be allowed to engage or interrupt – only listen; and no team member should drift into a long explanation that is only relevant to a subset of the team members.

Finally, I would suggest that the Scrum Master should note any meetings that need to take place after the daily scrum and ensure that they take place.

Retrospective

For me, the sprint retrospective is one of the most important meetings in any agile process, not just scrum. The retrospective provides the information required to adjust the process to ensure that it is consistently effective.

There is a danger that this meeting becomes more of a therapy session than staying focused on achieving a positive outcome for the team. If the team is struggling to deal with the simple what went well / what didn’t work questions, then it falls to the Scrum Master to help the team structure their discussion. Borrowing heavily from the world of management theory, the Scrum Master can direct the questions towards the seven ‘S’ model to help the team uncover positives negatives. Asking for feedback in the areas of:

• Shared Vision – or why are we doing this?
  All work should align with the goals of the business.
• Strategy – how are we aligned to the business goals?
  There’s no point in writing new desktop apps if the business intends to move to a combination of web and cloud.
• Staff – do we have the right people in the right jobs?
  Missing people mean work not done somewhere.
• Structure – have we structured the teams in the best way to meet the goals?
  Should the teams be working on a vertical stack, or swarming on features using cross functional squads?
• Skills – do we have all of the necessary skills in the team to deliver on the tasks?
  You might want to use AWS Lambdas with NodeJS, but if all of your staff are COBOL programmers you can imagine there’ll be some challenges.
• Style – are we operating in the best way?
  This often gets missed, but it’s a key element of the Agile Manifesto. Regular, open, face to face communication instead of fire and forget email for example. Self-organising teams versus centrally controlled is a key style question.
• Systems – do we have the right processes, tools and support systems in place that operate effectively?
  Everything from compilers, build tools, source control, testing, Ci and documentation. Similarly, in a sort of self-referential manner, is this very process properly structured?

Not every question requires an answer, but it can certainly help to open the conversation.