Less than 10% Information Density!
I left off my last post alluding to the need for conversation as part of the requirement process-continuous, reflective, emergent, and ongoing communication. The conversations in this case are face-to-face discussion amongst the constituents who are tasked with implementing a specific feature or component.
Even more importantly, those conversations need to be skewed towards doing the work-not simply talking about doing the work. They occur while developers are writing and testing their code, reviewing snippets of working design. They occur while testers are testing snippets, small slices of working code, and seeing what works and what doesn’t-providing that feedback to the developers. They occur while the team shows the customer snippets of working code, checking if it meets expectations and providing real-time feedback. And they occur when the functionality is considered complete and checked off as done.
In a 1967 study, Mehrabian and Wiener analyzed the effectiveness and coverage of human communication. In that study, they found that written communication (documentation, email, instant messaging, etc.) only makes up about 7% of the overall information density potential of communication potential. The breakdown follows.
- 7% of the communication bandwidth / potential was in the language
- 38% …was in the Inflexion
- 55% …was in the body language
Now there has been quite heated debate surrounding that study and how it may be applied. That it wasn’t focused on technology information exchange, but rather more emotionally charged communications. However, while I agree that it may be skewed, I also think there’s an important message embedded within it for our technical information exchange.
It’s that written documentation is probably the most error prone and least rich way for humans to communicate. Diagrams, pictures, and models certainly help-raising the bandwidth of the communication. However, the richest type of communication is when we interact face-to-face as teams. Where we can see each other and interact in that richer and higher capacity medium.
From a design perspective, some of my most successful projects were architected or designed collaboratively at the whiteboard and not at a computer. A small group gathered around the board and hashed out the design. We drew alternatives and discussed them-face-to-face. We explored strengths and weaknesses and reacted to what each others’ suggestions or critical points. When we looked back at the project, the entire team felt it was these critical moments of collaborative communication that were an important part of our critical success criteria.
In my last post I als spoke about the nature of the agile requirement artifact – the User Story. Stories are small, terse artifacts, which are left intentionally incomplete.
When an agile team plans a Story, they don’t invest too much time in it up front. Oh, they discuss it to understand the high level implications, but they defer much of the detail to later. They estimate it at a high level, while also deferring implementation details.
When they’re planning the Story for their very next iteration, they ask more questions, but again, not exhaustively. They also break the Story down into tasks for execution, and that helps drive additional conversation. Still, though, they have only explored 30, 40 or 50% of the clarity surrounding the guts of the Story.
It’s when they actually start to work on it that they flesh out the remaining details, usually in small groups. It’s this wonderful strategy of iteratively defining (and refining) your requirements that’s at the heart of agile methods. It’s allowing yourself to not fill in all of the blanks until you learn more…as you go, in a Just Enough and Just in Time fashion.
Now this is all fine, you might say, for small, co-located teams that can actually have face-to-face communication. What happens when you have real-world larger scale teams that are in distributed locations? Can these approaches still work? If there’s enough interest shown via comments that might be where I go next…
More information on the Mehrabian and Wiener study can be found here at http://en.wikipedia.org/wiki/Albert_Mehrabian
Don’t forget to leave your comments below
Robert Bob’ Galen is the President and Principal Consultant of RGCG, L.L.C. Bob has held director, manager and contributor level positions in both software development and quality assurance organizations. He has over 25 years of experience working across a wide variety of software technology and product domains. Bob can be reached at [email protected]