All these questions I keep asking are really the same: "Is change possible?" The answer, of course, is "Yes... but it's unlikely." Even the traumatized would prefer to think of it as a bad dream, and to go back to the way things were, blissfully thinking that everything is working OK. To quote Weinberg again: "People hate change. They really, really hate change."
You may hate your cubicle, but you keep going back to it. If you get kicked out, you try to get back to it or to another cubicle somewhere else. Cubicles are the devil you know, and that culture collects other people who are equally willing to resist change to keep out the uncertainty of the unknown. It's our nature to keep to certainty, and put up with rather a lot of pain to do so.
In the face of human propensity towards sameness, how do we introduce change?
- The change must fit the ability of the team to deal with change. A consultant that shows up and says "you need to adopt (my favorite flavor) of Agile" does not fit my definition of a consultant. [...]
- The change must be introduced subtly, so as not to engage the limbic system. [...] your "primitive brain" is easily frightened and always scanning for changes. The main trick is [...] to introduce changes that are so un-threatening that your primitive brain laughs. For example, I was having trouble flossing. Saying "I'm going to floss three times a day" was a big, frightening change, so the primitive brain goes into flight mode. But I could safely commit to "I'm going to floss once a month" without causing any reaction (the dentist in our group was thrilled). And each time I did floss, it turned out not to be such a big deal, so over time I became a much more frequent flosser.
- The force for change must be steady, to overcome the natural tendency to return to the original resting state. As noted earlier, our impulse when disturbed is to return to our comfort zone (even if it's not really comfortable, but only familiar). So if a consultant shows up and introduces a new technique and then leaves, it seems interesting in theory "but we have work to do" and so it's just too easy to return to what you always do. Even if the consultant helps you restructure your project for the new technique, the minute there's some pressure and you don't know what to do, you'll fall back into your old ways. [...]
venerdì 15 maggio 2009
Bruce Eckel è un consulente software, uno dei migliori, autore di "Thinking in C++", "Thinking in Java", etc. In questo post parla di come gestire il cambiamento. Si riferisce allo sviluppo di software, ma ci da delle lezioni valide in generale: