The most common question I am asked at my courses is - what makes a good Scrum Master? I always answer this question with a story from my own experience working with Scrum Masters (good and bad) over the years.
The 2 best Scrum Masters I ever had the pleasure of working with had a lot in common. They were both excellent servant leaders who fostered self-management, supported the Developers and Product Owner and guided their organisations on the path to agility. However, they did this in different ways and came from very different backgrounds.
The first Scrum Master, we'll call him him Joe (as that was his name), was a born technologist. He loved writing code and developing complex software Products. He was the Senior Developer prior to his team adopting Scrum. The organisation had strict budgets and could not (or would not) afford to recruit a Scrum Master. The Scrum Team needed someone to take on the role, and initially there were no volunteers. After some discussion, Joe stepped up to fill the void. He agreed to take on the Scrum Master role, whilst also remaining as a Developer and continuing to be hands on at creating software.
[Scrum Teams] are self-managing, meaning they internally decide who does what, when, and how.- The Scrum Guide
Joe loved writing code and wanted to spend as much time as he could doing this. This could have been a recipe for disaster if he neglected his Scrum Master duties in favour of his other work. Instead it led him to become a true facilitator of self-management for his team, and a highly effective Scrum Master.
Rather than falling into the trap that many novice Scrum Masters find themselves in, where they interpret the "remove impediments" part of the role too literally and feel they need to be the one to solve every problem that is raised, Joe found another way. Joe wanted the Developers to learn to solve their own problems as fast as possible. He was motivated to foster an environment of true self-management within the Scrum Team so they were not over reliant upon him so he could spend as much time as possible writing code.
This was a significant cultural change for the organisation. Up to the point where Scrum was introduced, Developers raised issues to Project Managers who were then responsible for finding solutions. The team wasn't used to being challenged to find solutions to their own problems. They needed help to get comfortable doing this.
Joe was patient and worked tirelessly to make this happen. He resisted the urge to present the team with his own ready made solutions. He knew if he did this they would continue to look to him for answers. They would also be less likely to effectively implement solutions that had been pushed on them by someone "more experienced".
Over time, the Scrum Team learnt to become self-managing. They became more productive as they found solutions to the problems they faced faster. They no longer had to wait for someone else to step in and find an answer for them. They became skilled at using their collective intelligence to solve complex problems.
They still called on Joe as the Scrum Master when they needed him, and he always put his Scrum Master responsibilities first when called. Joe helped them when issues were too tough or were out of their area of influence. As Joe was not overwhelmed by the volume of issues that came his way, he could dedicate time to deal with the truly important stuff and ensure that they were resolved promptly.
The result was that the Developers learnt to self-manage and got better and more efficient at producing software. The Developers felt a greater sense of ownership of their work and enjoyed the additional autonomy to get things done.
Joe was happy as he had coached himself out of a large part of his day to day activities as a Scrum Master, and was free to do what he loved - write and test code as part of the Scrum Team and create valuable and innovative products for the organisation. When he was called on as a Scrum Master, he enjoyed the additional responsibility and variety that the role offered. He was highly effective as a Scrum Master as he enjoyed a high level of respect from his Developer colleagues as he was "one of them" and could "walk the walk" and well as "talk the talk".
In my next post I will tell you about Laurence, an altogether different, but still highly effective Scrum Master.