George Dinwiddie’s blog

There’s been some discussion on the XP Yahoogroup about the practice of “blocking” in order to protect an Agile team in a non-agile corporation. I’d gotten rather behind in my reading, and came into the middle of the discussion. I’ve just now tracked this discussion back to a post by Scott Ambler, where he says,

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. (Continued)

Jerry Weinberg said this a couple days ago (and probably many times before that, but that’s when I heard it). Today, I have a story to illustrate this. I also have a puzzle to solve about how I may best avoid this same trap. (Continued)

Ron Jeffries, when someone asks for data to “prove” that XP or some development practice works, is wont to say that the person they’re trying to convince may be asking for evidence, but it’s not likely that the evidence will convince them. (Continued)

Dale Emery wrote a wonderful post about the Prime Directive on the ExtremeProgramming yahoogroup. This blog entry is mostly to prevent me from losing track of Dale’s comments, as is easy to do on a busy mailing list. I want to be able to go back and re-read his words. (Continued)

Over on the ScrumDevelopment yahoo group, a ScrumMaster reported problems getting the Product Owner fully involved in the development process. Part of the problem is that the Product Owner isn’t co-located with the development team. The physical distance will certainly make participation more difficult, and less sure. That’s something to work on.

The Product Owner is not following the “rules” of Scrum, and this is frustrating the ScrumMaster. He’s likely right that playing the game by the rules will benefit everyone. He asks for advice on how to handle the situation. (Continued)

Last week I was corresponding with Esther Derby on the use of the Prime Directive in retrospectives, and how some people express difficulty in accepting it. She followed up that discussion with an excellent post on the topic, where she lists many reasons why someone may be doing their best under the circumstances, though not doing their peak work. When I saw that, I shelved the article I’d been writing on the topic. It’s remained on my mind, however, and I still have a bit to say about it.

Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.

– Norm Kerth, Project Retrospectives: A Handbook for Team Reviews

(Continued)

Esther Derby commented on my Overcoming Resistance entry with an excellent list of reasons why people may appear to be resisting. Thank you, Esther!

She also said

Unfortunately, I hear many people–even those who hope to influence others to change–label people who are “resisting” as clueless, stupid, or selfish. Some would-be change agents attack the motives of the people who aren’t following their ideas, accusing them of wanting to bring the company down.

This may make the so-called change agent feel superior, as he/she belittles people who don’t get his/her wonderful ideas. But it doesn’t help him/her bring about change.

Well, it may make the so-called change agent feel superior, but I’d bet that it’s really an ego defense against feeling frustrated and helpless. Ineffective change agents need love, too.

“Hi, I’m George and I’m a so-called change agent.”

(Continued)

In my post on Overcoming Resistance, I said, “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.”  Besides the Velvet Elvis principle that Don Gray describes, there’s another reason why one didn’t come to mind.

You see, actually listening to people doesn’t work in a big, noisy way like that.  Instead, it’s a quietly effective activity that doesn’t call attention to itself.

When was the last time you said, “Boy, I really listened to her, didn’t I!” Hmmm…  Doesn’t have the same verbal punch as “Boy, I really told her, didn’t I!”  It’s just more effective, that’s all.

Esther Derby posted an excerpt of a Management Consulting News interview with Jerry Weinberg where he answers the question of how to overcome resistance, “Yes. Don’t.” Oh, he says more there, and he can say a lot more on the topic, but that’s enough for the intro to this article.

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. (Continued)

I was asked about how I would mentor people in the context of being the team leader. Tricky situation, that.

On the one hand mentoring people without their request is an instance of what Jerry Weinberg calls “inflicting help.” At best, it’s ineffective. Usually it’s worse.

On the other hand, an organization has a reasonable expectation that the people working there will improve over time. Who better to help a team do that than the team leader? (Continued)