I've been thinking about courage.
Scott Peck writes:
The absence of fear is not courage; the absence of fear is some kind of brain damage. Courage is the capacity to go ahead in spite of fear, or in spite of pain.
Courage is one of the 4 values of eXtreme Programming. I was struck by how every mention of courage in Kent's book, and also during a short googling session, has a technical rather than a social slant to it:
- Communication supports courage because it opens the possibility for more high-risk, high-reward experiments...
- Simplicity supports courage because you can afford to be much more courageous with a simple system...
- Concrete feedback supports courage because you feel much safer trying radical surgery on the code if you can push a button and see tests turn green at the end (or not, in which case you can throw the code away).
It's sometimes said that Scrum is very good at surfacing problems, making problems visible, and that if we don't deal with these problems it's not Scrum that's failed it's us. Moments of social tension are exactly like that. Tension surfaces, is felt, but isn't held and openly dealt with, and so slowly sinks out of view.
Problems in software are always a mixture of the technical and the social. I think many developers find it relatively easy to be technically courageous but not so easy to be socially courageous. Being technically courageous but not socially courageous is solving the symptoms but not the root-causes. In every case, if you fail to deal with the underlying causes you create a bad self-fulfilling dynamic.
Courage relates to trust. Holding the issue and not letting it sink away feels risky. But if you never take any risks you're not likely to create any trust. Acting when you feel a little scared is what courage is.
Courage relates to congruence. Congruence is about alignment. If you feel X, it's ok to say that you feel X, to sound like you feel X, and to look like you feel X.
Moments of fear can be precious moments. They can become moments of courage.
