I have been familiar with the Scrum method for developing software for a number of years. Scrum is a simple tool: it defines just a few meetings, artifacts, and roles. So the basic mechanics of scrum are easy to pick up. Using Scrum to its fullest potential, however, requires a much deeper understanding.
One area I have struggled with is the role of ScrumMaster. The basic responsibilities are straight-forward, consisting of activities like facilitating meetings, dealing with impediments, and updating burndown charts. But, like Scrum, it is not a question of what to do as ScrumMaster but how to go about doing it. Over the past few years when I have had opportunities to interact with experienced ScrumMasters, I have noticed that they seem to have a different mindset when it comes to dealing with teams, especially in regards to the Agile principle of self-organizing teams.
So I was excited recently to have the opportunity to take a ScrumMaster course from Mark Levison. I made it my goal in the course to learn more about the mindset of great ScrumMasters and I wanted to share what I learned.
Growing a High Performance Team
One key insight I had came from a comment by Mark that Scrum is a method of growing a high performance team. On the surface, Scrum seems to be about producing a product, and thus it would make sense that the ScrumMaster's goal is to guide the team in creating a great product. But when you view Scrum as really being about building a great team, then the role of the ScrumMaster shifts correspondingly to that of helping the team grow and improve. This is, I believe, at the heart of what being a great ScrumMaster is.
The implication of this is that the ScrumMaster tries to minimize what they do directly and instead helps the team do things for themselves. Below are some examples of doing this that were discussed in the course:
- When dealing with impediments, the ScrumMaster should only directly work on them as a last resort. First, see if the team can handle the impediment on their own. If not, then see if the team can be coached through the resolution. Usually the only impediments that the ScrumMaster will take on themselves are external organizational problems far beyond the scope of the team. For example, if the team is having a problem with how a separate operations team is doing deployments, then rather than the ScrumMaster talking to ops on their own, bring along a team member, introduce them to the ops team, and enable them to work out their issues with ops directly.
- Prefer asking socratic questions of the team instead of telling the team what to do. For example, if the daily scrum is taking too long and is not focused enough, then rather than telling the team what to do raise this issue with the team, perhaps offering some suggestions, and let the team decide what to do.
By helping a team to do things on their own you build up their mastery, and by letting a team make their own decisions you build up their autonomy. Mastery and autonomy are two of the three drivers of internal motivation as per the book Drive: The Surprising Truth About What Motivates Us by Daniel Pink. If you always tell a team what to do and how to do it, they will not only fail to develop initiative but will develop a dependency upon you to provide all the answers, thus losing their innate initiative.
I have heard the ScrumMaster role described as a servant leader. The ScrumMaster does not manage the team nor has formal authority over the team. Instead, they act as a humble steward supporting the team and product owner as depicted in the inverted organizational chart below.
Part of being a good leader is removing obstructions and obstacles from the way of the team and acting as a shield to protect the team from outside interference. This is part of being a ScrumMaster, but there is more to it than just this. For example, Mark described how one method he uses to assess a team is to sit in the team area and simply watch and listen as the team does their work. The following questions provide some examples of things to look for:
- How often are team members interacting with one another? Or do they stay silent in their cubicles?
- Who communicates with who? Do developers only talk to developers, or do they talk to the product owner (or business analyst)?
- What is the tone of the communication? How do testers communicate defects to developers and how do the developers respond? Are people positive or frustrated?
- How many interruptions are there from people external to the team?
This practice struck me as being identical to the Toyota principle of Genchi Genbutsu, translated as "go and see at the place where the work is done".
Teams do not start off as high performing. Only through continual improvement can teams reach this state. Therefore a key responsibility of ScrumMasters is to cultivate a culture of continuous improvement and to encourage ongoing growth. Some tips for doing this:
- Put effort into the retrospective agenda to tailor it to the needs of the team and to adjust the activities from time to time to keep the energy level within the meeting high.
- Follow up on improvements identified within the retrospective to ensure they are actioned.
- When observation of the team indicates that changes are necessary, try suggesting the smallest change that will lead to improvement. Smaller changes cause less resistance and are easier to adopt.
- Encourage lots of experiments. Having the team commit to only trying a change for a limited period of time and then being able to evaluate afterwards whether to keep or discard the change overcomes a lot of resistance and can help cut through a lot of the debate over whether to adopt a change or not.
- Coach team members one-on-one regarding individual needs.
In conclusion, the ultimate objective of the ScrumMaster is to put themselves out of a job by elevating the team to such a high level of performance that they can take over all the ScrumMaster responsibilities.
If you find this article helpful, please make a donation.