Thirty-five years ago, Chuck Tonies and I wrote about the state of software engineering as a basis for what we liked to call the "Effectiveness Formula."  As I reviewed the introduction to our 1979 book Software Engineering for this article, I was struck by the similarity between our description of software engineering in 1975 and the state of the profession today.  As it turns out, the lessons we learned in our software development work are directly applicable to development in any industry. The software development industry, especially within the U.S. Department of Defense (DoD), also collects enormous amounts of data to improve development estimates, and that stockpile provided much of the data behind the Effectiveness Formula.
I have been collecting software cost-analysis data from across the Department of Defense community since 1972, to calibrate a cost- and schedule-estimating model for traditional environments. Within these records, dating back to the 1960s, I noticed a constancy of the capability data for each of the DoD contractors, changing very little over the 20-year period ending in the 1980s.
Most development activities, including software system development, are dynamic. No matter how effective the development methods, and no matter how stable the project staff, some degree of rethinking, replanning, redefining, and redirection are necessary as a project proceeds. Unfortunately, communication among team members is not always perfect. Incomplete and incorrect understanding of requirements, designs, and interfaces is inevitable. Frequent communication among all participants on a development project is the only way to prevent or correct such misunderstandings.
If people are not capable of participating (or are not motivated to participate) in the inevitable ebb and flow of management decisions on a project, or if they can't communicate daily with members of the team, the value of their contributions (no matter how brilliant) is diminished, because those contributions probably don't match the real product requirements.
For those reasons, a person's value to an organization operating in the industrial environment is dependent on three attributes: technical talent, the ability to understand management concepts, and the ability to communicate. All three qualities are so intimately involved in the development process that the net effect of an individual's effort is best represented by the product of the Effectiveness Formula:
E = Net effectiveness (0–1)
C = Communication ability and skills (0–1)
M = Management concept awareness (0–1)
T = Technical ability (0–1)
Notice that M operates on T (technology), and C operates on M. The person's net effectiveness is zero if any of the terms is zero. The formula describes remarkably well the historic software-development project data I've collected over the past thirty years.
Now let's consider applying the Effectiveness Formula to the current traditional development environment, to see how the formula's factors are affected by the environment.
The first rather obvious observation is that most organizations are using similar or identical development technologies. They adopted similar methods and tools at roughly the same time. Each technology improvement offered some capability improvement, even though the capability gains are not strikingly significant.
The second observation is that the management approaches across the organizations are almost identical, all being slight variations of classical management best described as Theory X. 
Broadly defined, communication means the act or process of exchanging information between individuals, using a common system of symbols, signs, or behavior. The related definition of collaboration is working jointly with others, especially in an intellectual endeavor. Both elements, communication and collaboration, are necessary to produce a software product effectively and efficiently.
The most important observation is the norm for physical environments in current traditional development. The most common modern large-scale software development environment is the "cube farm," in which all communication between developers is carried through the organization's computer network. The cubicle development environment is not designed, by intent or by chance, to foster interactive communication among the project participants. Instead, the cube farm's purpose appears to even the casual observer as a means to prevent communication. The lack of effective communication blocks any attempt to motivate the staff, prevents collaboration within the staff, and eliminates the potential for forming teams.
The least common environment, the "skunkworks," is typically defined as a small group of experts who move outside an organization's mainstream operations in order to develop a new technology or application as quickly and efficiently as possible, without the burden of the organization's bureaucracy or strict process application. The skunkworks workspace is a physically open environment that encourages intra-team access and communications. Tools and processes are tailored and adapted to the project's requirements. An Agile environment fits into this type of structure.
The effectiveness of voice or visual communication elements is described in a well-known study by Mehrabian and Ferris.  According to the study, 55% of information is transferred by body language (posture, gestures, eye contact), as shown in Figure 1. Another 38% of the information is transferred through vocal tonality (pitch, volume, and so on), and the remaining 7% of the information transferred comes from the words (content) in the presentation. Removing the visual and vocal information elements of the discussion leaves us with only 7% of the information content. Reading a paper document offers advantages versus reading the same document on a workstation display: Information on paper can be highlighted, underlined, and commented.
Figure 1 Components of communication.
Communication, which has a range of values between zero and (ideally) unity, has an effective value of only 0.07 in a cube farm. With a value that low, even a management effectiveness value of 1.0 and a perfect technology rating (1.0) cannot provide much of a contribution to the person's effectiveness.