CRC Cards And Roles

Sociometric modeling can be based on several varieties of network relationship data. These differences correspond to properties of formal graphs in graph theory. The relationships between roles can be labeled (e.g., with a number that indicates the strength of the interaction) or unlabeled, directed or undirected, and so forth. During the CRC interview, we collected only dichotomous network data: in other words, a relation either exists between two roles, or it doesn't. We take care to capture directed lines to support studies of information flow. A directed line is called an arc, and a graph of arcs is called a digraph. Participants annotate the arcs at the end of the interview, giving them strengths so they become valued arcs.

CRC cards had some unanticipated benefits as well. They can be used as a therapy session that helps an organization introspect about itself in real time. Our CRC sessions usually served as mirrors in which organizations could see themselves in a new light. As such, the data gathering technique itself played out the sociodrama and laid the seeds of group therapy.

CRC cards have some drawbacks as well, including groupthink, consistency, and granularity. Perhaps the most serious problem is the opportunity for groupthink: the tendency for a group to fall into modes of social conformity [BibRef-Janis1971]. Most of the organizations we visited had a diverse collection of strong personalities that avoided many of the problems of self-censorship found in organizations dominated by groupthink. We avoided the problems of "mindguards" (those who protect the power holders in the organization from painful truths) by asking that the subject organizations not send process professionals from their organization, since they usually perform a policing function and frown on departures from stipulated practice. Most groups viewed the exercise as an opportunity to help their self-improvement efforts, and didn't seem to be blind-sided by illusions of invulnerability. We observed rationalization-based groupthink in some groups that participated in these studies because they perceived an allied group — such as the organization that created or managed their development process--as an "enemy". While we feel these factors would have affected our results if we were explicitly looking for process compliance, we don't feel that it affected our models of role relationships within these organizations. For more on groupthink, see [BibRef-Janis1971].

The second problem is consistency. Each group has its own culture that colors the meaning of common role names: Is it fair to compare the "Developer" role in a start-up company to the role of the same name in a legacy organization? Is there a commonly understood meaning for "role" itself? Different organizations produce different products that solve problems of widely varying difficulty: Is it fair to compare otherwise similar teams if one produces aerospace software and the other produces biomedical engineering control software? Such problems plague most software studies; the number of control variables is large.

Granularity is another issue. A complete understanding of process incorporates roles, actors, artifacts, and other dimensions; we are focusing on roles. It is difficult to define a role formally (we "define" them in terms of their responsibilities). A given person may play several roles, and a given role may be played by more than one person. For example, one person might be both a Developer and a Tester, and of course several people may adopt the Developer role. The Pasteur tools (see SocialNetworkTheoryFoundations) has an option to combine selected roles, which helps us evaluate some actor-to-role mappings. The general problems of granularity and mapping remain research issues.