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.

Yes, it’s very hard not exclaim about something that excites you. But telling is not teaching. And being so very sure of something leads others to think of you as a know-it-all. If you think that’s OK, search Google and see what other people think. Maybe you’re not as bad as the “difficult people” discussed in those thousands of websites, but maybe the people you want to convince will never continue the dialogue long enough to find out. Perhaps this is the source of strong negative responses to the introduction of Agile Software Development?

Mark refers to Jack Vinson, who refers to Bruce MacEwen, who says,

Finally, leaders need to ask themselves this, confronted with a problem…, what reservations do you have about that course of action? … The reservations enlist genuine support, changing “We’re going to do this so shut up and get on-board,” to “We’re going to do this so long as….” It makes your decisiveness and your vision realistic, in other words. And, surprise, admitting things might not be perfect enlists support. You’re not omniscient, and claims to the contrary alienate rather than attract.

Why does this enlist support? Because it invites participation. It leaves room for the others to offer suggestions and make the solution their own. As Naomi Karten says in Communication Gaps and How to Close Them,

“People who have a role in proposing and supporting solutions are more likely to endorse, promote, and take responsibility for their success or failure.”

You know what? I still think XP is just about the greatest thing since sliced bread. But I don’t think it’s the only effective way to do software development. And in many environments, an attempt to transplant XP as one piece is doomed to failure for many reasons–the “know-it-all” aversion being only one of them.

As I try to help teams improve their software development effectiveness, I still use XP as a guide help me remember what things are really important, and what things are less so. But I try to use examples and questions to encourage interest. And I try to use retrospectives to make that interest take root and grow. And maybe I should give voice to my reservations, too–not reservations about Agile development, but reservations about a particular way or order of changing how things are being done.

What do you think? Am I on the right track, here?

Edit 3/29/2021: fixed some dead links