Communication and Shared Experience


At the time of writing the first edition, I didn't fully appreciate the harmony between the idea of "communication as touching into shared experience" and the articles in Appendix B by Pelle Ehn and Peter Naur.

(New readers may want to skip this section until they finish reading Appendix B. I am writing this section as though you have read Appendix B and have come back to this point.)

Within the last five years, people first applied the idea of "communication as touching into shared experience" to project documentation. Teams are being more creative in using alternate forms of documentation to serve as markers and reminders for other team members.[1] They are separating what is needed as "reminders for the people who were in the room at the time" from what is needed as "catch-up information for people who were not in the room at the time."

[1] See, in particular, the many examples of project documentation in Crystal Clear (Cockburn 2005a).

This is, of course, very much in line with Peter Naur's article "Programming as Theory Building" in Appendix B. Naur describes designing a program as creating a theory of the world (we might say model instead of theory today) and another theory of how the program operates in that world.

To remind someone about a conversation in which he participated, we point into his theory (or model) and point as directly as possible into his shared experience. For this purpose, it is desirable to keep the original, messy, handwritten flipcharts. If we rewrite them into clean computer text, we lose the exact referencing mechanism we want to utilize. It also works out, handily enough, that keeping the original flipcharts is fast and cheap, whereas rewriting them online is relatively time-consuming and expensive. So using the original flipcharts as reminders is both cheap and effective.

However, it is quite different when the purpose is to bring someone else up to the team's current state of understanding (their theory, in Naur's terms). The same messy flipchart that is so effective as a reminder is unlikely to contain the cues necessary for the new person.[2] Most of the time, the team will choose to use a completely different approach to documenting their current state of understanding to help the new person catch up with them. However they approach it, a great deal of information is inevitably lost, just as Naur describes in his article.

[2] Unless, of course, the flipchart is re-createdredrawn, in the same sequencefor the new person as it was for the original audience. Then the new person builds an internal memory of the session rather similar to those who were in the room for the original meeting. I have used this technique on occasion to good effect.

In the second article in the appendix, Pelle Ehn describes the difficulty he and his programmers had communicating with their computer-näive users in the 1970s. Surprising most people (including me), he wrote that complete communication is not necessary:

". . . paradoxical as it sounds, users and designers do not have to understand each other fully in playing language-games of design-by-doing together. Participation in a language-game of design and the use of design artifacts can make constructive but different sense to users and designers" (see page 416).

His insight is relevant again today, when ethnographers and user experience designers still try to understand the work habits of users and from that understanding construct a good user interface. At a time when we work so hard to understand our users, it is good to be reminded that complete communication is not possible. . . but it is also not required. What is required is to play the language-game, acting and reviewing the feedback over and over in never-ending cycles of improving utility.

You can apply the lessons of "touching into shared experience" in your own environment:

  • Watch as people point to an old artifact to remind themselves of something that happened.

  • Watch as they construct something to create a "ladder of shared experience" for a new person.

  • Watch how communication gets missed, understanding is incomplete, but action gets taken anyway. Notice how many times people repeat the cycle of explain-act-discuss before they get to an acceptable level of non-understanding.

  • Notice how people have different tolerances for levels of non-understanding and for the number of times they have to repeat the cycle. Use what you notice to do two things: Raise your own tolerance for repeating the cycle, and (surprise!) raise your tolerance for people who have low tolerances.



Agile Software Development. The Cooperative Game
Agile Software Development: The Cooperative Game (2nd Edition)
ISBN: 0321482751
EAN: 2147483647
Year: 2004
Pages: 126

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net