“Protect the team” is part of the Scrum Masters role on a project. Please note that this post is not a discussion on the rights and wrongs of project setup. Let’s look at what this should and shouldn’t mean in practice….
- The background
The Scrum master is there to maximise the productivity of the team by ensuring the Scrum processes are as effective as possible. They are there to help the team reflect on how they are working and improve.
They protect the team to help the team achieve their sprint goals and achieve this by:
- Keeping the team focussed on their goals.
- Protecting the team from external interruptions that will damage the sprint goal.
- Ensuring that the goals are realistic.
- Protecting the team from itself.
I hope you find little controversy in what I have written here!
- How it can break down
The primary issue I have seen with Scrum masters is when they protect the team from their own delivery team. At its worst I have heard a Scrum master say, “Do you want me to get rid of him”, directed at someone involved in running the project. The chickens and pigs sketch was a primary example of this, it suggested that the “chickens” or non-Scrum team members were not committed to delivery. This created a them and us culture, seeing anyone outside of the team as meddling with progress.
I believe one of the failings of Scrum is not to insist on a big picture or system wide view. When the goal of the sprint takes priority above everything else this can damage delivery overall. Here are some simple examples:
- As a database administrator I need to know how much space the team are likely to need for a test database so I can build it for the next sprint.
- As a the head of security I need to know how the payments engine interface is secured so I can get it certified to go live.
- As a service manager I want to talk through how code quality is being addressed so I can be sure it’s maintainable.
Let’s be pragmatic! In this case I believe it is the role of the Scrum master to help understand and express the impact of the interruption. This can be light touch, it is not to patrol for anyone attempting to talk to the team and get rid of them. This closed view of a Scrum team can damage a project and introduce delays. We also need to be careful with solutions like, “I’ll talk to them and get back to you”, as this can create waste in the form of poor information hand-offs, leading to additional delays.
A good way of spotting this behaviour is when team members start to use the word “management” in a derogatory fashion to describe non-Scrum team members. This re-inforces a them and us culture.
- The solution
As a Scrum master you may wish to minimise interruptions, that’s fine:
- Maybe you ask for a meeting to be scheduled for a later part of the day, if it’s a large subject.
- You could openly accept interruptions just after the stand-up.
- You can ask for non-team members to think carefully about the urgency of their request before interrupting.
These are simple suggestions and I’m sure you can come up with more that fit your situation. What we must avoid is a them and us culture, as a Scrum master help everyone to feel like a team!