The book The Great ScrumMaster by Zuzana Šochová provides lots of ideas to help Scrum masters deal with everyday situations. In the book she describes the #ScrumMasterWay, a concept which explores different levels where Scrum masters are normally acting: MyTeam, Relationship and Entire System.
I did an interview with Zuzana Šochová about why we need Scrum masters, the advantages and disadvantages of combining the Scrum master role with the team member role, how the work that a Scrum master does changes when the team becomes more mature, the three levels of the Scrum master way, which skills Scrum masters need to acquire to become great Scrum masters, why Scrum masters should be working at the system level and how they can do that, and how Scrum masters can use retrospectives to increase positivity. You can read it on InfoQ: Q&A on The Great ScrumMaster.
15 quotes from The Great Scrummaster
Here’s a set of 15 quotes from Zuzana’s book The Great Scrummaster. I’m tweeting these quotes with #ScrumMasterWay:
ScrumMasters aren’t just an additional expense; they create high-performing teams
The ScrumMaster’s role is to support team rather than individual behavior
Great ScrumMasters must be practiced in soft skills and be good listeners
The ScrumMaster’s goal is to encourage self-organization
The ScrumMaster must encourage the team to take responsibility
The Product Owner should never act in the ScrumMaster role. The two roles have conflicting goals
Great ScrumMasters are not solely focused on their teams but are able to build communities across the organization
The ScrumMaster should stay only one step ahead of the team and organization, pulling them out of their habits and customs
Observing, listening, and not interfering are the most important aspects of a great ScrumMaster’s job
Scrum is a mindset, culture, and philosophy, not just a fixed set of practices
The ScrumMaster is never finished with learning
The great ScrumMaster is a leader who creates new leaders out of the people around him
If you as ScrumMaster keep the positivity high, you are halfway to achieving your goal
As ScrumMaster, your job is to improve the culture, empower people, increase motivation, and boost proactivity
Never forget that the great ScrumMaster is, in the first place, a leader
ScrumMasters can be technical team members
Where I support most of the things in the book (you should read it!), there’s one thing where I disagree with Zuzana. She argued that the Scrum master role should not be combined with a technical team member role, where I suggest to let the Scrum master come from the team and don’t have full time dedicated Scrum masters. I have seen many teams where Scrum master activities were done by technical team members which worked out very well, although I have to admit that those were teams were rather mature. Some teams even rotated the Scrum master role among team members.
The Great ScrumMaster is a book that I highly recommend. Some of the other books that I´d also suggest to read if you are a ScrumMaster are Succeeding with Agile, Coaching Agile Teams, and Scrum: The art of doing twice the work in half the time. For more reading, here’s a list of recommended books for ScrumMasters.
I agree with your thoughts that the SM role should come from the dev team, but that also highly depends on the teams skills and the individual(s) “want” to be SM’s. When a company has jumped into Scrum or even LESS, there are so many moving parts I think starting with season full-time scrum masters would likely further the team better initially. That’s been my practical experience.
Jim, thanks for your comment. I agree with you that large scale agile/Scrum transformations can be overwhelming for a part time Scrum master coming from the team. Having an experienced full time Scrum master from outside the team might not be a good solution though. Chances are big that the teams can’t keep up with the amount of organizational change. It doesn’t help if the Scrum master can cope with it, actually it probably only makes things worse as it creates a distance between the Scrum master and the other (yes, other !) team members.
I’d rather go for lowering the amount of change and doing the changes using a pull based agile approach. Then the team, with a Scrum master coming from the Dev team, can maximize the change result by doing things that help them to deliver more value.
Your thoughts on this?