That’s a Nice Theory

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.


Subscribe to our e-mail newsletter to receive updates.

7 Responses to That’s a Nice Theory

  1. YvesHanoulle January 21, 2012 at 3:59 pm #

    or ask: how could be make it worse.
    When people are blocked, it might help them to see that they can change the situation. If They can make it worse, there are chances they can also make it better.

  2. J. B. Rainsberger January 21, 2012 at 5:00 pm #

    Classic tactics that, when I remember to use them, serve me pretty well. Thank you for the reminder.

  3. Mohinder Khosla January 21, 2012 at 6:34 pm #

    If you can find out exactly where they are coming from you can make your arguments effective by being in that scenario. You can bend people’s views if you work hard on them where your views are stronger than their. Stronger smell is always overpowering.

  4. Bob Allen January 22, 2012 at 6:26 pm #

    Had heard you speak of Dale’s technique before but not had the pleasure of having it so well laid out. Like so many things from Dale, it sounds intuitively obvious — once it’s explained. Thanks to the both of you.

  5. B.J. Johnson January 23, 2012 at 4:53 pm #

    This is a *classic* technique from just about any kind of psychological or psychiatric therapy routine. It’s actually surprising that more people don’t use it, given its exposure in popular culture because it works really well in many, many situations.

    Thanks for sharing it with us so we can see how it applies in *our* environment!

  6. Sonali January 23, 2012 at 5:55 pm #

    Thanks for sharing this..This is good approach & I could very well relate to the similar discussions/resistance that comes up from team whenever we try to bring any change or improvements.

  7. Lanette Creamer March 4, 2012 at 6:46 am #

    Thank you for the reminder that everything you advocate isn’t controversy free or well known by all businesses. It seems obvious to me, after being on agile teams since 2008, but many people I talk to are just STARTING the agile transition. I quickly forget how new and scary these concepts are.

    It is nice to remember that we need to encourage people who don’t yet have the experience that YES this does work, and it doesn’t lead to bad behavior to trust your technical people. In fact, it leads to more productivity than the stick and carrot ever will. But those who’ve never seen it will need to see it working in their context first before knowing it is real and they can really make this level of change. As a tester, I need to be open to changing perspective, and sometimes that means closing your eyes as an “experienced” person, and seeing through the eyes of a novice for a short time.

Leave a Reply