Dale Emery has taught me an enormous amount about using resistance as a resource.
I’m grateful. I use his ideas every time I set foot in a classroom or start consulting with a new client.
In particular, I channel my inner Dale whenever discussing any of the various controversial things I advocate, such as:
The whole team is responsible for testing and quality, not just QA or the designated testers.
If the regression tests aren’t automated and the team is having a hard time finishing all the testing within a sprint, have programmers help execute them.
Do away with traditional (and often punitive) defect metrics like % missed by phase. Focus instead on metrics related to accomplishments: story points completed, cycle time, and test coverage.
In many organizations these suggestions fly in the face of their accepted “best practices.” Such ideas also tread on political toes. So one response I hear a lot is: “That’s a nice theory, but it won’t work here.”
Before learning techniques for reframing that resistance into a resource, I would end up in a position based argument that amounted to the professional equivalent of “Will too!” “Will not!” “Will too!” “Will not!” Not useful.
Dale’s nicer and wiser than I am, so even when I don’t handle the interaction as well as I would like, by leaning on Dale’s techniques, I certainly handle the conversation better than I otherwise would have. (Although I’m far from perfect at this. Sometimes people succeed in pushing my buttons in such a way that I forget everything I know about how to communicate effectively.)
The first thing I need to know is whether the results of doing whatever it is would be useful. So I ask something like:
Do you think this practice could help improve things?
If I hear “No,” as the reply, we have a fundamental and possibly insurmountable difference in perspective. Nothing I can say will make them try the practice if they do not believe there is any value in it.
I can explore their reasoning. I can say, “That’s interesting. Why not?” But if someone flat out does not believe that a practice I advocate will help, and I disagree even after listening to their reasoning, there is a good chance that I will not be able to help them. Further discussion will cause more harm than good. The best thing for me to do is to stop.
On the other hand if I hear “Yes…but…” then we have a different conversation. First I have to understand what follows the “but…” Often it’s:
It won’t work here.
At this point I am tempted to ask, “Why not?”
But I don’t.
“Why not?” won’t get us anywhere. We’ll end up running down a rathole of excuses starting with “our context is different.” (And of course, they’re right. Their context is different. Every context is different.)
So instead of asking “Why not?” I flip it around. I ask:
What would have to change for this practice to work here?
Now we get a list of objections, but each one is framed as a neat little impediment statement.
It would need to allow for this inherent complexity in our situation.
We’d need to allow time for it.
We’d need executive support.
We’d need money in the training budget.
We’d need to get the programmers to buy in.
We’d need the QA manager to agree.
And we can work on each of those impediments in much the same way, following the trail of reasons why this is a nice theory that can’t possibly work in their real world context all the way down to the bottom.
In what way would it have to accommodate the complexity?
What would have to happen in order to make time for it?
What would have to happen in order to get executive support?
What would have to happen in order to get budget money?
What would have to happen in order for the programmers to buy in?
What would have to happen in order for the QA manager to agree?
The answers usually reveal perfectly practical steps. We can talk to the people in a position of authority or influence who can get us resources, training, budget money. We can try a small pilot. We can experiment with variations.
The simple reframe from “Why not?” to “What would have to change?” opens up possibilities. What could have become an argument becomes instead a brainstorming session. The result is a chain of steps we can take to go from where we are now to where we want to be.