They don't get it (...well, maybe)

I got a call from an acquaintance, Gloria, who is trying to convince her organization to adopt agile methods.

"I've given them every logical argument I can think of," she said. "They just don't get it. All I get is blank looks. How stupid can they be?"

"They" probably aren't stupid at all.

But they may have a different frame of reference, or a different mental model.

They may value something that isn't considered in Gloria's logical arguments.

They may agree completely with Gloria's argument, but don't see how to get to where she wants them to go.

They may be afraid that if they do what Gloria suggests, their managers will be angry.

What Gloria doesn't get is this: while logic is appealing, it isn't always the most effective tool for persuasion.

Rather than try to win through logical argumentation, Gloria might try understanding:

what other people value
what other people fear
what obstacles other people face
what problems they want to solve.

Interview with Jerry Weinberg

An interesting interview with Jerry Weinberg here, at the Citerus site.

Some excerpts:

Q: You must have seen a whole bunch of ideas, about how to best do software development, grow and die over all those years. Do you see the agile movement as a pendulum swing or is it a move in a new direction?

A: How about a pendulum swing in a new direction? It's a pendulum swing because approximately every decade, there's a fresh movement to "solve the programming problem." High-level languages, structured programming, object-oriented programming, ...

But it's a new direction because it's the first movement to focus largely on social processes rather than purely intellectual ones. For that reason, I believe, it has more hope for success than the earlier movements, each of which made a little progress, then largely ran out of steam before achieving its grand promises.

Of course, agile won't achieve all its grandest promises either, given the conservative nature of human beings, but that's all right. After another dozen decades or so of incremental improvement, we'll begin to see some really fine software development. Well, I shouldn't say "we," because none of us will see them, but at least our great-great-grandchildren will be able to look back at us and laugh at our crude methods.

Q: If you're the J.K Rowling of software development, who's Harry P then?A: Well, first of all, I'm not a billionaire, so it's probably not correct to say I'm the J.K. Rowling of software development. But if I were, I suspect my Harry Potter would be a test manager, expected to do magic but discounted by software developers because "he's only a tester." As for Voldemort, I think he's any project manager who can't say "no" or hear with Harry is telling him.

Promises Involve Self, Other, and Context

I talked to an middle manager recently who promised his VP that his group would deliver a special project for the VP.

Unfortunately, he made a promise on the basis of incomplete information. Once he talked to his group and ran the numbers, it turned out the work he promised will have a negative return on investment. And it's a double whammy: doing the low value work will delay doing higher value work, and cause the group to miss other targets.

But the middle manager refuses to even consider going back to his boss to explain the situation and renegotiate. He gave his word, and he feels his integrity is at stake.

I think he's leaving something out. In standing on "integrity," he's considering self, but not the context or the other people involved. What about the financial integrity of the company? What about the people who have to do the work, and will work overtime to meet other commitments, or experience consequences when they miss other dates?

There's another part of integrity that involves cleaning up your own messes.