The role of a Scrum Master is one of many stances and diversity. A great Scrum Master is aware of them and knows when and how to apply them, depending on situation and context. Everything with the purpose of helping people understand and apply the Scrum framework better.
In a series of blog posts, I will share the 10 different stances I consider to be relevant for the Scrum Master. This blog post is about the Scrum Master as a teacher. I'll describe the definition of a teacher, the theoretical viewpoint and some practical examples of the Scrum Master as a teacher.
What is a teacher?
The most straightforward definition I've found is:
"Someone who helps others learn new things."
Teaching is about imparting knowledge or skills and instructing someone as to how to do something.
Some nice quotes about teaching are:
- "The art of teaching is the art of assisting discovery." - Mark van Doren
- "I never teach my pupils; I only attempt to provide the conditions in which they can learn." - Albert Einstein
- "A good teacher can inspire hope, ignite the imagination, and instill a love of learning." - Brad Henry
The Scrum Master as a Teacher
According to the Scrum Guide, the Scrum Master is responsible for ensuring Scrum is understood and enacted. Scrum Masters do this by ensuring the Scrum Team adheres to Scrum theory, practices and rules[1]. They guide the team back to agile practices and principles when they stray[2]. With teaching, the primary focus for the Scrum Master is the Development team and Product Owner. But the Scrum Master should also ensure Scrum is understood by everyone else involved with the Scrum team.
So what could a Scrum Master teach?
- Teach Agile during the team start-up. In the first week with a new team, I always bring the team back to the heart of Agile and Scrum. I learn them about the why & what of the agile mindset, Scrum framework, XP and Kanban. Although some team members might have quite a lot of agile experience, it's about getting on the same page. Explaining the Agile manifesto and emphasize that product development is based on assumptions: the customer knows what he wants, the developers know how to build it and nothing will change along the way. In reality, the customer discovers what he wants, the developers discover how to build it and thing will change along the way.
- Teach the core of Scrum. Using Scrum can be compared with playing chess. You either play it as its rules state, or you don't. Scrum and chess don't fail or succeed. They are either played, or not. Those who play both games and keep practicing may become very good at playing the games. In the case of chess, they may become Grand Masters. In the case of Scrum, they may become very good development organizations, cherished by their customers, loved by their users, and feared by their competitors[3]. Some teams start using Scrum leaving out some of the parts of the framework. For example, doing a 'daily' standup twice a week, mixing up the different roles, and skipping the retrospective. If the team thinks this is wise to do, that's ok, but the Scrum Master should teach them the consequences and also emphasize they're not doing Scrum.
- Teach the differences between Scrum and good practices. Nowadays, a lot of good practices have become strongly intertwined with the core of Scrum. Teaching the team the differences is useful. Examples of good practices are using story points, doing the daily Scrum standing or using a burn down chart for tracking visual progress. All good practices, but not mandatory considering the core of Scrum.
- Teach the team about creating a shared identity. The team should be aware of the prerequisites of teamwork. What does is take to be a team? What does it mean to be a team? I sometimes ask the team to share some personal experiences they've had with the teams they've been part of. What was the worst team and why? What was the best team and why? A powerful exercise to create a shared identity is setting up a team manifesto[4].
- Teach the team about the importance of the product vision. This is also the part where the Product Owner comes along. Probably the team was created with a purpose, e.g. to build a new product. It's crucial the team knows and understands the vision the Product Owner has with his/her product. The team can only make the right decisions if they understand the purpose of the product. A clear vision basically acts as a lighthouse for the Development team, necessary in difficult times.
- Teach the team about self-organization. As the Agile Manifesto says "the best architectures, requirements, and designs emerge from self-organizing teams." A self-organizing team is a group of motivated individuals, who work together toward a goal, have the ability and authority to take decisions and readily adapt to changing demands. A Scrum Master, as the promoter of Scrum and self-organization, should consider how to help a team work out their problems themselves and offer any tools, trainings and insights on how to best do this[5].
- Teach the roles of the Scrum team. Ask the team to expect that the people around them will completely fulfill their role. Anything less is an impediment[6]. Teach them how the three different roles interlock with each other. The Product Owner wants to build the right thing, the Development team wants to build it right and the Scrum Master wants to build it fast. A great team knows how to balance these different interests.
- Teach the team about impediments. In Scrum, an impediment is anything that keeps the team from being productive. It's the job the Scrum Master to ensure impediments are being removed. The Scrum Master only removes impediments that exceed the self-organizing capabilities of the Development Team. Otherwise it's not really an impediment, just a problem the team needs to fix by themselves.
- Teach the team about visualizing progress. Transparency is one of the pillars of Scrum; it's crucial for inspection, adaptation and self-organization. Therefore the need for visualizing progress is also quite obvious, without it self-correction is quite difficult to achieve. It's up to the Development team itself to choose what to visualize. Visualizing the product- and sprint backlog is a good practice I definitely encourage them to use. But other practices for visualizing progress or improve collaboration are burn-down charts, setting up a board with impediments and improvements, showing the availability of the team members or creating a sprint calendar that shows all the events and meetings.
- Teach the Product Owner about backlog management. The Scrum Master should teach the Product Owner how to create a product backlog, how to order it based on priority, value, risk and dependencies and how to involve the entire team with managing the backlog. I've described some more practices about backlog management in this blog post.
- Teach the organization about Scrum. The Scrum framework can be quite disruptive for some organizations. It causes change that some people might find difficult to cope with. Explaining the purpose of Scrum and the need for some changes is important to create mutual understanding and build a foundation that ensures the changes truly stick.
- Teach the team to have fun! Don't take it all too seriously. Having fun helps to cope with difficult situations, strengthens collaboration and build a healthy team spirit. Therefore ensure having fun is part of a team's daily routine.
These are some examples of what a Scrum Master could teach the Development Team, Product Owner and organisation. For sure this list isn't entirely complete, if you've got any other examples please share them. The most important lesson I've learned is: don't try to teach the team everything up front, give them the opportunity to fail and learn from there own mistakes. Remember: mistakes are the portals of discovery (James Joyce).
[1] http://www.scrumguides.org/
[2] Schwaber, 2004
[3] https://kenschwaber.wordpress.com/2011/04/07/scrum-fails/
[4] http://www.barryovereem.com/the-team-manifesto-the-foundation-every-team-needs/
[5] Scrum a Pocket Guide by Gunther Verheyen
[6] Coaching Agile Teams by Lyssa Adkins