Failure to Convert to Agile
When the decision has been made to transition from whatever non-Agile process is currently being practiced to something that is Agile, an early question is "Who's responsible for making this happen?"
Answer: Everybody, all the time, 100%, no exceptions.
It's the same answer to the question "Who's accountable if the Agile implementation stalls or fails?"
All too often, scrum masters fall into the trap of being tagged as the one responsible and accountable. The bushiest of bushy tailed scrum masters take this on a some sort of noble weight or sacred secular burden to bear in their heroic quest to somehow find a way to make their teams Agile. The underlying assumption that a scrum master is somehow expected to single-handedly transform a team into a high performing Agile machine is an excellent way to pave the road ahead with broken glass. If there is a team, or one or more individuals on a team, that really don't want to shift away from the familiar status quo, they will be more than willing to help the lonely scrum master hoist themselves on their own petard.
Filling the role of scrum master is hard enough, why change a challenge into misery by committing such an unforced error? There is nothing anywhere in Scrum or Agile lore that says the scrum master has this level of responsibility, much less the authority. It is up to the scrum master to make sure the team knows they are responsible for practicing Agile and it is the responsibility of the scrum master to be sure the team has all the knowledge and tools needed to succeed in that endeavor. But if the team proves unresponsive, then the responsibility of the scrum master shifts to working with company leadership.
Before enlisting help from management types, the savvy scrum master will have done a lot of pre-work.
What's the nature of the team's resistance? They're fighting you for a reason. The system is pushing back and the message the team is communicating is vital to your success.
That's the overall level of trust - on the team, between teams, within the company as a whole?
What is the company history of process change? Is the team distrusting and scarred from a long history of management doublespeak and failed strategies?
Set aside the company mission statements and evaluate the culture for yourself. How vigorous is the corporate grape vine and back-channeling? How relevant is favoritism, scapegoating, and backstabbing? Where are the cliques and who controls each of them? Where are the turf war boundaries?
Is the entire management chain fully vested in successfully implementing Agile? What are their expectations and are they realistic?
As the scrum master begins working to enlist management's help, it's important to have a strategy for reshaping the team and move them forward. While it would be grand if everyone knew how to respect a co-worker's vulnerabilities, it's foolish to expect any show of weakness on the scrum master's part will be met with care and compassion. Defensive people don't behave like that. The scrum master needs to be strategic in their display of venerability.
The goal here is to re-establish trust and respect for the role of scrum master. This is vastly different from "being liked." A scrum master that is liked and trusted, but not respected, will fail. A scrum master that is liked and respected, but not trusted, will fail. A scrum master that is trusted and respected, but not liked, will still be effective. It’s been my experience that if teams trust and respect the scrum master, they will also like them. Being liked is a trailing indicator, not an objective. The nature of the scrum master's relationship with the team is exclusively the scrum master's responsibility.
Photo by Majestic Lukas on Unsplash