How pushy should a scrum master be?

Question

My Scrum team has given me feedback that I should not be as dogmatic about Scrum and Agile as I currently am. I should “relax” and integrate more with how the company does things.

I am happy to do this but I am just unsure how relaxed I must get. I thought that Scrum Masters are change agents always pushing for Agile evolution.

Is there a way for me to gauge whether I am taking things too seriously or going to far?

For example if I did the scrum master checklist with the team and we get ticks for most stuff does they mean I can relax a bit more.

Any advice would be helpful.

Answer 1

Invest your engergy in coaching the team rather than pushing them.

If there is resistance to your ideas then you can:

• Try and understand the motivation behind the resistance
• Come up with better constructed arguments for why your approach is better
• Look to find quantative evidence as to why the current approach is not working well

The key here is to make people want to change, rather than telling them to change. This will tend to make the changes you make more likely to persist.

Answer 2

Dogmatic and pushy are probably on the wrong end of the spectrum but you should be an opinionated facilitator of the agreed process.

As a scrum master you are responsible for designing the process that is followed by the team for achieving results. of course this process is tailored and agreed with the team but is led by you.

In my experience too many scrum masters ask the team how they would like to work and end up with ceremonies but not a wholistic process. this is akin to the database developer designing the database by committee, of course they should listen to others and incorporate everyone's feedback but they should also lead with expertise.

Answer 3

There's a difference between being a change agent and being dogmatic about Scrum.

Agile is a set of values and principles related to rapid delivery of value, adapting to a changing environment, collaboration, trust, motivated and self-organizing teams, working at a sustainable pace, technical excellence, reducing waste in the process, and continuous improvement. There are a vast number of methods and frameworks which, when used properly, can support Agile values and principles, and Scrum is one such framework.

Being dogmatic about Scrum may not be helpful in helping your team or the broader organization adopt Agile values and principles. Scrum may not even be right for your context. Taking a Scrum checklist and making sure that your team goes through the motions of Scrum would say little about the organization's ability to be Agile.

I'd tend to agree with your team. It's usually not effective to be dogmatic about Scrum (or any other method or framework). It is best to understand how the company does things today, what problems people in the organization are facing, and how they can apply various practices and techniques to solve those problems. Explaining the benefits, but also the costs, of employing those techniques, and why they are right for the organization, is part of the role of change agent.

Answer 4

If you have to be pushy is because you do not have enough power to change things yourself, do you?

If I can change boards, projects, meetings, documents, why will I push others?

Scrum has to be applied from day one by the Scrum Master and the rest should follow... whoever is not following YOU, the company must do something about them, but you just need to TELL not to PUSH!

You should ask the right questions and let them agree on certain things, they will tell YOU how they want to work.

I do not see a situation where a Scrum Master needs to push unless the company is not open for Scrum.

If the product owner is not ordering task, do not push, just tell at least 3 times that tasks must be ordered, if the PO doesn't do it, then you can talk to management. The same for every part of scrum, meetings, artifacts, etc.

If they don't want to craft a goal for the sprint (pretty usual) make sure they do it during the sprint.

If they don't see benefits in some parts of Scrum, they might be looking for something else like Kanban, Waterfall, etc.

Scrum must not be forced! It should be used wherever can add value.