Good ScrumMaster | Bad ScrumMaster

Years ago, Ben Horowitz wrote about Good Product Manager, Bad Product Manager while he was at Netscape. It has remained arguably, one of the most role shaping pieces I have read. If you have not read it, I would.

I started reflecting recently on what I value in a ScrumMaster. As a result, I started searching for something similar for ScrumMasters…I couldn’t find anything. There is great dialog around what the role entails, but nothing so pointed and precise as Ben’s original email to his staff. I decided to write one of my own, based on experiences in trainings, past organizations and SCRUM readings. Let me know your thoughts.

Good ScrumMasters know the framework, the process, the tools and have the insight to adapt them to the team’s needs. A good ScrumMaster is the evangelist of accurate and timely reporting. A good ScrumMaster knows her team’s current progress and expected velocity range, always. A good ScrumMaster is a coach, one who removes impediments, builds the team’s confidence and fights the right fight.

Bad ScrumMasters have lots of excuses. Not enough buy-in from leadership, Product wont listen, I cant manage this many teams, I dont know the business objectives. Mike Cohn doesn’t make these excuses when coaching, neither should a good ScrumMaster.

Good ScrumMasters measure their success with velocity increases, team morale gains, estimate precision increases and project completions — on time and under budget. Good ScrumMasters appropriately plan releases, sprints, and sizing meetings, all with well scoped stories and expectations. Good ScrumMasters coach Product on story writing and take a personal interest in what will be reviewed by the team. Bad ScrumMasters dont review stories until the day of the respective meetings.

Bad ScrumMasters get buried in the “how” with the engineers. Good ScrumMasters recognize they control the process and the “when” of execution. Good ScrumMasters are technical and understand stand-up reports. Bad ScrumMasters let team members labor on beyond their team’s stand up needs. Good ScrumMasters ask what road blocks someone has, because they care. Bad ScrumMasters assume things will get elevated before it’s too late.

Good ScrumMasters embrace change as an opportunity to learn and challenge a team. Bad ScrumMasters cling to processes that worked in the past without consideration for the future. Good ScrumMasters report frequently on sprint progress and check in with Product to ensure scope isn’t inflating. Bad ScrumMasters complain that scope is increasing because process isnt being followed.

Good ScrumMasters have 100% confidence from their teams that they are looking after the team’s interests. Bad ScrumMasters dont care about buy-in from the team. Good ScrumMasters do anything necessary to help the team perform at their peak. Bad ScrumMasters blame the team’s process doubt on the team’s inability to perform. Good ScrumMasters work hard to know each team member’s skills and work style, understanding how they can best contribute to the team’s success. Bad ScrumMasters treat engineers as interchangeable cogs.