Two Things You Need to Protect Your Team From

A lot has been written and said about the responsibility of a Scrum Master to protect the team.

Examples of protecting the team almost always involve protecting a team from an overzealous product owner who wants more, more, more done in a sprint.

And this is a good example. ScrumMasters do sometimes need to protect their teams from product owners.

But, there are two additional dangers you should protect the team from if you are a Scrum Master.

Management Dysfunctionalities

First, be sure to protect your team from management and organizational dysfunctionalities. As agile--and, in particular, Scrum--have become more popular, it has become more common for managers to use parts of agile or Scrum to micromanage a team.

Empowered, self-organizing teams are at the heart of Scrum. If anyone outside the team is doing anything that affects that and you are the Scrum Master, it is your job--perhaps your duty--to try to fix that problem.

The problem could be a product owner who insists on providing estimates to the team of how long they’ll be allowed to take on each product backlog item. It could be any stakeholder who insists that a certain amount of functionality be delivered by some date without first seeking input from the team (or listening when the team says something is impossible).

Or the problem might be a manager who thinks "As your manager, you need to work on this project” makes a good user story. Or any number of other management or organizational dysfunctionalities.

If your team is suffering from problems like these, talk to whoever is causing it. Yes, even if the person is above you in the organization.

If you cannot fix this problem, fix the related problem of calling something Scrum that clearly isn’t Scrum.

I have been involved with many companies at which Scrum is highly tainted because something that wasn’t even remotely Scrum (or agile) was called Scrum. If management is stopping your team from doing something that is at least essentially agile, don’t let them call it agile.

Complacency

A second thing a great Scrum Master will protect the team from is complacency. Agile is about continually getting better. I don’t care how good a team is today; if they aren’t better a year from now, they’re not agile.

Complacency often appears after a team sees some initial improvement from adopting an agile approach. Team members will notice how improved they are and think that’s enough.

It may be enough that a celebration of the improvements is warranted. But it’s never so much that the team should stop seeking further improvements.

Teams become complacent in pushing themselves to find ways to deliver more value each iteration. They become complacent in seeking out new engineering practices that could make the team even better.

Protect your team from complacency by setting high expectations and encouraging the team to set even higher expectations of their own performance.

If, as a Scrum Master, you can protect your team from management dysfunctionalities and from the team’s own complacency, you will help your team succeed with agile.