That people could ask for, and could accept, the help they need and want.

The first thoughts that prompt ths response are the client inquiries I’ve had that didn’t really go anywhere.  Some of these, of course, had to do with money.  If the client couldn’t afford to hire me, and I couldn’t afford to work for less, then that’s one way that people cannot accept the help they want.

Even if I could afford to work for free, then it probably wouldn’t help them accept help.  People need to have some skin in the game to effectively make changes.  If I work for free, the best I can offer is advice.  And people usually ignore advice. It’s not consulting without the client indicating the value by paying something for it. (I once read a study that showed that free psychological counseling was extraordinarily ineffective, even compared to counseling that cost only a dollar a session.)

So, when a potential client calls me but isn’t prepared to pay (what I consider) a reasonable rate, I wonder how much do they really want to improve their software development organization.  Will they accept the need to slow down enough to learn new skills and behavior?  Will they be willing to do things differently, themselves, in order to reap the benefits they desire?  Often people want the quality and speed to go up, as long as they don’t have to make any changes.

Or they’re willing for other people to make changes. “Teach my developers to do Test Driven Development so they won’t ship bugs.”  This seems like a fine sentiment on the surface–Test Driven Development is, in my experience, an excellent tool for preventing the shipment of bugs.  But I have to ask myself, what’s keeping these developers from practicing Test Driven Development on their own?  If it’s lack of knowledge, then I can help them with a course.

Often there are other forces at play, however, that maintain the status quo even with new knowledge.  Perhaps the organizational culture frowns on people admitting that they don’t already know everything important.  Perhaps bugs, while deplored in words, are not given the same attention in actions.  I’ve seen rushing to ship take priority over shipping good code. I’ve seen heroics to fix a problem be given more accolades than preventing the problem in the first place.  Are people willing to change these behaviors so they may receive the needed help?

Of course, while it’s easy for me to describe these issues in others, I see the same difficulties in asking for, and accepting, help with the thinks I need, too.  I had the pleasure, recently, of working with Dale Emery on an engagement.  You may know Dale as the recipient of the Ward Cunningham Gentle Voice of Reason Award.  One of the things I truly love about Dale is his skill at asking questions.  And when he does, I’m frequently surprised both by the answers he receives and at my recognition, yet again, of my own tendency to make assumptions rather than seek and accept helpful information.

It’s not easy.  And that’s why it’s my wish for the day.

“Don’t worry about that.  Besides, I’m working on these other issues that are more important.”

That response reassured me–NOT!

That response told me that my concerns were not being taken seriously.  In fact, I wasn’t sure that they were even heard.  This was very frustrating to me.

It also reminded me that I’ve done the same thing.

As a software development coach, I’m in the business of helping people to change the way they do things.  Silencing their objections doesn’t help.  Adopting change is a long term proposition rather than a one-time agreement to buy.  If you blow past an objection, it won’t dissipate.  It’ll still be there tomorrow.

Instead, it’s important to really listen to someone’s objections.  Let them know that you’re listening, even if you don’t agree with them.  Perhaps, especially if.  Let them know that you’ve heard them correctly (or, possibly find out that you haven’t).  Dig into the reasons behind the objections they express.

I’ve been working with Dale Emery this past week, and it’s such an instructive pleasure to watch him illustrate this behavior.  I’m such an amateur in comparison, though I’m a long way from where I was.  I’ve taken to wearing a small horn charm, symbolizing an ear trumpet, to remind me to really listen.  It’s my addition to the Consultant’s Tool Kit in Jerry Weinberg’s book, More Secrets of Consulting.  That tool kit is, in turn, based on Virginia Satir’s Self-Esteem Toolkit.

The next time that you want to convince someone of something and they have an objection, do a favor to both of you.  Remember to listen.

This is a great example of something that I call blocking, where you produce the paperwork, attend the meetings, pretend to care, … to make it look as if you’re following the “official process”.

Scott is responding to a mention of the use of PERT on the Polaris submarine project. Scuttlebutt says that PERT was deemed a great success in managing the Polaris project, but in reality the PERT charts were reverse-engineered from more seat-of-the-pants management techniques. As the stories go, this “scientific” management technique wowed the Congressional oversight committees, and such techniques have been the backbone of government contracting oversight ever since.

Scott refers to his Software Development (now Dr. Dobbs) article, “Running Interference.” Now having read this article, I see that the word “blocking” comes from American football, and refers to direct resistance in order that others may “run with the ball” and make forward progress. A long and frequently interesting thread ensued (and continues, at this writing) on the ethics of such blocking. In this article, I’d like to skirt the ethical issue, which ultimately must be decided by each person, and look at some pragmatic aspects.

First of all, note the reported outcome of the Polaris project and PERT. If it is true that the project did not use PERT to manage the project, but merely to keep the project auditors at bay, it’s quite ironic that the end result was strengthening the belief that those with oversight of a project should direct how the project is managed. The long-term effect has been more intrusive auditing, not less.

Perhaps this should not be surprising. If we fool people, we shouldn’t be surprised that they draw some unwarranted conclusions. Would this same principle not apply in the situation Scott describes? If you merely produce documents and attend review meetings of them without any regard to what’s actually happening on the team, won’t this reinforce the belief that such documents and meetings are necessary?

