The Web is full of articles “explaining” what the Scrum Masters’ responsibilities are and how they should help the team to achieve their goals. Unfortunately most of the articles fail to grasp the core concepts of Scrum, and by arguing whether a Scrum Master should or should not be a part of the development team the authors of the articles hint they have no clue what Scrum is.
Yes, the Scrum Master IS part of a team, but he’s part of the Scrum Team, together with the Development Team and The Product Owner(s). SM is the owner of Scrum and he’s the one to make sure both the team and the product owner adhere to Scrum principles. She is the one who works hard to enable, coach the team and by no means manage!
SM is not part of the development team. There are many companies that think they’re doing a great job by rotating the SM role between their developers, but that purely means they haven’t got a clue what the role of SM is, and it is usually richer than most SM job descriptions outline; not reflected in dozens of more lines of job responsibilities, but reflected in the fact that a simple expression “The Scrum Master removes impediments for the team”, or “The Scrum Master helps the team be accountable to themselves” can be only achieved by employing an abundant and robust set of practices.
Finney (2008) points out that as adults, people grow up to have qualities of both a “beat cop” and of a “visionary”. Every so often, there are also people that reside mostly in one category or another. These qualities can especially be well observed in managers and their styles. There are managers that are excited with the power of possibilities (Visionaries), whilst there are managers that are excited with the power itself (Beat cop).
So the key goals of a SM are to help, coach the team to enable the team to self-organize. There are quite a few, confused practitioners that shockingly claim they are “self organizing” or they have successfully “self organized” their team(s). Self organisation is not something the SM can just implement. It may come as a result of a set of practices employed and largely depends on the team members and their qualities.
Let’s see how the qualities of a beat cop vs a visionary map to these of a good Scrum Master.
Visionaries break new ground, while beat cops avoid breaking rules (Finney, 2008).
The SM needs to make sure the Development Team, the Product Owner and all other stakeholders adhere to Scrum values, practices and rules, so in essence, the SM needs to act as a good beat cop. On the other hand though, the SM needs to be inspired by Scrum and find new ways to enable the team and help them in their journey through forming, norming, storming and performing.
Visionaries embrace inspiring scenarios, while beat cops prevent dire scenarios (Finney, 2008).
By helping the team to make their commitment right and by carrying out daily progress check using tools like Burndown Chart etc, the SM tries to prevent a Sprint failure (dire scenario), then again the SM needs to be able to pass the core concepts of Scrum and Lean principles over to the team; still the Scrum Master doesn’t usually carry out a lot of inspirational activities, especially once the team starts performing. Every once in a while the SM may remind of the core values of Scrum and the Lean principles.
Visionaries prefer loose reins, while beat cops prefer more control (Finney, 2008).
The only control that the SM needs to have is of the basic Scrum processes/ceremonies and make sure these are followed correctly and without any compromise. Since the core strength of Scrum is the basic framework that needs to be followed. SM does not have any control over the developers directly and they should never dictate the team’s internal ways of working. In certain situations the SM may suggest the team to look into improving internal practices and suggest tools; however these should never be enforced.
Visionaries need a sketchpad. Beat cops would rather have the rulebook (Finney 2008).
The rulebook of a SM is the set of basic principles of Scrum and any other practices and decisions that the team as a whole decides to follow. The SM-s simply highlights the situations to the team, and the team and the product owner need to decide the appropriate actions together. At times the SM may use a sketchpad to come up with new ways of tracking the team’s progress and highlighting that to the stakeholders, at other times she may come up with tools to ease and optimize certain activities.
Although it seems that the nature of the SM’s responsibilities is more like those of a beat cop more than of a visionary, I definitely think there is more than meets the eye; a beat cop type person is without doubt not the best SM and they need to posses some of the qualities of a visionary. A beat-cop type SM may enforcing the rules well and doing all the necessary calculations and tracking, but lack common sense, on the other hand a strict visionary person acting as a SM will almost certainly fail to have a control over the basic Scrum ceremonies.
In a summary, I believe a right balance is indispensable. A good SM without a doubt is a Scrum enthusiast, follows the common sense and is there for the team, for the product owner and for all the rest of the stakeholders and by no means is the manager of neither the team nor the product owner.
- Finney M (2008), The truth about getting the best from people, FT Press; 1 edition (March 1, 2008)