To understand the social dynamics of the complex processes for developing individual software, it is necessary to analyze in which structures the persons involved and how this involvement affected their work. Damian Tamburri has in recent years identified the relevant social structures in a number of publications, analyzed and graded on their effect. He first distinguishes four basic types: communities, networks, groups and teams. Communities and networks exist primarily outside of the concrete software projects, teams and groups can be found directly in the projects.
In communities something will be shared
Communities are formed to share something: an interest, knowledge, experience. Therefore, these communities are supportive for everyday life, without intervening directly in the daily work. However, developers just know the importance of the role they can play in quickly finding solutions today. For organizations, it may therefore be a productivity gain to give employees the opportunity to participate in Communities. On the other hand, some companies fear rightly, that expertise could drain away, which is a competitive advantage. (This topic I will take up shortly in the discussion of another paper).
An exception to this are communities of practice. Those structures are understood to be working together on open systems, such as in open source projects.
All communities have in common that members can become members quite easily and without access rules, and that they can just as easily leave the community. Decision-making processes are in a community, if at all, only possible by forming an implicit culture.
Networks use technology
The most important feature of a network is to ensure a mutual accessibility. Therefore Tamburri points out that networks are usually bound to technology (e-mail, social media, collaboration platforms). Networks ultimately form the infrastructure for other collective structures. On the other hand, and this is significant for the issue of collective decision-making, networks allow to circumvent or short-cut prescribed and defined decision-making mechanisms, which make up our own research regarding the rationality of the organization, that can be undermined by networks.
Teams and Groups
The real work is done in teams and groups, they will be ever made for the purpose of organizing the project work. Tamburri distinguishes between them, groups are formed independently of the project and in the long term, they provide the framework the work is organized in. Departments, but also the developer and test teams may be counted as groups in this sense. What Tamburri called teams or project teams, are collective structures assembled within the project from the staff to work together to solve a specific task within the project.
Decision making and rationality
For our research at INDAL, from this classification is interesting that each of the various collective structures show a certain kind of rationality in decision making, therefore they may considered as rational actors from the perspective of economic theory to a different extend. Consequently, the description and explanation by economic theories shall be possible for some of them, and for other not. Groups have due to their long-term structur solid cultural rules of decision that can be secured either by authority by persons or by regulations. However, their rationality may be defeated by networks, but also by communities. Teams rarely form collective rationality, as they exist for a short time and the participants often come from different cultures. Their choices are therefore to be considered in terms of economic theory rarely as rational.
Also for the immediate business practice, the results can be used effectively by a systematic analysis of the collective structures that will be carried out within the company and in projects on their base. As a result, weaknesses can be identified and improvements in the decision-making structures can be made.
Tamburri, D., Lago, P., & Vliet, H. (2013). Organizational social structures for software engineering ACM Computing Surveys, 46 (1), 1-35 DOI: 10.1145/2522968.2522971