Book Report: Communication Gaps and How to Close Them
I attended a session with Naomi Karten at the AYE Conference last Fall, so I knew she had a lot of good things to teach me. In spite of those high expectations, I was blown away by this book. In fact, the only negative thing I can say is that there’s material for two or three books in here. Having read through it once, I know I’m going to have to re-read it in sections.
None of this information is really new, of course. Learning how to solve communication problems is one of those things I have to learn repeatedly. I already “know” the Satir Interaction and Change Models. I have a passing familiarity with MBTI. I’ve previously encountered Kübler-Ross’ stages of grief. But while I “know” this stuff with my head, Naomi knows it. And she can describe things so simply, using little stories to make the points easy to understand. If only it were as easy to put into practice.
If you’re working on or managing an Agile Software Development team, or want to do so, you owe it to yourself to read this book. I put so many post-it® flags on the pages that it looks like lace. Things like this:
Unfortunately, focusing on the technical aspects of change–to the exclusion of its impact on people–guarantees that your change effort will be an interminable jackhammer of a headache. You can’t effectively manage change without paying attention to the human factors.
How do you deal with the human factors? Build trust. Prepare people. Talk to them. Listen to them. Empathize with their reactions. Involve them in the effort. Explain the experience of change. Reassure them. Tell them what you can–and when you have information that you can’t divulge, say so. Explain the reasoning behind your thinking. Don’t expect immediate acceptance of your ideas. Treat people’s concerns with empathy and respect. Be persistent without being pushy. Communicate early, often, and in multiple ways. In other words, follow the guidelines in this chapter and throughout this book. Above all, use your common sense. It will help you through the rough spots.
This is a fundamental part of adopting Lean or Agile processes. And if you can’t get the “Individuals and Interactions” part right, the technical parts aren’t going to be enough. I cannot stress this too heavily. Dealing effectively with other people is tough for many people in the software business. Often we went into software because computers are a more tractable problem. But no matter how cool our tools and processes are, the real issues are people issues.
> But no matter how cool our tools and processes are, the real issues are people issues.
Word.
George,
I could not agree more with your section quoted from Ms. Karten’s book or your comments thereon. That was why I took such sharp umbrage to Dave’s comment as to when TDD should have been discussed. It is attitudes like that, that mark techies as people to be avoided. I keep most of my customers over decades, because I spend the time to know the people and their methods of working.
At the same time that such approaches are essential to the success of ANY project, computer or otherwise, I cannot see that the people on the forum seem much attuned to such niceties. Ron seems only able to repeat that he can solve all problems by sitting down with Chet and starting to program. Maybe, he considers discussions of things such as Ms. Karten’s approach outside the scope of what he wants to discuss.
Since XP is as much a philosophy as it is a programming method or set of techniques, it would seem that philosophical understanding of the process would hold more importance.
You might also find it interesting to know that I have not only read Kubler-Ross, but I have been a hospice caregiver. Some of her stages of dealing with death and dying can be applied to any major change in life or work. That is not to trivialize the difference between the loss of a loved one and changes in a programming environment, but such changes can inspire much deeper emotions than one might suspect at first glance.
If you and your boys would lower your shields a little and actually read what I write, I might actually be able to contribute something. On the other hand, I can hold my own at any level of conversation that is wished, without cursing or using any bathroom humor. If you guys cannot acquire a little equanimity in dealing with some actual criticism, nothing is likely to change very much, and you won’t need to memorize all those lovely stages. Having lived them, memorization is the least of my problems.
Rett,
Thank you for taking the time to visit my blog. I’m not going to get into the details of how Dave and Ron communicate on the XP YahooGroup. Certainly both of them have successes and failures. Certainly I’ve disagreed with both of them at times, and agreed at other times. Certainly I’ve not understood what they meant at times. We’re all human and imperfect.
The relationship between reader and writer is a very unequal one. It does a writer no good to complain that the reader isn’t doing a good job of reading. In fact, the reader has no obligation to do so, or even to finish reading a passage. The onus of successful written communication is entirely on the writer.
The first job of the writer is to gain the reader’s attention, and to hold it, so that the reader reads at all. If the writer wants to challenge beliefs held by the reader, it’s also necessary to build some trust and credibility, lest the reader dismiss the writer’s work out of hand. Credibility is not built by reciting past successes, however. A glowing resume might induce a reader to open a work, but not to give weight to its words. Credibility builds on trust, and trust builds on shared understanding and a common ground. This is the essence of Naomi Karten’s advice on building a foundation for communication. Of course, Naomi communicates this much more effectively than my little synopsis.
I applaud your work as a hospice caregiver. I have known people who undertook such work, and I am in awe. I’m not sure I could handle the emotional stresses.
You are quite right that the stages of grief apply to more mundane situations than death and dying. My trouble is not in memorizing them, but in recognizing them in the day-to-day business world when I’m concentrating on accomplishing some task.
Please forgive me for speculating, but I am wondering if XP and other Agile processes aren’t, perhaps, disrupting your professional world. You have a long career that you value highly. Now this upstart methodology comes along and your deep experience might not be held in as high esteem by others. I get this feeling by reading between the lines of the written word, so it’s quite possible I’m off the mark.
If I’m even close, however, then I would like to find a way to allay your fears. Your experience is as valid as ever. Indeed, the practices of XP generally have roots that are decades old. XP is just a collection of these practices, along with principles and values to guide them, that seem to work quite well together.
And the kids, the young whippersnappers, they don’t seriously value long experience anyway. They have to build their own history of experience before they can do so.