Protect the Team
A very important role of the Scrum Master is to protect the team.
This can come in many forms such as uneducated stakeholders or over eager product owners. I have highlighted two things below which I think are important for the Scrum Master to protect the team from.
Complacency
Remind yourself why you initially decided to implement Agile or Scrum, most likely it was so you could get better. Scrum is all about getting better iteratively and persuing continuous improvement. If you measure how your team is delivering now, and in one year and you are still in the same place, then you cannot really call yourself Agile.
Teams usually get to this point of complacency when you have seen some clear improvement in the team. The team had a low velocity, slowly delivering and are now a strong performing, high velocity team. Organizations will often think this is enough, Scrum has done its job and no need to continue doing retrospectives or identifying areas of improvement.
Its fine to celebrate your successes; relish in your improvement, but its never enough that you should stop optimising.
What you also have to remember is that a lot of things change around you in your environment. New technologies emerge, methodologies improve, companies change direction, team members change…
As a Scrum Master, you should ensure that the team always has goals, and is always self-reflecting. Ensure that any goals that are set are high, encouraging and motivating.
Poor Management
One of main adversaries to implementing Scrum is bad management.
It is important for a Scrum Master to protect the team from management dysfunction, so the team can get on with delivery. Its unfortunately a common trait where managers don’t fully understand Scrum or even Agile, let alone the problems it is intended to solve. They use parts that they like, latch on to ‘buzz words’ or even worse, use it to micromanage.
Autonomous, self reliant, independent teams are what makes Scrum work and if management is interfering with that, then as a Scrum Master it is your job to protect them.
As a Scrum Master, if you see any of the following, you definitely need to step in and speak up. Yes, even if they are more senior in the company than you:
- Product Owner insisting on giving the team estimates on how long he thinks the task will take
- Stakeholders insisting that functionality will be delivered by a certain date
- Stakeholders making decisions without consulting the team
- The teams reporting lines (developers reporting to one manager, QA reporting to another) telling the team they need to work on other priorities.
There are many forms of management dysfunction, and in the end you need to ensure that you are not calling something that is not Scrum, Scrum. Managers can taint Scrum by adding things they think are better or prevent the team from doing something that is at least build on the fundamentals of Agile.
If its not agile, don’t call it agile.
Social Media
Please follow me on social media:
