A friend pointed me to this great article from Business Week talking about Ford's new CEO, Alan Mullaly, and some of Mullaly's experiences in trying to change the culture within Ford. I found one paragraph that correlated to some of my past experiences as a software developer:
After a couple of hours on the firing line, Ford's engineers got defensive. Interrupting the testers, they started airing their side of the story in front of the new boss. Sensing that the meeting was deteriorating, Mulally says he handed each one a pad and pen. "You know what? Let's just listen and take notes," he said. The episode was a perfect illustration of what Mulally considers one of Ford's major problems: the tendency of employees to rationalize mistakes instead of fixing them. "We seek to be understood more than we seek to understand," he observes.
Developers have all found themselves justifying certain design decisions in an effort to complete tasks and move on. This is a natural part of the process of software development. But if their focus changes from understanding their users to making their users accept their design, then their software quality tends to suffer. It's a difficult balance to maintain.
I find that following the last two points of the Agile Manifesto would go a long way towards maintaining this balance:
Customer collaboration over contract negotiation
Responding to change over following a plan
What are your strategies for understanding rather than being understood?