I note that Scott says,

Subterfuge should be a last resort, but if you’ve failed all other attempts (education and communication foremost among them) to combine an agile team with a rigid power structure, blocking may be your only alternative to maintain the agility necessary to reach your goal.

Clearly he’s a little uncomfortable with this tactic, himself, though he doesn’t see it as unethical. What, however, does it mean to say that we have “failed at communication?” Doesn’t this mean that we’ve given up trying to communicate? Otherwise it would be more accurate to say we have “not yet communicated.” In other words, Scott is saying something like, “We’ve tried some things and those things haven’t produced the results we wanted, so we’re going to ignore the spirit of the requests made of us and just meet the letter of those requests. The people asking for these things no longer matter to us. They’re just resisting a change that we know is right.”

I’ve written on dealing with resistant people, before. I quite understand why Scott would suggest going around such people rather than working with them. But I would urge him, as I still need to urge myself, to resist that temptation. Not because it may be unethical, but because it may be counter-productive.

I’m not suggesting that it’s a mistake to produce the documents and go to the meetings that are mandated, even if you don’t find them valuable for progress of the team. Nor am I suggesting that it’s a good idea to give up practices that are working for you just because someone has asked for something different. What I am suggesting is that merely creating the appearance of complying, without attempting to actually comply to the requests, is an uncomfortable zone for me. I would rather take what I find I need to do to be successful and translate it into terms that are comfortable and acceptable to others. Yes, that can take a lot of time and effort. Yes, I may ultimately fail at that effort. But if I fail, have I done any worse than if I consciously fake the effort?

And if I don’t fail, I’ve opened the possibility of real change. If I successfully translate what I’m doing that I think is right into a format that can be understood by the powers-that-be who are demanding business-as-usual, then perhaps I can show them the advantages of what I’m doing.

And are the demands being made really unreasonable? Sure, they may look unreasonable from the point of view of what I know, but I doubt that they’re being made just to be unreasonable. Let’s suspend disbelief for a moment, and ask what would it look like if the request did have value to the requester. What would that value be? What would have to be true for this request to make sense? This understanding is essential for a successful translation. Of course, it is a lot more work than just going through the motions. But when I take the time and energy to do this, I invariably find that the request is not arbitrary, from the point of view of the requester. The request is just a manifestation of what they really want.

I’ve never been a fan of the martial arts, but I’ve learned an Aikido phrase from Jerry Weinberg that’s useful in many situations: “Center; enter; turn.”

Center: be aware of yourself, who you are, and what you want to accomplish.

Enter: be aware of the other. Enter their world and stand beside them, rather than in opposition.

Turn: together with them, turn their energy in a more effective direction.

When I can do that, I’m much more effective than when I try to block them.

You see, I wanted to write an article with a shining example of a time when I didn’t try to overcome resistance, but used it to advantage, instead. The problem was that I found myself in the trap that Don Gray frequently mentions, that when someone tells you not to think about something, you can’t help but immediately think about it. So what filled my memory was a time when I had tried, eloquently and earnestly, to overcome resistance on the part of my client.

The system being developed was a Java J2EE system that had been in production for a number of years. It was the system that the development team had built as they first learned Java. It worked well–a real testament to the skill and care the developers had applied. It was, however, rather difficult to extend and small changes tended to make odd bugs pop up in other places. The short description is that the code was very procedural in nature, rather than object-oriented. There was duplication where blocks of code were copied and modified for new features. There was temporal coupling where dissimilar things were being done in the same place because they needed to be done in the same HTTP transaction. There were code objects that extracted values from data objects, operated on them, and put them back.

I could clearly see that refactoring this code into good object-oriented practice would reduce the complexity, reduce the unwanted coupling that caused unexpected bugs, and reduce the time it took to add new features. I wrote up a description of the types of changes I was proposing and made my pitch to the team. As I talked about making these changes (and making them incrementally, as we added newly requested features), I could tell that they weren’t really enthused by the idea. I poured on the heat of persuasion, describing the benefits in the short term of the immediate features we were developing. The less progress I made, the more enthusiastic I became, scribbling UML diagrams on the whiteboard and building castles in the air as I pointed out the advantages in the long term of making some significant changes we knew were coming down the pike.

I got nowhere but exhausted. I stopped, wondering how I could get these procedural programmers to understand the benefits of object-orientation. I was trying to figure out what to say next when a senior member of the team said, “I don’t think there’s anyone in this room who doesn’t believe you when you say this is a good thing to do. We just don’t know how to get from where we are to what you describe.”

Oh.

I guess I should have asked more questions.

How did I get over this “resistance” to my suggestions? I can think of three distinct ways, demonstration, discussion, and retrospection. The demonstration is focused around what I did, as I provided examples of what I intended and described how I got from the current code to the new code. The discussion is balanced between us, with questions and suppositions and assertions flowing freely in both directions, between peers. The retrospection lay on their shoulders, where I facilitated the discussion while remaining outside of it. They owned what they had learned, where they wanted to go, and what still puzzled them.

What techniques have you used to get across ideas that don’t seem easily accepted?