Approach to take with resistance from senior team members

A common technique I like to use (some may refer to it as a crutch...) is to think about and ask the simple question "why?".

Regarding your situation, team members are expressing skepticism because similar efforts failed in the past. Well, why did they fail? What were the reasons that things did not progress as intended? Was there buy-in from executive management? Buy-in from the team? Unreasonable expectations? Tendency to revert back to what is comfortable?

One particular strength with Agile is the practice of continuous improvement, and using failure as a learning opportunity. There could be a myriad of root causes for why a previous initiative did not work. It is critical to understand what may have "tripped" it up in the past, so that you, as a Scrum Master, can make these impediments as visible as possible, and then work to mitigate them so your odds of success improve.

Touting the benefits of Scrum/Agile is always a good thing, but Agile adoption is always a difficult path, and it is important to leverage hindsight in all instances to promote learning and improvement, so that the team and the organization can do better in the future.

Good luck.

Kaizen,
While its important to confront resistance, be careful not to create an atmosphere of “us” against “them.” When an employee resists, an effective leader (Scrum master) looks at him / her not as a problem to be solved but as a person to be understood.
I'd like to recommend an article by Jonathan Levene "Overcoming Resistance to an Agile Process Rollout" to you. It can be googled easily. The article contains several cases which are similar to yours. It might be helpful.

> "we tried that before and it didn't work"

As Timothy says, ask "why". In fact, ask "why", "why", "why", "why", "why".

Five times.

The 5 Whys are a technique for root cause analysis. The objective being to find something that does work, and which solves the correct problem.

> or "it doesn't matter if we don't get everything done this sprint."

If that is true, then it is no sprint at all, and the empirical delivery of working product doesn't matter. Nobody cares. So again, "why..."?

Be careful about "why" because it creates immediate confrontation. Consider the two scenarios:

Senior dev "Stand up meetings are useless we should only do them once a week"
Scrum master "Why?"

Now you've questioned his authority on the subject and set the tone of a confrontation.

Senior dev "Because we tried it, i tried it 100 times and I don't really care if you have a scrum master certification or not they don't work"

Now you're back and forth with a type A personality and you will quickly get off topic and find no resolution the the problem.

Maybe a better approach is to ask "How"

Senior dev "Stand up meetings are useless we should only do them once a week"
Scrum master "Ok, I get that. You're not getting much out of stand up meetings. How could we make them more useful to you?"

You haven't challenged any of his knowledge or experience, in fact you're asking for his input from his expertise on what could be done to make them useful. You're guiding him into solving the problems that he's faced with scrum.

Simple example, but just illustrating to be careful with "why" as it is naturally confrontational. "Why were you late again?" as opposed to "How can we make sure everyone attends these meetings, is there a better time?". "Why did you not finish this item that you forecasted?" as opposed to "How can we make sure we don't have this problem in the future?" Etc.

Here's a description of how the Five Why's establish root cause without need for confrontation:

http://www.isixsigma.com/tools-templates/cause-effect/determine-root-ca…

I've spoken with teams and suggested we try Scrum. I usually say that if it does not work, we'll go back to the old way (which we never do).

Well, first is to find out why the previous SCRUM Master left...

There is this story about the war and why so many young new lieutenants fresh from the Academy perished... they were found with a bullet in the back. Why? Because they didn't listen to the members of their platoon. "Storm that hill!"... We've stormed that hill before and we got hammered... lost 30 people." "I order you to Storm that hill!" the young lieutenant says again. "Well, you first!" and then we know what happens... in the back.

So, be careful. There is an interesting article which sheds some good light on esp. the developers in SCRUM:
https://michaelochurch.wordpress.com/2015/06/06/why-agile-and-especiall…

delves a bit in the psyche and why so many are unhappy.

i'd also be very careful with the 5 why approach. It's quite efficient at finding out root causes not solving personal conflicts (that would be too easy). Here it seems like a contentious context not an open-minded

I recommend the wonderful videos/books on non-violent communication, it brings few tips on how to avoid escalating tension in a conflict while still confronting the issues. Basically the Kaizen here is to be good at spotting and phrasing other people's needs and feelings.

There is this story about the war and why so many young new lieutenants fresh from the Academy perished... they were found with a bullet in the back. Why? Because they didn't listen to the members of their platoon. "Storm that hill!"... We've stormed that hill before and we got hammered... lost 30 people." "I order you to Storm that hill!" the young lieutenant says again. "Well, you first!" and then we know what happens... in the back.

Thank you Nicko for that great analogy highlighting the inherent difficulty and resistance associated with command and control behavior.

And as we all know, Scrum is about servant-leadership, collaboration, and self-management. The three pillars of Scrum are around the Empirical process of Transparency, Inspection, and Adaptation. The 5 values of Scrum are Focus, Openness, Respect, Courage, and Commitment.

That is about as far from "command and control" as you can get. :-)

Thanks all for the good advice.

I took the NVC approach, and set up a 1:1 with him. I came at it not from a point of advocacy for Scrum, but listened and tried to empathise with his feelings. Then went to 'how can we solve' mode, eventually encouraging him to bring it up at a retro so we can make a team decision, which is what happened. Better outcome.

I do have concerns though that ultimately if you have a senior member of a team who's constantly vocal about not wanting to follow basic Scrum rules, that the ability for the team to truly self-organise will be reduced. Am I overthinking that?

if you have a senior member of a team who's constantly vocal about not wanting to follow basic Scrum rules, that the ability for the team to truly self-organise will be reduced

Maybe. It isn't a good thing - I will concede that.

In my mind, what is most critical is to understand why the senior member is so dead-set against Scrum.

I recently attended a great meet-up where issues like this were discussed. As a Scrum Master, it is critical for you to read past what is being said, and understand what the motivation is. If someone is "swimming against the stream", what is their end-game? What are they trying to promote or protect? Since this is a senior team member, I can speculate that they are trying to preserve status or authority, and they view Scrum as a challenge to that (just a hunch).

Also, I have recently become very fond of an expression about listening that I've used at times with devastating effect. "Listen to understand, and not to reply." So often, we listen to others while preparing at the same time to respond and engage with the person, instead of simply listening and empathizing with the person. It is a skill that I'm trying to get better in, because it not only allows me to effectively challenge others when I see the behavior in them, but it allows me to really put aside the temptation for command and control behavior (i.e. - preaching, or "locking horns").

Good luck!

"Listen to understand, and not to reply." So often, we listen to others while preparing at the same time to respond and engage with the person, instead of simply listening and empathizing with the person.

I like it! Sounds like it should help in many situations...

I think most of the advice in this thread is very valuable. I just want to add one more perspective. Maybe you should just ignore that person. Not in a vile manner, but just go on with your agenda. And convince slowly the people around you that the Scrum way is the right way. Find followers (your a servant-LEADER) and build trust. Perform great retros, teach the PO to do awesome reviews, motivate people to do backlog refinement with whiteboards and sticky notes etc..
As the offending person doesn't want to stay an outsider, (s)he sooner or later has to confirm. If not, peer pressure will do the job and if still not, the person might not be longer part of the team.

In the end, change-management is a big game of politics. We just don't play it top-down, but bottom-up ;-)