Are we really managing other peoples money by sending texts, chatting on IM's and exchanging and parsing emails around?We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
1. Individuals and interactions over processes and tools.
No meetings, no "war room," no big visible charts, no "team daily stand ups for the Scrum Team, no planning sessions, with cards and hand waving on the white board, no customer briefings?
According to Claude Shannon - effective communications is dependent on the channel bandwidth and the symbols sent over that channel.
In the late 1940s Claude Shannon, invented a mathematical theory of communication. His motivation was how to design telephone systems to carry the maximum amount of information and how to correct for distortions on the lines.
His approach introduced a simple abstraction of human communication - the channel. Shannon's communication channel consisted of a sender (a source of information), a transmission medium (with noise and distortion), and a receiver (whose goal is to reconstruct the sender's messages).
Shannon introduced the entropy rate, a quantity that measures a source's information production rate and a measure of the information carrying capacity, called the communication channel capacity. He showed that if the entropy rate, the amount of information you wish to transmit, exceeds the channel capacity, then there were unavoidable and uncorrectable errors in the transmission.
This is intuitive enough. What was truly surprising, though, is that he also showed that if the sender's entropy rate is below the channel capacity, then there is a way to encode the information so that it can be received without errors.
This is true even if the channel distorts the message during transmission. Shannon adapted his theory to analyze ordinary human (written) language. He showed that it is quite redundant, using more symbols and words than necessary to convey messages.
Presumably, this redundancy is used by us to improve our ability to recognize messages reliably and to communicate different types of information. In the study of complex systems today, we view deterministic chaotic processes as information sources and use Shannon's entropy rate, as adapted by Kolmogorov and his student Y. Sinai in the late 1950s, to measure how random a chaotic system is.
Now for Project Management Communication Channels
When we revisit the first agile manifesto statement - individuals and interactions over processes and tools - we can see that the communication channel capacity and the encoded information sent over that channel are critical to the understanding of the message.
So why reduce the channel capacity on purpose. Why restrict the number of symbols that can be sent over that channel (128 characters for example). Why not increase the channel capacity and increase the number of symbols. Face to face, pictures, hand waving, tonal inflections, body language, hands on touchable outcomes that demonstrate progress?
I have a speculation, OK several speculations:
- Those suggesting the "next big thing" is a narrow half-duplex pipe with a limited character set are infatuated with the technology of these gadgets - IM, Twitter, and the like. It's part of their culture. They grew up with these tools. They think everyone will like them.
- The projects they have applied these concepts to are their own projects. IT projects for the most part. They haven't worked construction, defense and space, energy, petrochemicals, pulp and paper. Projects like that.
In these project domains - and those domains where agile has succeeded - face to face, hand waving style communications dominates. Large enterprise IT has the same channel capacity needs. Possibly those 2 to 3 person 3 month projects that make up the vast majority - by count - of IT projects, such a narrow channel communication is effective.
But of course those showing the histograms of the number of projects fail to monetize those projects in the population of all projects. One large flight software program for a major weapons systems, swamps 100's of small 2 and 3 person IT software development projects. It's just bad statistics when such numbers are used
As Dr. Phil might say (had he read Shannon), "how's that - narrow bandwidth - limited character set channel - working for you?"
