I have recently read a book called “Change or Die” by Alan Deutschman that has some good insights on how people change deeply held behavior. I like to share some thoughts inspired from (and some outright lifted from) the book.
We spend a lot of time talking about change. We want to become more agile or we want to improve quality or time-to-market. Each one of us has something we want to change about the way we are go about making software. So how do we go about initiating that change?
Most of us take the same approach. We use facts, fear, and/or force. We often start with facts. We find some source who has statistical information or powerful stories about what we want to change and we put that information in presentations, e-mails, and hallway conversations. We expect that those who hear the conclusions of our research and our brilliant analysis will quickly submit to our logic and adopt new ways.
Unfortunately, logic loses.
The reason why logic loses is threefold. First, those who are doing things that are contrary to clear logic (at least our clear logic) have great defenses. These are the classic ego defenses of denial, idealization, projection, and rationalization. The denial defense in software sounds like, “this is just the way that software is done .” People in software development denial did not believe that software can be created any better than the way they are doing it today. Of course, the kind of software they produce is unique and the suggestions, even if the techniques work someplace else, wouldn't work here. Idealization often occurs when the person you're trying to convince helped create the current way of doing things. They can't imagine there being any more perfect way to doing development for their shop than the way they thought of doing it. Projection says that, while there may be problems, it is not the fault of the current way of doing things, it is somebody else's fault. Rationalization suggests that while your idea is good, “they won't let us do that.”
Of course, those same ego defenses of denial, idealization, projection, and rationalization are at work in us too so that our incredibly important change is just as blinded as their stubborn refusal to move on.
The second reason logic loses is that our insightful change doesn't even sound logical. To tell somebody who believes that the world is flat that you can sail around the world doesn't even make sense, it's illogical (I bet you pictured Spock saying that). Each of us has a frame of reference that helps us decide what is true and useful and what is silly and should be ignored. If our beneficial change idea does not fit within the frame of reference of the audience, it makes no sense to them. It is not a logical idea, it is silly talk. One great example of this is the estimation rule of thumb that to decrease the schedule for a software project you often have to increase the estimate. The logic behind this rule has to do with the reality of unplanned rework and is documented elsewhere. However, to somebody who just wants to go faster, lengthening the estimate makes no sense at all.
Just as in the first instance, if their ideas are outside our frame of reference, they sound like a madman.
The third reason is that, by my estimate, roughly 1/2 of our ideas are just plain stupid and should be rejected. Not that we think they are stupid at the time. Actually, we think the idea is quite wonderful and it works great “on my machine”, or my work area, or in my ivory white tower. It is more like creating a bit of functionality and not considering any error routines or doing testing. We may think it's done but it is not done-done. When we start promoting half-baked ideas we often end up doing far more harm than good.
Another reason our ideas should be rejected is when we approach the change with an all or nothing total transformation. “Let us switch from waterfall to agile in one big swoop,” we might say. Or, “Everybody must start doing code reviews immediately!” More often than not, at least in my experience, a quick change over often leads to a quick change back. Rather than flip-flop around, it is best to ignore this change approach.
So if our logic loses, let’s scare them into adopting our change; the fear approach. But fear is simply negative logic and it suffers the same issues as our positive logic. Fear can generate some short term action but it seldom lasts. In Deutschman’s book (remember it from the beginning of the post?) he points out that people with serious heart problems stop taking their medication—medication that they are supposed to take for the rest of their life—within one year. If I am not immediately in fear, if the pain is not currently present, then why change?
Our last trick is force. Make them do it the better way. The, “I told you so,” approach our parents used on us. Did the parental mandate engender genuine change on our part or merely compliance? When out of sight or out of the house, did many of us not actually adopt the very opposite of the ordered direction? Not that software development is analogous to child rebellion but forced change most of the time only lasts while there is an enforcer. Without changing individual frame of references, when the law giver leaves, the golden calf is created.
So how do people change given all these defensive ramparts? That is the subject for a follow-on post and your comments below. Only don’t suggest I am wrong, my ego defenses will put you in the illogical camp :-)