Roles And Communication

All the world's a stage, and all the men and women merely players: They have their exits and their entrances; And one man in his time plays many parts, His acts being seven ages. 
—As You Like It, act 2, scene 7. 

Within every organization, every person plays one or more roles. We have found that the roles people play are very significant: they are an important indicator of what really happens in the organization. 

Why are roles so significant? 

First, the roles define what is done in the organization. This is more important, and lasting, than how things are done, which is captured in the organization's processes. This what helps shape the organization's identity. It also illuminates the organization's values. 

Second, people identify with roles. You may hear someone say, "I'm a developer," or "I'm a tester." They occasionally may change roles, but there is generally a great deal of stability among roles. People often carry roles from project to project; in that sense, roles are more stable than the projects themselves. It is through these roles that people use their creativity to develop software. 
Third, communication flows among roles, thus information is linked to roles. Information flow is one of the biggest factors in an organization's success — or failure. 

We have learned much about organizations by examining their roles and communication among those roles. Presence or absence of certain roles tells a lot about the project. Occasionally we notice that a role is missing; this may indicate that the organization does not see that role as important. For example, a few organizations have not included "Customer" as a role. One wonders how responsive such organizations are to customer problems. Some organizations have no "Architect" role. And they probably feel that software architecture is unimportant. 

Amount of communication, and to whom, among roles, is significant. A "Developer" role should be well connected to other roles. But a "Manager" role that is too well connected may indicate an overly meddlesome manager. A "System Test" role that has few connections to the rest of the project may spell trouble. It could even indicate that the development organization does not see the value is rigorous system testing — bigger trouble. 

Communication among roles can form groups — cliques, if you will. Sometimes those are optimizations of communication, but other times they are tantamount to social cliques. And such cliques can be very damaging to the organization in a number of ways. We can gain clues as to which they are by examining the particular roles involved in the communication groups. 

Many of the patterns in the patterns chapters describe the characteristics of roles. Some describe communication among roles. Each of these can be vital to the success of an organization.