Tag: Change

“Blocking”

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. Read More

Efficient don’t work for people.

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.”

Read More

When do we get to the stage where we can tell the client what the answer is?

I saw this question in a blog post by Mark Schenk:

About two-thirds of the way through the workshop one of the students asked “when do we get to the stage where we can tell the client what the answer is?” This literally stopped us in our tracks ““ we were so accustomed to working on the basis that complex problems have no single correct answer that we hadn’t explicitly explained this and we had bumped headlong into a prevailing management mindset.

That question struck a chord. I thought back to the days when I first learned XP. Most of the ideas and practices resonated strongly with me. The one that seemed most foreign, Test Driven Development, became a personal fixture after trying it for three days. Yep, this was the way software development should be done! It was so obvious and right, and I told everyone I knew.

They all immediately agreed and thanked me for the information. Well, not exactly. Read More