This is the 4th of an 8-part series. Part 3 can be found here.
The Scrum Master as a Teacher
This chapter is about the Scrum Master as a teacher. I'll describe the definition of a teacher, the theoretical viewpoint, and some practical examples of what a Scrum Master should teach.
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. They guide the team back to Agile practices and principles when they stray. 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 teach them about the why and 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 emphasizing 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 things will change along the way.
Teach the core of Scrum. Using Scrum can be compared to 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. 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 practicing 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 burndown 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.
Teach the team about the importance of the product vision. This is also the part where the Product Owner comes in. The team was likely 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 make 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, training, and insights on how to best do this.
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. 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 of 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 backlogs is a good practice and one that I encourage. But other practices for visualizing progress or improving 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.
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 builds a healthy team spirit. Therefore ensure having fun is part of a team's daily routine.
This chapter contains some examples of what a Scrum Master could teach the Development Team, Product Owner, and organization. The most important lesson I've learned is: don't try to teach the team everything upfront, give them the opportunity to fail and learn from their mistakes. Remember: mistakes are the portals of discovery (James Joyce).
Some Suggested Readings
Scrum: A Pocket Guide, by Gunther Verheyen.
Coaching Agile Teams, by Lyssa Adkins.