C2M: a maturity model for the evaluation of communication in distributed software development

Abstract

Communication is essential in any software development project, particularly those globally distributed where geographical, temporal, and cultural distance may hinder the effectiveness of communication. The challenges imposed by distance often characterize communication as still one of the main drawbacks of globally distributed projects. Therefore, establishing communication processes and practices is relevant to support a team’s work. These processes and practices need to be updated and aligned with the team’s needs. Thus, assessing and evaluating the maturity of such communication processes and practices is paramount. This article presents a Communication Maturity Model called C2M which aims to help organizations identify the maturity of communication-related aspects by providing an approach for revealing what practices need to be improved. The model is composed of 4 levels of maturity (causal, partially managed, managed and reflective) and 4 areas of maturity (people, project, organizational and engineering) which are organized into 15 maturity factors, each factor comprising a set of practices. The model has 58 practices and each has its specific objectives. The model was empirically developed and evaluated in three well-defined phases. In the conception phase, methodological procedures (Tertiary Study, Systematic Literature Review, and Interviews) were carried out in order to gather relevant information for designing the first version of the C2M model (alpha version). Then, in the refinement phase, two focus group meetings were held in two organizations in order to identify how effectively the model attends its purpose. The results led to a second version of the C2M model (beta version), analyzed by a survey with experts who assessed the representation of the third version of the C2M model—omega version (evaluation phase). All results achieved so far suggest that the model can assist in discovering the maturity level of the communication processes and practices in globally distributed projects. Future works will focus on developing a software tool to help with self-assessment.

Introduction

Communication has been a topic of interest in academia for years. Some studies have proposed communication models, such as the Rhetorical Method of Aristotle (Century IV B.C.), the Lasswell’s Model (Lasswell 1948), the Shannon and Weaver’s Model (Shannon 1948), the Newcomb’s Model (Newcomb 1966), the Schramm’s Model (Wilbur 1966), the New Media (Fidler 1997), among others, to explain the communication process’ needs. While some studies are complementary, others are distinct in their structure and scope. In this study, we consider communication to be as described by the Media Richness Theory (Daft and Lengel 1983) and The Mathematical Theory of Communication (Shannon 1948) and Communication Architecture in the Virtual Environment Model (Ferreira and Farias Junior 2014), i.e., a contemporary communicative process mediated by information technologies and cyberspace communication with multiple message senders and receivers. Additionally, we define communication as synchronous and asynchronous exchange of sounds, videos, images, written messages, and information.

Communication is pointed out as one of the main subjects in distributed software development (DSD), also known as Global Software Engineering (da Silva et al. 2010; Britto et al. 2017). It is well known that, in globally distributed projects, the frequency of face-to-face and informal communication is often lower when compared to traditional or co-located development (De Farias Junior et al. 2012; Jusoh et al. 2018; Sinha et al. 2020). Networked communication technologies are being used to support new ways of working in increasingly global organisations (Bietz 2013; Stray and Moe 2020). These technologies have given us a broad range of tools with which to try to overcome the challenges of distance (Bietz et al. 2012). Despite technological advancements, geographical distance still imposes limitations (e.g., lack of overlapping working hours) (Olson and Olson 2000).

Communication, as a social act, depends on the team’s maturity, therefore the communication processes and practices established by a distributed team are also expected to mature as the team itself matures (Evaristo 2003; Cataldo et al. 2008). The team needs to assess, from time to time, whether its current processes and practices meet its communication needs. DSD literature is rich in studies on the subject of communication; however, most studies focus on the causes and consequences of communication problems and propose practices to minimize them. Little is known on how to identify the maturity of communication processes and practices, helping team members to identify opportunities for communication improvement.

Maturity models, such as the CMMI (Team 2006) , are effective in assessing the maturity of organizations and provide the means for improving their processes. Over the last few years, it has been possible to identify the appearance of maturity models with a focus on agile environments. These models define different structures, approaches and concepts when compared to traditional models. Some of these are provided in Fontana et al. (2015), Stojanov et al. (2015) and Ozcan-Top and Demirörs (2013) where one of the main objectives of these agile models is to allow for a better communication and collaboration within a project’s teams, aiming to minimize conflicts caused by the lack of effective communication. Fontana et al. (2015) has developed the Progressive Outcomes Framework for agile software development maturity in her research, which is a framework that takes human beings as keys for its implementation and, consequently, the success of a project. Nevertheless, existing models are not communication-oriented, as they are focused on general organizational aspects, e.g. product development, acquisition and service provision. In this context, this study aims to answer the following research question: How should a maturity model be defined in order to support communication in DSD?

In this article, we present a maturity model for communication in DSD called C2M, composed of maturity areas organized by maturity factors, goals and practices. The C2M Model can be applied in different organizations, being evaluated from projects in which there are distributed teams. It was developed incrementally, that is, first informed by literature and then supplemented empirically. The general process was carried out in three well-defined phases. In the first phase (conception), some methodological procedures, such as Adhoc Literature Review, tertiary study, systematic literature review, and interviews with experts, were performed. This first phase gave rise to the alpha version of the model, discussed briefly in Section 4.5 and presented in more detail in Farias Junior et al. (2013). Then, in the second phase (refinement), two focus group meetings were held in two distinct organizations to help identify whether the model effectively served its purpose, and then it was analyzed through a survey with experts. This second phase gave rise to the beta version of the model, discussed briefly in Section 5.2 and presented in more detail in Farias Junior et al. (2016). Finally, in the last phase (evaluation) we proceed with the representation of the final model, presented in Section 6.2. Findings reveal that the model can assist in discovering the maturity of processes and practices related to communication problems, in addition to promote process improvement in DSD. An example of the applicability of C2M to assess communication maturity in DSD projects can be seen in Leitão Júnior et al. (2015).

The remainder of this article is organized as follows: Section 2 presents background information. Section 3 introduces the research methodology in order to propose the C2M model. Section 4 describes the model’s conceptualization. Section 5 describes the model’s refinement. Section 6 describes the model’s evaluation. Section 7 Discussion and presents the limitations and threats to validity and Section 8 presents the final remarks, including a discussion about the study’s limitations and future work.

Background

Communication serves the purpose of supporting people who work on the same project, allowing them to share information, exchange knowledge, resolve conflicts, provide information to the senior managers, among other activities (Saleem et al. 2019). In distributed projects, team members have to deal with the challenges posed by distance (Olson and Olson 2000; Damian and Zowghi 2002; Herbsleb and Moitra 2001; Khan et al. 2019). Communication can take place formally when teams follow imposed structures, procedures and protocols defined by the organization, or in an informal manner, when they discuss any work-related topics without constraints. Use of formal or informal communication depends on the team’s maturity and work settings (Bjørnson et al. 2018; Pikkarainen et al. 2008; De Farias Junior et al. 2012). For instance, agile teams are more prone to informal communication given their cross-functional structure, reduced number of members, and short development cycles (Jalali and Wohlin 2011; Korkala and Maurer 2014; Fontana et al. 2015; Fontana et al. 2018).

The media (e.g., phone, chat, e-mail) adopted by the team can also affect how communication takes place in a distributed project. Certain media channels, such as e-mail, are not as feature-rich as others such as phone calls or even face-to-face conversations (Herbsleb and Moitra 2001; Ramasubbu et al. 2005; Stray et al. 2019). The choice of those media channels allows us focus on a particular set of affordances, specifically the ability to send audio and visual information (Bietz 2008). Due to advances in technology, distributed members can meet without having to travel back and forth. In addition, communication technology can also be a roadblock factor when one of the worksites has infrastructure problems. Electricity, for example, is turned off frequently during Summer, when thunderstorms strike remote locations, leaving companies inaccessible from a few minutes to a couple of hours without previous notice. Literature also reports other factors that are part of any communication process in DSD, such as the need of establishing common ground to allow people to share a mutual understanding of project-related topics (Damian 2007), or topics that affect communication per se, such as cultural diversity (Deshpande et al. 2010) or lack of trust on remote colleagues (Moe and Šmite 2008; Beecham et al. 2021). Given their importance, teams are expected to take the time to assess their communication processes and practices and reflect on what needs to be improved in them. We proposed the C2M Model as a way to help teams guide such assessment and improvement.

In parallel, according to Perry et al. (1994), the quality of a system or product is largely influenced by the quality of the communication processes adopted to produce it. In addition, these processes provide the basis for increasing productivity and improving the use of technology in order to make an organization more competitive in the market. Adopting quality models is, therefore, an organizational strategy to effectively manage its assets, which in turn are critical for any business success (Prikladnicki et al. 2011). A maturity model is a set of best practices that, when properly defined and adopted, can enhance work practices (PMI 2013). Maturity itself represents the mastery and the improvement of practices aligned with the organization’s businesses. Oliveira (2006) states that a maturity model is a guide for an organization to understand where and how a set of practices (or processes) is currently situated and, subsequently, to move to a new stage towards continuous improvement and excellence.

At a time in our history, software production was done without any defined process. There was no control over possible maintenance or possibility of integration with other system modules. Legacy systems result from a short lifecycle and high costs. As the complexity of projects increased, new technologies appeared, requiring adjustments in production processes and preventing companies from having high costs due to software development carried out in an ad-hoc manner. With this, software engineering was encouraged to find and create models that could define a standardization for their processes (Kneuper 2008). The quality models were created to be a guide to improve organizational processes and their ability to manage the development, acquisition and maintenance of software products. Given this context, among the first maturity models that emerged, similar to the CMM methodology, we can mention, the Contract Management Maturity Model (Rendon and Garrett 2005), the Documentation Process Maturity (Visconti and Cook 1998), the Human Factors Integration Capability Maturity Model (Earthy et al. 1999), the Supply Chain Management Process Maturity Model (Lockamy and McCormack 2004), People Capability Maturity Model—P-CMM (Curtis et al. 2002), among others. All of these models present a progressive and systematic path towards the development of capacity in management processes. For most of these models, the most important thing is not to determine what level a company is at, but what must be done to maintain the continuous improvement of its processes.

Examples of maturity models for DSD are available in the literature. The Sources of Offshore IT Work (Morstead et al. 2003) describes four stages of offshore maturity work that companies can go through (offshore bystander, experimental, cost strategy, and offshore leverage). In 2005, this model was updated, changing its name to OSM (Offshore Stage Model). The Offsourcing Maturity Model (OMM) proposed by Morstead et al. (2003) aims to position organizations in relation to the maturity level of their processes. This model has five maturity levels (staff augmentation, turnkey, integrated, managed and optimized). The Offshore Ready (Perry et al. 1994) is a model that integrates various aspects of offshore development (e.g., processes, metrics, people, technology and relationships). The Process Maturity Framework (PMF) (Ramasubbu et al. 2005) focuses on managing distributed projects and it is structured into 24 process areas. Additionally, PMF is based on four central concepts (readiness for collaboration, mutual knowledge, engagement, and readiness for work and technology). Finally, WAVE (Prikladnicki et al. 2011) is a DSD model with the objective of helping an organization’s distributed units to increase their capacity to develop projects with globally distributed teams.

The models described above are related to the DSD area in general, none of them specifically deal with communication in the context of DSD. Out of the previously-mentioned models, only PMF provides an area focused on the process of communication called Enabling Communication, though it is still considered underdeveloped for accommodating the complexity inherent to the matters of communication, as declared in the author’s research (Ramasubbu et al. 2005). Regarding the contribution of this article, C2M is not a substitute for quality models and should be adopted together with other models in order to maintain a transparency of what is happening in a project. Its main goal is to list factors that affect communication in DSD, allowing teams to identify how mature their communication processes and practices are in relation to these factors. This current research differs from the aforementioned representations mainly due to the proposal of a maturity model for DSD, with a focus on the social aspect of communication. In what follows, we present the methodological approach to design the C2M maturity model.

Research Methods

In order to answer the survey question highlighted in Section 1 (“How should a maturity model be defined in order to support communication in DSD?”), a methodological process was carried out inspired by the strategy proposed by Dias-Neto et al. (2010). This approach has been conveniently used in other studies, such as the investigation of causal analysis of software defects (Mafra et al. 2006) and what would be a “Ubiquitous Requirements Engineering” (Spínola et al. 2008). According to Fig. 1, our method is organized into three main research phases and six steps. In the figure, a full line represents the flow of the process, and a dashed line represents the products (model, body of knowledge, among others) generated or consumed by the steps.

Fig. 1.

Our research method based upon Dias-Neto et al. (2010)

The Phase 1 (Section 4) seeks to design a (alpha) version based on the theoretical background and interviews with experts. In phase 2 (Section 5), we proceed to the refinement through two well-defined steps: at first, the alpha version was empirically assessed by means of a focus group with specialists, allowing the model to evolve into an intermediate (beta) version. Then a survey was carried out in order to evaluate and refine the beta version, leading to the omega version of the model. Therefore, phase 3 (Section 6) conceives this model based on the body of knowledge created in the previous phases.

A body of knowledge itself is a collection of terms; a reading list; a library; a collection of information that was fed by the results of each step of the methodological process. The body of knowledge is structured in terms of the following data: I) the tertiary study on communication factors in DDS; II) the communication practices identified in the SLR; III) the interviews with experts who corroborated the factors raised and complemented the practices found in the SLR; IV) the refinement of the C2M model (alpha version) by the two focus groups; and V) a survey for assessing the C2M Model (beta version). Finally, the proposal to design the maturity C2M model (omega version) for communication in DSD is well consolidated, and is organized by means of the knowledge collected.

Conceptualizing C2M

Step 1: AdHoc Literature Review

As suggested by Dias-Neto et al. (2010), we first performed an ad-hoc literature review (Step 1), with the aim to identify the main concepts related to our research, namely, communication and maturity models in software development, especially in the context of DSD. Given the small number of distinct maturity models available for software development (Table 1), we decided to limit our scope to communication problems. In addition, some studies were selected to provide the background for the preparation of a tertiary study (Step 2) and a Systematic Literature Review (SLR, Step 3). Thus the studies selected were focused on providing the state of the art of communication in DSD projects, but also the available maturity models which offer insights into the definition of the C2M structure, as mentioned in Section 2.

Table 1.

Models identified in the ad hoc review

Name	Description	Reference
OSM	Describes four stages of offshore maturity work that companies	Morstead et al. (2003)
	can go through (offshore bystander, experimental, cost strategy,
	and offshore leverage). In 2005, this model was updated,
	changing its name to OSM (Offshore Stage Model).
OMM	The Offsourcing Maturity Model (OMM) aims to position	Morstead et al. (2003)
	organizations in relation to the maturity level of their processes.
	This model has five maturity levels.
Offshore	It is a model that integrates various aspects of offshore development	Perry et al. (1994)
Ready	(e.g., processes, metrics, people, technology and relationships).
PMF	The Process Maturity Framework (PMF) focuses on managing	Ramasubbu et al. (2005)
	distributed projects and it is structured into 24 process areas.
	Additionally, PMF is based on four central concepts (readiness
	for collaboration, mutual knowledge, engagement, and readiness
	for work and technology).
WAVE	It is a DSD model with the objective of helping an organization’s	Prikladnicki et al. (2011)
	distributed units to increase their capacity to develop projects
	with globally distributed teams.

Step 2: Tertiary Study

Planning

The study reported in this section corresponds to Step 2 of our methodological approach, presented in Fig. 1. The main objective is to advance toward a consolidated knowledge about communication in distributed projects by developing a better understanding of which factors influence communication processes and which are the reported effects of this influence DSD projects. For this research, the main objective was to identify, from secondary studies, the communication factors and effects that influence DSD projects. The factors deserve attention and management to increase the chances of satisfactory communication (effectiveness and efficiency). To achieve our goal, we conducted a tertiary study (Kitchenham and Charters 2007) of communication in distributed projects. The review was guided by the following three research questions:

• RQ1: Which factors influence communication in Distributed Software Development projects?

• RQ2: Which are the effects of these factors in communication in Distributed Software Development projects?

• RQ3: Which factors identified in RQ1 are related to the effects identified in RQ2 in Distributed Software Development projects?

The definition of the search terms used to investigate the research questions was developed in three stages. Firstly, keywords were identified in the questions. Secondly, synonyms for the keywords were defined by DSD consulting experts. Thirdly, the unique search string was built from the combination of keywords and synonyms (Communication, Systematic Literature Review and Distributed software development) in which the operators OR and AND were interchangeably used. The resulting search string is shown below:

(Communication OR Communication Management) AND (Distributed software development OR Global software development OR Collaborative software development OR Global software engineering OR Globally distributed work OR Collaborative software engineering OR Distributed development OR Distributed teams OR Global software teams OR Globally distributed development OR Geographically distributed software development OR Offshore software development OR Offshoring OR Offshore OR Offshore outsourcing OR Dispersed teams) AND (Systematic Literature Review OR Systematic Review OR Systematic Mapping Study OR Systematic Mapping).

The first step to accomplish this tertiary study was to define the protocol, which describes the research plan in detail. In this study we analyzed secondary studies (literature reviews) in the context of DSD. An extensive search was conducted in order to identify studies published. We searched the following databases: ACM Digital Library, IEEEXplore, Elsevier ScienceDirect, El Compendex, and Scopus. Moreover, others sources were selected for the manual search, among them, we highlight, IEEE Software, Information and Software Technology, and International Conference on Global Software Engineering—ICGSE. Furthermore, four criteria of exclusion and three criteria of inclusion were defined.

Exclusion Criteria:

• (Restriction 1) Studies which do not answer the research questions;

• (Restriction 2) Duplicated or repeated studies;

• (Restriction 3) Opinion pieces, viewpoints or purely anecdotal;

• (Restriction 4) Studies showing in progress research or incomplete results.

• (Restriction 5) The articles that are not available for recovery through the web

Inclusion Criteria:

• (Restriction 5) Studies that describe a systematic Literature Review in DSD environments;

• (Restriction 6) Studies that primarily or secondarily focus on the Communication Process in distributed environments;

Three researchers participate in the execution of this tertiary study because, according to Kitchenham and Charters (2007), the involvement of more researchers lowers the bias of interpretation so that the study is relevant enough to answer the research questions. To back up and register data and to conduct the subsequent analysis of extracted data, we used the Mendeley tool. Mendeley is a Web-based reference manager. The following information was extracted from each article: publication year, authors, and the country where the research was conducted in.

The data synthesis process was based on the constant coding and comparison methods (De Souza et al. 2002), where the studies’ transcriptions have a code for a given factor/effect and make up a specific category. As the data were identified, they were removed and given a unique identifier (Category—C1...Cn/ Factor—F1...Fn / Effect—E1...En/ Secondary Study—SE/ Articles— A1...An).

Execution

During the manual and automatic searches, 310 secundary studies were obtained. After the selection (application of inclusion and exclusion criteria) there were 34 left. During the extraction, some repeated studies and studies that did not answer the questions of the search were excluded. So, for the analysis step there were 20 studies left (It is worth noting that the studies were evaluated by two researchers who considered them relevant to be part of the research). A list of these studies is presented in Appendix Appendix.

The 20 studies were independently assessed by two of the researchers using the same version of the criteria set by the Centre for Reviews and Dissemination (CDR) and Database of Abstracts of Reviews of Effects (DARE) from York University (Aoyama 1998). This version of the DARE criteria use the following levels of agreement or disagreement: 0 (not included), 0.5 (partly included), and 1 (totally included). The final quality index is calculated by the total sum of the four criteria scores. This index is also commonly used to display the strength of evidence for extraction and data synthesis. This assessment is available in Appendix Appendix.

Results

Our manual and automatic search revealed 20 secondary studies. The findings are briefly presented according to the defined research questions. RQ1, “Which factors influence communication in Distributed Software Development projects?”, sought to identify the main factors that influence communication in distributed projects. Based on the 20 secondary studies analyzed, we identified 29 factors grouped into three categories (Human Factors, Location and Infrastructure, Processes and Technology). The most-cited factors are: Cultural Differences, Language Barriers, Coordination, Visibility, Limited informal communication. RQ2, “Which are the effects of these factors in communication in Distributed Software Development projects?”, sought to identify the main effects. We found 25 effects associated to the factors. We highlight the following effects: Uncertainties, Misunderstandings and Misconceptions, Lack of Confidence, Quality of Communication, Limited information sharing. These effects were classified into the same categories as the factors. In addition, they were also categorized for their impact on communication effectiveness.

Finally RQ3, “Which factors identified in RQ1 are related to the effects identified in RQ2 in Distributed Software Development projects?”, sought to relate the main factors that cause the effects identified in the communication. Out of the 29 identified factors, 25 were associated with 23 of the identified effects. For some cases, more than one effect related to the same factor in the relationship between factors and effects.

Discussion

About RQ1, it is observed that in order to provide a better understanding, the secondary analysis of these research studies show that the field of DSD is still researching the maturity of methods, techniques and tools. Given this context, we can observe in the Table 2 the main factors cited in this research.

Table 2.

Factors and number of studies

Factors	Number of studies (%)
Cultural Differences	8/20 (40%)
Language barriers	7/20 (35%)
Geographic dispersion	7/20 (35%)
Coordination	6/20 (30%)
Visibility / Perception	6/20 (30%)
Limited Informal Communication	6/20 (30%)
Temporal dispersion	6/20 (30%)

This question sought to identify the main factors that influence the communication process in the design of DSD. Based on the 20 secondary studies analyzed, it was possible to identify 29 factors, which were grouped according to categories: Human Factors, Location and Infrastructure and Processes and Technology.

About RQ2, we find that despite the consequences of major impact from these effects in DSD projects, most managers and project participants do not give them due attention. Among the 25 effects that were found, we can highlight the ones most cited in this research in the Table 3.

Table 3.

Effects and number of studies

Effects	Number of studies (%)
Uncertainties / misconceptions	7/20 (35%)
Limited sharing of information	6/20 (30%)
Lack of Confidence	5/20 (25%)
Quality of Communication	4/20 (20%)
Delay of answers	4/20 (20%)

This question sought to identify the main purpose of the communication process in the design of DSD. From the 20 secondary studies analyzed, 25 were identified through the effects, which were classified in two ways: negative effects are not associated with Effective Communication and positive effects are associated with Effective Communication. The effects are sorted according to their Human Factors, Location and Infrastructure, and Processes and Technologies, which were obtained from the extraction of information from selected secondary studies. A mapping of C2M practices and factors from secondary studies is presented in Appendix Appendix. More details about the results with the execution of this tertiary literature review are discussed in dos Santos et al. (2012).

Step 3: Systematic Literature Review

Planning

Another literature review was carried out—as a complement to the tertiary study (presented in Section 4.2)—this time, with the aim of identifying, from primary studies, factors and, especially, practices that influence communication processes. The protocol was established based on the guideline proposed by Kitchenham and Charters (2007). The first step was to specify a clear group of research questions that should be answered by the SLR. Then, aiming to investigate the communication in DSD projects, two main questions were formulated (RQ1 and RQ2):

• RQ1: What are the communication factors in DSD projects?

• RQ2: What are the practices utilized to maximize the communication in DSD projects?

The main part of the search strategy is the elaboration of a search string. For the construction of the search string, synonyms were selected for the terms “Distributed Software Development” and “communication”. Based on the steps presented in Kitchenham and Charters (2007), the following string was constructed: (“Communication” OR “Communicate” OR “Communication Management” OR “Information sharing” OR “Information transfer”) AND (“Distributed software development” OR “Distributed development” OR “Distributed teams” OR “Global software development” OR “Global software engineering” OR “Global software teams” OR “Globally distributed development” OR “Globally distributed work” OR “Geographically distributed software development” OR “Collaborative software development” OR “Collaborative software engineering” OR “Cooperative software development” OR “Cooperative software engineering” OR “Offshore software development” OR “Offshoring” OR “Offshore” OR “Offshore outsourcing”).

The follow sources were selected for the automatic search: ACM Digital Library, El Compendex, Elsevier ScienceDirect, IEEEXplore Digital Library, Scopus, Wiley InterScience. Moreover, others fifteen sources were selected for the manual search, among them, we highlight, Communications of the ACM, Transactions on Software Engineering, IEEE Software, Information and Software Technology, and Journal of Systems and Software. In regard to the sources for the automatic SLR search, most of them (four sources) are indicated in the guideline Kitchenham and Charters (2007) as review sources with relevance for the field of Software Engineering. Furthermore, eight criteria of exclusion and two criteria of inclusion were defined.

Exclusion Criteria:

• (Restriction 1) Articles that are not written in English;

• (Restriction 2) Articles that do not answer any of the research questions;

• (Restriction 3) Articles that are not available for recovery through the web;

• (Restriction 4) If two articles publish the same results of a study, the one that is less detailed will be excluded;

• (Restriction 5) If two equal articles are found in more than one source, one of them will be excluded;

• (Restriction 6) Articles that are not from the field of Computer Science (for example, Business, etc);

• (Restriction 7) Articles which were published before 1999;

• (Restriction 8) Articles that contemplate the execution of theoretical studies involving the communication in DSD projects.

Inclusion Criteria:

• (Restriction 9) Articles that contemplate an execution of the empirical studies involving the communication in DSD projects and that answer at least one of the research questions;

Three more researchers were invited to participate in the execution of this SLR because, according to Kitchenham and Charters (2007), the involvement of more researchers lowers the bias of interpretation so that the study is relevant enough to answer the research questions.

Finally, a strategy of extraction was defined. A textual template of the document was elaborated, with sections to map the relative data of each primary study. At last, it was defined that the data synthesis would be based on the method of Thematic Analysis (Merriam and Tisdell 2015) generating codes and categories. The group of codes and categories is a product of the analysis and was obtained with the help of the quantitative data analysis software Weft QDA. The protocol of this SLR was evaluated by seven researchers (more details on this assessment are presented in Appendix Appendix). The evaluation result was positive, and indicated the possibility of executing the SLR.

Execution

During the manual and automatic searches, 1,338 primary studies were obtained. After the selection there were 245 left. During the extraction, some repeated studies and studies that did not answer the research questions were excluded. So, for the analysis step there were 184 studies left. A list of these studies is presented in Appendix Appendix, and a list with the sources of primary studies identified in the SLR is presented in Appendix Appendix.

Results

RQ1—What are the Factors that Influence the Communication in DSD Projects?

The studies that were selected evidenced 34 factors that influence communication in DSD projects. The five factors that influence communication the most are Cultural Difference (F1), Temporal difference (F2), Physical Difference (F3), Infrastructure (F4), Software Engineering Activities (F5). Furthermore, the five factors that influence communication in a positive or negative way are: frequency, wealth, speed, efficacy and interlocutors. The frequency of the communication is the characteristic that suffered more impact due to the distribution of the teams, followed by wealth, efficacy, speed and perception about the interlocutors.

RQ2—What are the practices involved in the communication in DSD projects?

The selected studies evidenced 29 practices that are used for the communication in DSD projects (presented in Appendix Appendix). It can be noticed that distributed teams communicate directly through two practices: Making meetings/face-to-face encounters (P1) and Sending an ’ambassador’ to remote locations (P2). However, in general, the five practices of communication adopted in DSD projects that stand out in relation to the amount of evidence found are Making meetings/face-to-face encounters (P1), Use of unsynchronized communication via technological tools (P3), Use of synchronized communication via technological tools (P4), Use of collaboration platforms (P5) and lastly, Selection of the communication channels (P9). On the other hand, other practices also stood out in the evidence analysis such as: Making frequent meetings (P8), Describing the communication protocol (P11), Standardizing the language of the Project (P14) and, finally Sharing a meeting schedule (P32).

Discussion

The factors that influenced the communication in DSD projects identified in this research were compared to the factors identified in the first systematic literature review executed in this article, described in Section 4.2 (terciary study). Only two factors of the terciary study Collaboration Tools (F14) and Collaboration Models (F25) were not evidenced in the SLR. However, they were comprised into a practice used for communication Use of collaboration platforms (P5), and nineteen distinct factors emerged, such as, Software Engineering Activity (F5), Trust (F10), Knowledge about the teams (F11), and Acquaintance among the teams (F13).

The results of the terciary study and SLR served as input for the alpha version of the C2M model. Some limitations could be observed in the study, in relation to the systematic review. One of the greatest concerns in SLRs is selecting as many relevant studies as possible to answer the research questions, and a coverage of 100% of the sources was not possible due to the limitation of time and resource. To minimize this problem, a manual search was done in the main conferences and journals within the field of knowledge. More details about the results with the execution of this secondary literature review are discussed in Farias Junior et al. (2021).

Step 4: Interview-based Study with Experts

Planning

A protocol was developed and validated with 2 senior researchers. The objective of the protocol is to guide the researcher for the activities of data collection, establishing general rules to be followed on site. In our protocol, we defined the invitation for participating in the research, confidentiality agreement, interview script (presented in the Appendix Appendix), instrument of data collection, duration of the interview, date and time of the interview, and the delivery of material within the research scope as determined by Yin (2009).

The empirical study with 31 professionals was developed in twelve units of software development companies. The objective of this study was to understand the challenges of communication, identify the factors with more priority, as well as the communication practices adopted in the DSD context. The research participants were geographically distributed as follows: 1 professional was located in Canada, 5 in the United States, and 25 in Brazil. An effort was made to understand the order of relevance of the factors to the conception of the first version of the C2M model.

The initial criterion for the definition of the respondents was centered mainly in the objectives of the study. In this sense, the population direct or indirectly involved was constituted mainly of collaborators in two levels: management and operational.

The data collection tools consisted of a script for semi-structured interviews, with open and non-inductive questions. The interviews were organized to identify challenges, main communication factors of the technical and non-technical parts. In relation to the data analysis, all the interviews were recorded, transcribed and after analyzed, through content analysis according to Coutinho (2005). Microsoft Excel and the Weft QDA (http://www.pressure.to/qda/) were used as data analysis tools.

Execution

The selection of the participants was done according to their professional profiles and experiences. The participants should, mandatorily, have had experience with DSD or be currently working in a DSD project. 31 professionals with experience in DSD from 12 organizations were selected for the interview. Of the 12 respondents, 9 were software developers, 5 were software testers, 4 were technical leaders and 12 were project managers. As for their level of education, all respondents are from the IT field, and post-graduated.

Data were collected through semi-structured interviews. The interviews lasted an average of 1 h 04 min and counted on the full availability and attention from the participants. Regarding the dispersion level of the projects, 52% were classified as Global, and 48% as National. Information was provided in accordance with the privacy and confidentiality policies of the project they were involved in.

Interviews with thirty-one professionals were defined, selected by convenience. All the interviews were previously scheduled and transcribed after they occurred. Aiming to ensure the quality of the data, six respondents were contacted again to clarify some points where the researcher had doubts. With the transcriptions in hands, the qualitative analysis of the data was performed. At first, an analysis of the content was performed, where preliminary categories were defined.

Results

According to the analysis of the collected data, it can be said that the factors (considered as challenges) of DSD communication, according to the 31 respondents of the 12 companies, are centered in the lack of understanding of the activities, absence of mechanisms (guides, processes, models) to planning communication in projects, lack of standardization of the activities within the distributed teams, and the absence of a well-defined process for requirements engineering activities. Plus, there were also verified factors in relation to language barriers, cultural differences, among other.

Aiming to consolidate the results, the most relevant communication factors, in the view of the respondents, were explicited. According to the opinion of the respondents and considering the 31 factors found, it is observed that at least 11 are evaluated from 94% to 100% as relevant. It is worth to mention, in this sense, the provision of project results to the senior management, elicitation and specification of requirements and frequent communication. These factors are considered of major impact for DSD projects from the point of view of those who deal with distributed software projects on a daily basis. More results of the interviews are presented in the technical report in Appendix Appendix.

Discussion

The factors of DSD communication were inherited from the systematic review (Step 2) and the tertiary literature review (Step 3), and were corroborated by the results of the interviews (Step 4). The 22 factors with the strongest evidence were used to design the alpha model version, for example, communication planning, management of cultural differences, and interpersonal relationship.

After the comparison between the systematic review (step 3) and the interviews (step 4), we found out that only eleven practices of the interviews were not evidenced/contemplated in this systematic review, for example, exchanging of members among dispersed teams (P5), making of technical workshops about technologies used in the project (P7), and institutionalizing the cultural context of each team that belongs in the project (P10).

However, in the systematic review, eight new practices were identified, practices which were not identified in the empirical study, for example, use of asynchronous communication via technological tools (P3), selection of the communication channels (P9), and standardizing the language of the project (P14).

Both researches complement each other with the objective of broadening the basis of good practices regarding the communication in DSD projects. The factors and practices confirmed by the interviews served as input for the alpha version of the model.

In relation to the sample of the field study with DSD professionals, it counted on the participation of thirty-one professionals. This number of professionals influences in the generalization of the results. Even if the generalization is not possible, these data have the validity of being the first results presented in this structure and can be complemented with other studies.

Preliminary Version (Alpha Version)

The first version of the C2M model (alpha version) was developed with still incipient elements. Table 4 shows the origin of each element of the Alpha version C2M model.

Table 4.

Mapping of the C2M alpha version elements extracted from the studies we carried out

Elements	Origin
Categories	Tertiary Study (Section 4.2)
Factors	Tertiary Study (Section 4.2) and SLR (Section 4.3)
Practices	Tertiary Study (Section 4.2) and interviews (Section 4.4)

The results of the Tertiary Study were the 3 categories (Human Factors, Location and Infrastructure, Processes and Technology), 29 factors and 25 communication effects for the DSD context. As for the SLR, the main results were 34 factors and 29 good practices for DSD communication. Finally, the results of the interviews with professionals aimed to assess the main results of the Tertiary Study and SLR. This assessment was made by 31 professionals with extensive experience in DSD. After the evaluation, we obtained the most relevant communication (calculated from the strength of evidence) factors that served as inputs for the design of the alpha version of the C2M model (Fig. 2). It is worth noting that for this version of the model, good communication practices were not detailed or distributed in the categories identified in the Tertiary Study.

Fig. 2.

C2M Alpha Version

Refining C2M

Step 5: Focus Group

Planning

The evaluation was performed by two focus group sessions with experts. The focus group was planned in line with the recommendations of Carlini-Cotrim (1996), Kontio et al. (2004), Tremblay et al. (2010), Munaretto et al. (2013). In this plan, the following information was taken into consideration: formal invitation sent to the companies/the participants; confirmation of the experts’ characteristics; confirmation of the number of experts, satisfying the proposed method; confidentiality agreement and consent to record the discussion; presentation of the schedule and the steps of the focus group’s activity; presentation of each expert; general presentation of the proposed model; discussion of the themes; and finally, conclusion and acknowledgments.

The focus group meeting was organized as follows:

1. First, the C2M model was presented in order to align the knowledge of all participants and feedback was collected in an organized way, based on their discussions.

2. Next, participants were asked what they thought about the model’s structure (e.g., categories, number of maturity levels, number of factors and practices, among other aspects);

3. Then, participants were asked what they thought about the maturity factors (e.g., description, classification, associated practices, and so on);

4. Finally, participants were asked about the C2M model’s practices (e.g., whether they are associated with the correct maturity factor and whether they are available at the correct maturity level).

For the first focus group, it was important to have at least five years of professional experience in maturity models, and at least one year of experience in DSD projects. For the second focus group, it was important to have at least five years of experience in DSD projects and some knowledge on maturity models. We define these two criteria to make sure that both the DSD and the maturity aspects of software processes are properly covered in our model. As a result of our invitations, two organizations allowed their collaborators to participate in our study after signing a confidentiality agreement with the research team.

Execution

The first focus group was run with seven (7) experts in maturity processes for software development (Table 5). They are employees of a consulting company in maturity models for software processes. All experts have either a Master’s or a PhD degree in Computer Science. They had an average experience in quality maturity models (e.g., ISO 9001, CMMI, and MPS.BR) of eight years. They also had an average of two years of professional experience in DSD projects. They evaluated the structure of the C2M model and the distribution of the maturity factors in their respective level of maturity, as well as the number of levels of the model.

Table 5.

Characteristics of the participants of the first and second focus group

Participants	Experience in software maturity/process models	DSD Experience
PA1.1	8 years	1 year
PA1.2	10 years	2 years
PA1.3	10 years	2 years
PA1.4	10 years	2 years
PA1.5	6 years	1 year
PA1.6	8 years	3 years
PA1.7	8 years	1 year
PA2.1	10 years	6 years
PA2.2	1 year	5 years
PA2.3	3 years	8 years
PA2.4	3 years	5 years
PA2.5	1 year	5 years
PA2.6	6 years	6 years

The second focus group was run with six (6) experts with broad experience in DSD projects, distributed as follows (Table 5): three developers, one tester and two managers. All experts have a Master’s degree in Computer Science. The experts have an average of six years of professional experience in DSD projects. They evaluated the structure of the C2M model and distribution of the maturity factors in their respective levels of maturity. They also gave special attention to the review of the practices proposed by the C2M.

To make the method more efficient, a presentation of the maturity model for the communication in DSD projects was made and then a form was handed with the information to be evaluated (factors, levels, structure and etc.) with space for them to write any comments they would like to remember in the moment of the discussion. After the start, we told the participants that, whenever they were told what the discussion topic was, they should feel free to expose their opinions and if anyone had a different opinion, they could complement in a way that would contribute with more knowledge.

Results

None of the participants disagreed with the effectiveness of the structure proposed by the C2M. However, as a suggestion, they pointed out the possibility of creating additional categories to categorize factors like requirements specification, configuration management, among others. Another suggestion made by the participants was to evaluate the possibility of following the quantitative levels of CMMI, because this adjustment would facilitate the use of C2M in companies.

With regards to the maturity factors, none of the experts disagreed with the importance of factors in the DSD context. However, as a suggestion, they pointed out the possibility to refactor some maturity factors, i.e, modifying the internal structure of the C2M template so that it is improved. For example, to unify some factors (those which are similar, e.g., Selection of Communication Technologies, Collaboration Tools and Definition of the Communication Media). These suggestions have the objective of making the C2M model more dynamic and easier to use.

Referring to the practices of the model, two experts expressed their concerns with the large number of practices in the first level of evolution. Their opinion is that the amount of practices can hamper the use of the model in small organizations. Another important point raised by some of the experts is about the title of the practices. They believe the titles need to be self-explanatory and as such they suggest that we review how we name some of the practices. They pointed out the possibility of reviewing some specific practices, aiming to rewrite them or remove others that may be unnecessary. For example, the practices i) to establish direct and fast communication channel for doubts and problem solving, ii) to maintain face to face communication and iii) to establish a committee for continuous improvement of the communication process, of the maturity factors i) Communication Planning, ii) Face to Face Interaction and iii) Continuous Improvement of Communication, was suggested to be rewritten in order improve understanding of the practices of C2M.

The participants of the focus group commented in relation to the C2M maturity factors and practices:

Analysis of Answers Related to the C2M Maturity Factors

• First focus group

  • PA1.1 said that “apparently all the factors are highly relevant. However, many can be grouped or turned into practices.”
  • PA1.2 said that “there are many factors and this can create a stereotype of complexity for the model. I advise you to review some factors to group them, and remove the useless ones when it is appropriate.”
  • PA1.3 said that “all factors are important, but you need to check if they are really needed in the context of DSD.”
  • PA1.4 said that “the selection of factors for a first version is great. I think that over time, the model should mature and will certainly feel the need to make some changes.”
• Second focus group

  • PA2.1 said that “all factors are relevant. I think this model will be a good tool for the project manager.”
  • PA2.2 said that “despite the belief that the factors are important, I think there are too many factors in the model. I think we need to simplify to get acceptance from the organizations. However, I want to note that in my opinion they are all extremely relevant to any kind of project.”
  • PA2.3 said that “you need to decrease the amount of factors and to do that, I realized that it is possible to group some factors and others may become practical. Perhaps, the model would even adopt the concept of sub-factors.”
  • PA2.6 said that “the proposed model is relevant and the composition of the factors is also relevant. I think that there is no need for changes in the model until its application in a real project.”

Analysis of answers related to the C2M practices:

• First focus group

  • PA1.2 said that “the practices are very interesting, but I think there are many practices for the proposed model. I think that a small business will not be able to deploy this model.”
  • PA1.6 said that “all practices were effectively well selected. As a suggestion, I believe it is possible to improve the names of each practice to become more understandable.”
  • PA1.7 said that “this model can certainly be complementary to existing models such as CMMI and MPS.BR. I think that some practices are very comprehensive.”
• Second focus group

  • PA2.1 said that “the number of practices is consistent with the amount of existing factors in the model.”
  • PA2.3 said that “I think that some practices can be grouped and others can be grained. Another important point is to review the names and descriptions of the practices so that they are more reader friendly.”
  • PA2.6 said that “I think that all practices are consistent. However, I missed some other practices, for example: Managing meetings, verifying the effectiveness of the trainings, among other practices.”

Discussion

This evaluation of the C2M model, executed by two focus groups, was extremely important, since we had the opportunity to review the staggering of the maturity factors, evaluate all the practices to operationalize the implementation of the C2M, and verify possible adjustments, such as: group, include, exclude or change maturity factors, as well as their respective practices. Furthermore, we can capture general suggestions for the proposed model. Ten respondents (76%) pointed that the C2M model certainly will bring benefits to the communication in projects, and that they could adopt the model in their projects. However, three (24%) respondents said that the model is promising, but they believe that the model is more directed at medium and large organizations.

The experts made some suggestions for improvements. These suggestions served as input for the beta version of the revised model (along with the previous steps). Although the model has been developed in the academia, the experts stated that it is a welcome asset for the software industry. The main reason for the experts to deem the C2M model suitable for use in real-life projects was that it has the following characteristics:

• defined scope and established goal (communication);

• simple architecture to facilitate implementation;

• the topic is relevant to real-life projects;

• the solution proposed by the maturity model is applicable for organizations of any size;

• the C2M does not exclude other quality models (it can be seen as supplementary model).

The main points implemented in the beta version of the model from the results of the focus groups were:

• Changed the model categories to: people, projects and organizational unit;

• Adjusted factor names to be more self-explanatory;

• Revised factors and factors to remove redundancies;

• Revised the model in order to refactor or unify some maturity factors;

• Adjusted the names of some practices to be self-explanatory;

• Revised the distribution of factors and practices at the levels of the C2M model, mainly to ensure that small businesses will be able to use the model.

As limitations for this study, the focus groups were comprised of only two Brazilian organizations, and it was not possible to carry out focus groups with foreign organizations. More details about the results with the execution of this study are discussed in Farias Junior et al. (2016).

Revised Version (Beta Version)

The version called the beta version, is an evolution of the alpha version. It was conceived after the evaluation made by two focus groups according to phase II of Fig. 1. The beta version was composed of three areas of maturity (people, projects and organizational unit), four levels of maturity, 28 factors of maturity and 84 communication practices. In this version, all factors and practices were already distributed at their respective maturity levels (See Fig. 3). It is worth noting that the categories of the model have evolved and came to be called areas of maturity. All suggestions from the two focus groups were aimed at making the C2M model more dynamic and easier to use. Table 6 shows the origin of each element of the Beta version C2M model.

Fig. 3.

C2M beta version

Table 6.

Mapping of the C2M beta version elements extracted from the studies carried out

Element	Origin
Maturity Areas	Tertiary Study (Section 4.2) and focus group (Section 5)
Maturity Factors	Tertiary Study (Section 4.2), SLR (Section 4.3) and focus group (Section 5)
Practices	Tertiary Study (Section 4.2), interviews (Section 4.4) and focus group (Section 5)
Maturity Levels	Focus group (Section 5)

Evaluating C2M

Step 6: Opinion Survey

Planning

The approach to this study was based on the recommendations from Li and Smidts (2003) and motivated by the work of Garcia (2010). It is organized into four phases. In the first phase, the objective was to: define, evaluate and validate the script of the guided interview. In the second phase, the experts were selected and contacted. In the third phase, the invitation to participate on the interview was sent to the experts and after the acceptance the data was collected. Finally, in the fourth phase, the data were analyzed aiming to characterize the C2M model in what concerns to its viability, based in the opinion of experts.

For this study, 110 potential candidates were selected, composing the group of experts for this research. They represent a group of experts with the capability to evaluate and contribute to the improvement of the C2M model. Despite the reduced sample, 110 experts is considered an adequate number. As notorious in the literature, the inquired sample is satisfactory to the current study, once it is qualified by renowned experts, with broad experience in DSD and software quality process.

The research was composed by an interview script (presented in the Appendix Appendix) developed after an extensive literature review, with strong influence of works relevant to the DSD area (Prikladnicki 2003, 2009; dos Santos et al. 2012; Da Silva et al. 2011) and Opinion studies (Beecham et al. 2005; De Farias Junior et al. 2012; Li and Smidts 2003) among others.

The first version of the research was defined and was reviewed for two months. The review was performed together with three researchers (one with theoretical and practical experience in software quality improvement, and the other two experienced in the DSD area). Is important to note that these researchers did not participate in the research, but took part in the pilot project that was carried out in order to estimate the time needed for the respondent conclude the investigation/interview, and raise other relevant aspects.

The main aim of our study was to evaluate the viability of the C2M model (beta version), as well as its adaptation based on the opinion of experts. In this sense, the questions were elaborated in relation to: role of the expert (academia or industry), the way that the maturity factors are distributed in the levels of the model; the specification, description of the main objective of every maturity level; objectives related to the maturity factors; descriptions and objectives of every practice in the model and, if it is possible for an organization to perceive and obtain, in the initial stages, the benefits of effective communication, outside the highest maturity levels proposed by C2M. The final script was composed by 38 questions with open and closed questions and was designed to be concluded in approximately 1 h.

Execution

We selected 110 experts based in the previous guidelines, but only 55 participated on the research. The main requirements to participate on the study were: i) have a minimum of three years of experience (theoretical or practical) in DSD; ii) have knowledge in improvement of the software process, especially in quality models, like CMMI, and ISO. Therefore, according to the recommendations of the NUREG-1150 (Wheeler et al. 1989), we selected experts from the industry and academia, from different companies and universities, as well as from different places.

Most of the fifty-five experts that participated in the study are residents of Brazil. Two participants were from outside the country (USA and Germany). Still about the characterization of the participants, fourteen work exclusively in the industry, nineteen work exclusively in the academia, while twenty-two work in both. From the participants of the research, fifty-two have the basic training in computing, one in administration and the other two in communication. Furthermore, there are the ones with degrees, forty have a master’s degree, seven are doctors and one is a postdoctoral researcher in computer science. The other are postgraduated in “Lato Senso” courses in computer science. All the participants had acted actively in the last years in the DSD area.

Before the interview, the script was sent by email to all the experts, and next the interviews were scheduled (some face-to-face, others through Skype). All the interviews were finished and gathered for analysis. In some cases, we needed to contact the respondent to answer some doubts or clarify some things that could lead to divergent interpretations. In the study, ten experts were contacted to clarify some questions, mainly related to the objectives and practices of the C2M model. It is worth to point out that the interview script applied in this research was submitted to the Cronbach’s alpha test through the SPSS software and as a result was reported to have an acceptable reliability to the scale of 0.70.

Results

Regarding the maturity factors, none of the experts disagreed with its importance in the DSD context. Nevertheless, as a suggestion, the possibility of merging some similar factors was highlighted (e.g., selection of communication technologies, collaboration tools and definition of communication media). In addition, new factors were proposed.

We asked if the maturity factors in Levels 2, 3 and 4 are correctly organized in the C2M model. Expert 1 said that: “the configuration management could be in level two, to stay in line with other models”. Expert 50 said that: “the communication management is a very important item and it should be in level 2. The risk management could be in level 3 as part of a more mature process”. Expert 28 says that: “the objectives of the factors must be refined, specifically those which are evolved in the subsequent levels”.

With respect to C2M practices, two experts expressed their concerns about a large amount of practices at level 2. Their opinion is that the number of practices can hamper the use of the model in small organizations at first. Another important point raised by experts is about the identification of the practices. They believe the headlines need to be self-explanatory. Thus, reviewing how the practices were named was an important insight. In addition, the possibility of revising some specific practices and rewriting or removing unnecessary ones was noted. For example, Communication Planning, Face-to-Face Interaction and Continuous Improvement of Communication Processes were indicated as potential items to be rewritten in order to improve the understanding of C2M practices. Expert 38 said that: “the practices are very relevant, but a calibration, redistribution and redefinition of some points will strengthen the model much more”.

We asked further whether C2M’s maturity levels represent a natural path of evolution. With respect to level one, 45 specialists (82%) answered positively. In addition, for levels 2, 3 and 4, we have obtained the following number of experts who confirm such statement, respectively: 39 experts (71%), 43 experts (78%) and, finally, 48 experts (87%). Expert 22 argued that: “the approach followed by C2M is the best alternative, as it considers that a company has no maturity and evolves in things that make sense to the organization”. More results of the survey are presented in the technical report presented in Appendix Appendix.

Discussion

65% (36) of the experts said they would adopt the model and 33% (18) of the experts said they could possibly adopt it. Only 2% (1) expert said they would not adopt it. This result motivates us to invest heavily in continuous improvement of C2M so that it can assist organizations in organizational processes effectively.

Even with the reduced number of experts (55), the analysis has shown that the C2M can be feasible. The study also identified some directions for improvement that would be analyzed and subsequently generated a omega version of the proposed model.

According to the experts, the main reasons for suggesting C2M as a suitable model for real-life projects are: (I) a well-defined scope and well-established goal addressing communication requirements; (II) a simple architecture facilitating its implementation; (III) the topic is very relevant to projects and is not fully addressed by available approaches; (IV) the solution proposed meets organizations’ necessities of any size; and (V) C2M does not override other quality models (actually, it can be employed as a supplementary model).

The limitation to the utilization of the survey depends exclusively on the good faith and on the total capability of the respondents, and these concerns were reduced by the rigor that was applied during its planning and execution.

Omega Version

Considering the scope of this research, a maturity model for communication in a DSD endeavor is defined as a set of practices adopted by an organization throughout the daily software development activities aimed towards the improvement of communication processes in DSD projects. The omega version of our Communication Maturity Model (C2M) is presented in this section.

The omega version, is an evolution of the beta version. It was conceived after the evaluation made by 55 experts according to phase III of Fig. 1. Some improvements have been implemented based on expert feedback in agreement with experts, for example:

• Refactor some maturity factors;

• Modify the internal structure of the C2M template so that it is improved;

• Unifying some factors (those which are similar, e.g., Selection of Communication Technologies, Collaboration Tools and Definition of the Communication Media).

The omega version was composed of four areas of maturity (people, projects, organizational and engineering), 15 factors of maturity and 49 communication practices. In this version, all factors and practices were already distributed at their respective maturity levels (See Fig. 5). The units of analysis for C2M evaluation are projects. Table 7 shows the origin of each element of the omega version C2M model.

Fig. 5.

C2M elements (Maturity Areas, Maturity Levels, and Maturity Factors)—Omega Version

Table 7.

Mapping of the C2M omega version elements extracted from the studies carried out

Element	Origin
Maturity Areas	Tertiary Study (Section 4.2), focus group (Section 5), and survey (Section 6)
Maturity Factors	Tertiary Study (Section 4.2), SLR (Section 4.3), focus group (Section 5), and survey
	(Section 6)
Goals	Survey (Section 6)
Practices	Tertiary Study (Section 4.2), interviews (Section 4.4), focus group (Section 5) and
	survey (Section 6)
Maturity Levels	Focus group (Section 5) and survey (Section 6)

Structure of C2M

C2M is mainly inspired by the structure of two other maturity models: CMMI (staged representation) (Team 2006) and WAVE (Prikladnicki et al. 2011). A set of maturity factors (each factor has one or more practices with its respective objective) must be implemented collectively to reach a level of excellence, so that communication in DSD projects is standardized to a certain level of quality. However, if the organization is not interested in identifying the maturity level, it can decide which maturity factors to implement according to its business/strategic objectives.

Maturity areas in C2M represent a mapping of different categories for the types of factors identified (Fig. 4). Some models have a similar concept identified as “domains”. For each maturity area, there are maturity factors which, in turn, have goals. Each maturity factor has only one goal. Furthermore, maturity factors are associated with one or more practices which must be implemented to address DSD communication. Finally, some practices established on a set of factors determine the level of maturity of the organization at the time of its assessment.

Fig. 4.

C2M structure (Omega Version)

As illustrated in Fig. 4, C2M divides its structure into three dimensions: maturity areas, maturity factors and maturity levels. A Maturity Level comprises a set of maturity factors that portray an organization’s maturity stage w.r.t. the DSD communication. It signalizes a distinct evolutionary stage for achieving a mature software process, capable of providing continuous improvement.

Maturity Areas

Maturity areas are categories that group related maturity factors. The four defined areas are people, project, organization and engineering. The people area presents human-related aspects, e.g., trust acquisition. The project area is related to the management of the entire project, driven by communication resources (e.g., infrastructure) and aligned with the strategic objectives of an organization. The organizational area focuses on its processes (e.g., the ones regarding the continuous communication improvement) or on aspects observed at the organizational level (e.g., communication patterns and policies).

Maturity Factors

Maturity factors, as previously described, gather related practices towards a desired goal (when implemented in conjunction). 15 maturity factors (Table 8) were identified as the result of the second SLR and the focus groups’ contributions, according to the collective perception of participants and aligned with the DSD communication aspects. Each factor contains associated practices. The maturity factors were initially published in the works of dos Santos et al. (2012) and De Farias Junior et al. (2013).

Table 8.

Maturity factors grouped into C2M maturity areas (Omega Version)—for more details see the Appendix Appendix

Maturity areas	Maturity factors
People	Management of cultural differences
	Trust acquisition
Project	Tools to support communication
	IT Infrastructure
	Management of geographical distance
	Management of temporal distance
	Management of stakeholders
	Monitoring, measurement, and analysis
	Communication planning
Organizational	Continuous improvement of communication
	Risk management
	Communication patterns and policies
	Communication training
Engineering	Configuration management
	Requirements, elicitation, and specification

Maturity Levels

A maturity level consists of a set of factors determining an organization’s maturity stage w.r.t. DSD communication. Four maturity levels were defined in the C2M model. Level 1 is the initial phase of any organization, with no defined practices. This means that each organization executes communication activities in an ad-hoc way. Level 2 is defined as partially managed. The organization usually has basic capabilities, which must be developed to sustain individual skills for dealing with potential communication challenges in DSD projects. Level 3 is defined as managed. Individual efforts are directed towards teamwork, which requires teams to be strictly aligned with the organization’s goals. At this level, projects are carried out by distributed teams which are not fully integrated and are usually managed independently. Although some specific projects allow for team integration, it still cannot be adopted as a standard in the organization. Finally, Level 4 is defined as integrated. An organization foresees an ongoing motivation to improve the performance of each team, since patterns are created and institutionalized at the organizational level (e.g., organizational processes, reports and communication media patterns).

Moreover, C2M foresees specific practices of work integration among one or more teams, when they need to work together. Therefore, the potential of an entire organization (including subsidiaries) should be identified so as to develop software in a global and integrated way. Figure 5 shows all elements of the C2M model, including the defined maturity factors, practices and respective levels. Although we took CMMI as one of the base references to C2M, both models are different in some structural aspects. For example, in C2M factors are not the same for all levels: (in Level 2, there are no practices for the factor “cultural differences”); this logic follows at Levels 3 and 4.

Goals and Practices

For each factor, a set of practices was defined. A practice is an activity that must be carried out as a means to ensure a gradual implementation of the factor in compliance with the maturity desired by the organization. Factors were documented following the pattern described in Fig. 6.

Fig. 6.

C2M factor pattern (Omega Version)

Each factor has a name and an acronym. In addition, there is a general goal describing its objective. The fulfillment of a goal of a respective practice will provide the basis for improving DSD communication. Practices are described for each factor.

In the following, we shall present two examples of maturity factors with their respective objectives and practices. More details on the maturity factors that compose the C2M are presented in Appendix Appendix.

• Tools to support communication (TC):

  Goal: to make adequate use of the existing tools considering the scenario of distributed teams.

  • (2) TC1: Adopt asynchronous communication tools on demand.
  • (2) TC2: Adopt collaboration tools.
  • (3) TC3:Adopt synchronous communication tools (face-to-face).

  • Adopt asynchronous communication tools on demand: This practice focuses on defining the adoption of synchronous or asynchronous tools (or both) based on the specific needs of the projects. Asynchronous tools are those that do not need to be connected in real time at the same time. Therefore, even if the participants of the distributed teams are not connected at the same time, it is possible to continue the communication on the activities.
  • Adopt collaboration tools: This practice has as its main goal the adoption of collaboration tools seeking a greater interaction among the teams, as well as an increment in information sharing.
  • Adopt synchronous communication tools (face-to-face): This practice has as its main goal the adoption of a face-to-face communication tool in order to reduce the geographical distance, as well as maximize the understanding of the shared information. They are those tools that need the participation of distributed teams at the same time. Therefore, teams must be connected at the same time and interact in some way so that communication (especially activities) happens as planned.

• Communication continuous improvement (CC):

  Goal: to continuously promote the maintenance and improvement of the organization’s communication.

  • (4) CC1: Perform analysis of collected data.
  • (4) CC2: Provide guidance on the use of historical data (establishing reliable estimates).
  • (4) CC3: Research, evaluate and monitor new processes, methods and tools to apply in the organization.
  • (4) CC4: Establish, monitor and maintain the strategic action plan for improving the organization’ s communication.

  • Perform analysis of collected data: This practice systematically analyzes the data regarding the preparation, conduction and execution of the communication in the project. The registered data on the communication in the project and its planning, conduction and results must be analyzed in order to identify tendencies and continuously improve the communicative process.
  • Provide guidance on the use of historical data (establishing reliable estimates): This practice establishes reliable estimates about the communication and other areas that the organization should consider relevant based on historical data.
  • Research, evaluate and monitor new processes, methods and tools to apply in the organization: This practice has as its main goal researching, evaluating and monitoring new processes, methods and tools in order to apply them in the organization with the intention of discovering better ways to communicate with stakeholders. This practice tends to be related to the area of innovation.
  • Establish, monitor and maintain the strategic action plan for improving the organization’s communication: This practice has as its main goal the monitoring of the interaction between plan and execution and also seeks to make continuous improvements and corrections of diversions in the communication planning and, consequently, in the communicative process, according to the experience obtained from the plan’s execution.

These factors intend to demonstrate practices of evolution of the organization’s maturity, as well as the understanding of communication planning and effective use of the communication tools, among other factors observed in the context of a project with distributed teams and in the context of the cultural differences.

Each practice can only be placed in one maturity level. However, they must be presented in ascending order of difficulty, allowing an organization to implement them in a gradual manner and according to its strategic objectives.

Implementers and Evaluators

The C2M Model can be evaluated and implemented by the following individuals:

1. Implementers are experts who know how to use the model in a way that offers the most value to business processes. As a result, the C2M implementer must be familiar with the theory and practice of distributed software development, as well as the C2M Model;

2. The evaluator is a professional with expertise in evaluating maturity models, as well as theoretical and practical knowledge of Distributed Software Development, who can contribute positively to the process of evaluating a company w.r.t. the model.

Discussion

A Discussion on the C2M Model and Home Office

With the emergence of the coronavirus (COVID-19) pandemic, countries all over the world were forced to proclaim a state of public emergency, prompting the adoption of social distancing measures to prevent the virus’s spread. As a result, the adoption of the Home Office model (Barros and Silva 2010) was pursued, requiring professionals to conduct their business from the comfort of their own homes.

Actually, when examining issues such as work practices and conceptual elements, the DSD model fits with several characteristics of the Home Office (or Telework) in Software Engineering. It’s worth noting that the DSD model applies to a group of professionals who are distant in geography and time but linked via media resources. Therefore, we believe that much of the content of the C2M Model applies to the Home Office in Software Engineering. We recognize that there are other ideas connected to the home office (and related to communication) that are not covered in this study, but that may be explored in future iterations of the C2M Model. These new concepts include (but are not limited to) behavioral or psychological content about possible interactions with family members during work (Greer and Payne 2014), the lack of physical limits to delimit work environments (Basile and Beauregard 2016), and the perception of overload (Nohara et al. 2010).

Limitations and Threats to Validity

Some limitations could be observed in the study, even with all the precautions and attention of the researchers. Regarding the research method, the limitations are typical of qualitative studies, particularly in the generalization of the results. Additionally, in such a study with strong empirical basis, it was not easy to find companies willing to participate with the desired intensity. Regarding the systematic review, one of the greatest concerns in SLRs is selecting as many relevant studies as possible to answer the research questions and cover 100% of the databases in the limitations of time and resource. Six electronic databases were chosen for the automatic search, being most of them from the list of relevant databases to Computer Science, according to Kitchenham and Charters (2007). Due to the limitations of the search engines, relevant studies still could not be found. To minimize this problem, we performed a manual search in the main conferences and journals of the field. Furthermore, there is also the influence of the researcher in the classification of the studies found in this review process. Regarding the sample of the interview with DSD professionals (the field study), it counted on the participation of 30 professionals. This is not an expressive number itself, as it influences the degree of generalization of the final results. In addition, most of these professionals were not participants in global projects. However, they represent a sample of experts with valuable experience and a relevant potential to contribute with their opinions. Nevertheless, if the generalization is not possible, these data have the validity of being the first results presented in this structure and can be complemented by other studies.

Finally, regarding the survey, it depended exclusively on the good faith and the total capacity of the respondents, and these problems were reduced by the rigor of its planning and execution, as described in Section 6. The following threats to validity were identified:

1. External Validity: the population studied in this survey does not represent the global community of authors in the area of DSD, therefore, it is not possible to say that the research can be generalized. Furthermore, the qualitative analysis of the open questions of the survey is an exploratory assessment and it is not intended to generalize its results, only to help in the understanding of aspects of the research whose analysis could hardly be developed any further using quantitative methods. Even so, according to the results presented, the diversification and characteristics of the research participants contribute to a lower probability that a specific segment of researched specialists could negatively influence our results.

2. Internal Validity: to reduce interpretation errors and doubts about the questions, the researcher met online each respondent individually without influencing them. The objective was merely to make themselves available for eventual questions. This strategy was important to stimulate and motivate the interviewees to answer the questions more confidently and, therefore, obtain an acceptable response rate.

3. Construct Validity: in order to ensure the effectiveness of the presented questions (the instrument of data collection), a previous evaluation of the questionnaire was carried out through a pilot study with 3 researchers, and also the Cronbach’s Alpha coefficient was applied, which is a technique used for evaluating the reliability and internal consistency of data collection instruments. However, we still consider that there is a risk of the questionnaire influencing the participants due to the questions and answer options that were chosen and this may contribute to inaccuracies in the data and limitations to the interpretation of the results. Given this context, we know that the design of the questionnaire may not have been clear or sufficient to ensure that the answers were extracted with the best quality.

4. Conclusion Validity: to analyze the statistical validity of the results, the statistical software IBM SPSS was used, which allows the effective performance of descriptive and inferential statistical analyses, in order to avoid inaccuracy, errors and statistical misinterpretations of the research results, according to Appendix Appendix.

Conclusion

Many companies that adopt DSD are concerned with overcoming the challenges imposed by the physical, temporal and cultural dispersions to develop software projects. In this scenario, the communication stands out, being directly impacted by the cited challenges and intensifying them. A possible solution to handle these challenges is the adoption of improvement initiatives for the communication process aligned with good practices of project management. However, this alone is not enough, since current models and norms do not cover specific problems of a project, and in certain cases of the organization itself. In this case, we are referring mainly to the communication, which in most cases is the identity of a project.

Considering that communication in DSD is a challenging activity, and in order to help the improvement of this concern in such setting, our research proposed a maturity model for communication in DSD named C2M. This model aims to help organizations that conduct DSD projects and wish to improve their communication processes. The model can assist in discovering the maturity of processes and practices related to communication problems, in addition to promote process improvement in DSD. The main objective of our research has been achieved with the proposal of the C2M model, contributing in an innovative way to DSD projects by providing a maturity model for communication, as described in Section 6.2.

During the development of this research it was possible to identify the main maturity models in general and also specifically in the DSD area (such as WAVE, OMM, OSM and PMF), taking into consideration everything from history to mandatory characteristics, to the conception of a maturity model. After analyzing the maturity models, we realize that none of these models has focused on communication. Some even promote a more practical, underdeveloped approach. Given this context, it is apparent that the model proposed by this research focuses on the differential maturity of communication where the organization can improve its communication process continuously. In addition, C2M can be implemented in conjunction with the other models, seeking, therefore, to complement what they lack. C2M was developed incrementally: first informed by literature, next supplemented by empirical studies. We promoted a refinement and evaluation of the C2M model in a two-step process: first, we conducted two focus group meetings aiming to initially evaluate the C2M model (alpha version) by identifying how it can fulfill its purpose, and then we submitted the revised model (beta version) to expert opinions. After that, the omega version was created, which is an evolution of the beta version. It was conceived after the evaluation made by 55 experts according to phase III of Fig. 1. We have observed some indications that C2M maps communication aspects of real-life projects and that it can be feasibly applied in practice.

Table 9 brings a synthesis of the related work. The comparing criteria were selected from Pilatti et al (2006). The analyzed models bring significant results to the DSD projects, but there are still gaps to be treated. The present work defines a maturity model for communication in DSD (C2M) as a form of filling some of these gaps not attended by the models presented in this section. The C2M has its differential in the use of practices for the communication, seeking to improve the communicative process of the organization, clear identification of the needs for a more effective communication to support the success of the project. In addition, the C2M Model is compatible and complementary with other maturity models, such as the MPS.BR/CMMI (Vieira et al. 2020).

Table 9.

Comparison of models with C2M

Analysis criteria	Maturity models
	OSM	OMM	PMF	WAVE	C2M
Governance	Non-adherent	Fully Adherent	Non-adherent	Non-adherent	Non-adherent
Process Maturity	Fully	Fully	Fully	Fully	Fully
or Capability	Adherent	Adherent	Adherent	Adherent	Adherent
Implementation	Partially	Partially	Partially	Partially	Partially
and deployment	Adherent	Adherent	Adherent	Adherent	Adherent
Alignment with	Non-adherent	Fully	Non-adherent	Partially	Partially
other models		Adherent		Adherent	Adherent
Focus in the social aspect of the communication	Non-adherent	Non-adherent	Partially	Non-adherent	Fully
			Adherent		Adherent

The main motivation for the development of C2M was the lack of studies on how to evaluate communication in DSD (De Farias Junior et al. 2012), as well as organizational difficulties in dealing with communication problems in this scenario (Damian and Zowghi 2002; Herbsleb and Moitra 2001; Prikladnicki et al. 2011). Our work offers the following contributions to the DSD industry and academia: (I) we provide a consolidated understanding of communication practices in DSD; (II) we provide a maturity model to support communication processes in DSD; and (III) we report on real-case projects demonstrating that C2M is feasible in practice and can add value to a software organization.

Theoretical and Practical Implications

To the academia, the proposed research contributes to the field of Software Engineering, by identifying the implications of communication in DSD environments. Furthermore, it also contributes to the understanding of the influence that non-technical aspects like communication have over distributed software development projects. Also worth noting is the conception of the maturity model itself, which was based in uniquely qualitative studies. The set of best practices can be also considered a contribution, once it was extracted from the same methodological process which generated the C2M model.

From the point of view of the software industry and the professionals involved, the proposed model aims to to support organizations to significantly improve the way they communicate. In this sense, we can cite some concrete implications for the industry: i) Stimulating and establishing a new culture with a focus on relevance communicative process of the project; ii) Guide to best practices for improving communication; iii) Increased productivity; iv) Reduction of errors in the planning of the communicative process; v) Agility and effectiveness; vi) More Flexibility and competitiveness; and finally, vii) Defining the steps for implementing C2M Model (Appendix Appendix).

We recently assess two companies on the C2M Model on real projects. The idea was to generate value for the two voluntary organizations and, at the end, to calibrate the model, so that it can benefit even more organizations, whether small, medium or large (more details about the assessment in Appendix Appendix).

Future Research

Considering the scope of the proposed model, we identified some opportunities for further studies. It is understood that the C2M model must be used by the organizations aiming to identify how they respond to the proposed practices. To do so, there is the possibility of the elaboration of a C2M evaluation guide for companies who seek to improve their communication processes continuously. In addition, another possibility is to develop a computational tool to support the proposed model, made available for every organization that wants to use it. Finally, we propose the implementation of the C2M model in real projects and the conduction of evaluations with the purpose of verifying its effectiveness regarding the communication process.

Biographies

Ivaldir de Farias Junior

has a PhD in Computer Science (Federal University of Pernmabuco, 2014). He is an Adjunct Professor at the University of Pernambuco (UPE) Campus Garanhuns, in Computer Science and Software Engineering undergraduate courses. Research areas of interest include: Maturity and Capacity Models and Distributed Software Development areas, including the Communication phenomenon in those teams. Performing in Development and Innovation in Software Engineering, as well as in Process Improvement, Agility, and Project Management. Ivaldir de Farias Junior is also a professor of PPGEC, the Postgraduate Program in Computer Engineering at UPE/POLI.

Sabrina Marczak

is an Adjunct Professor in the School of Technology at PUCRS University, Brazil. She co-leads the MunDDoS Research Group, which mostly conducts industry-based research in Software Engineering. Her research is on Software Process Improvement and Human Aspects in Software Development.

Rodrigo Santos

received the Ph.D. degree in computer science from the Alberto Luiz Coimbra Institute for Graduate Studies and Research in Engineering, Federal University of Rio de Janeiro(UFRJ), 2016. He is currently an Associate Professor with the Department of Applied Informatics, Federal University of the State of Rio de Janeiro (UNIRIO), where he leads the Complex Systems Engineering Laboratory (LabESC). His research interests include complex systems engineering (specially software ecosystems and systems-of-systems) and software engineering education.

Cleyton Rodrigues

has a PhD in Computer Science (Federal University of Pernmabuco, 2019). He has experience in the field of Artificial Intelligence, with an emphasis on Logic Programming, Knowledge Representation, Agents, Ontologies and Machine Learning. He is currently an Adjunct Professor at the University of Pernambuco (UPE) Campus Garanhuns, in Computer Science and Software Engineering undergraduate courses. Cleyton Rodrigues is also a permanent professor and vice-coordinator of PPGEC, the Postgraduate Program in Computer Engineering at UPE/POLI.

Hermano Moura

Professor of Software Engineering at Federal University of Pernambuco (Recife, Brazil). PhD in Computing Science, University of Glasgow, Scotland. MSc in Computing Science, Federal University of Pernambuco, Brazil. Electronic Engineer from Federal University of Pernambuco, Brazil. PMP - Project Management Professional by Project Management Institute. Research areas of interest include: management of software projects; software process improvement; strategic planning of information systems.

Appendix A: Secondary Studies Identified in the Tertiary Study

The contents of this appendix can be accessed through the link: 10.5281/zenodo.6546618

Appendix B: Quality Assessment (Tertiary Study)

The contents of this appendix can be accessed through the link: 10.5281/zenodo.6546680

Appendix C: Mapping of C2M Practices and Factors from Secondary Studies

The contents of this appendix can be accessed through the link: 10.5281/zenodo.6546741

Appendix D: SLR Protocol Evaluation

The contents of this appendix can be accessed through the link: 10.5281/zenodo.6546690

Appendix E: Selected Primary Studies from SLR

The contents of this appendix can be accessed through the link: 10.5281/zenodo.6555117

Appendix F: Sources of Primary Studies Identified in the SLR

The contents of this appendix can be accessed through the link: 10.5281/zenodo.6546749

Appendix G: Mapping of C2M Practices and Primary Studies from SLR

The contents of this appendix can be accessed through the link: 10.5281/zenodo.6546760

Appendix H: Script of the Semi-structured Interview

The contents of this appendix can be accessed through the link: 10.5281/zenodo.6546762

Appendix I: Interviews Professionals DSD Technical Report

The contents of this appendix can be accessed through the link: 10.5281/zenodo.6546769

Appendix J: Survey Questionnaire

The contents of this appendix can be accessed through the link: 10.5281/zenodo.6546771

Appendix K: Evaluation of the C2M Model

The contents of this appendix can be accessed through the link: 10.5281/zenodo.6546775

Appendix L: Steps for Implementing C2M Model

The contents of this appendix can be accessed through the link: 10.5281/zenodo.6590200

Appendix M: Details of C2M Model: Factors, Goals and Practices

• Management of cultural differences (CD):

  Goal: to understand the difficulties that exist due to cultural differences and prepare the teams who act in DSD projects to be aware of and respect such differences.

  • (2) CD1: Establish policies for the recruitment and selection of new talents for the project.
  • (2) CD2: Identify and institutionalize the cultural context of each team in the project.
  • (3) CD3: Establish a cultural knowledge basis.
  • (3) CD4: Standardize the jargon and vocabulary of the project.
  • (3) CD5: Plan initiatives to mitigate occurrences caused by cultural differences.

  • Establish policies for the recruitment and selection of new talents for the project: This practice has as its main goal the establishment of guidelines for the recruitment and selection processes considering the project’s scenario.
  • Identify and institutionalize the cultural context of each team in the project: This practice has as its main goal the institutionalization of all the information regarding the team’s cultural diversity for all stakeholders.
  • Establish a cultural knowledge basis: This practice has as its main goal the establishment of a management of the knowledge about the distributed teams’s cultural diversity.
  • Standardize jargon and vocabulary of the project: This practice has as its main goal the standardization of jargon and vocabulary, avoiding noise (misunderstandings) in the communication.
  • Plan initiatives to mitigate occurrences caused by cultural differences: This practice aims to create a mitigation plan for reducing the probability of occurrences or impacts caused by cultural differences.

• Trust Development (TDE):

  Goal: to solve or minimize the difficulties derived from the lack of confidence between teams.

  • (3) TDE1: Establish strategies for stakeholders’ integration.
  • (3) TDE2: Promote interchange by members from distributed teams of a given project.
  • (3) TDE3: Encourage the collaboration and cooperation between the teams.

  • Establish strategies for stakeholders’ integration: This practice describes the strategies used by the organization to integrate and socialize the teams (members) with one another. At this point, it is important to integrate the teams with the mission, values and objectives of the organization.
  • Promote interchange by members from distributed teams of a given project: This practice addresses the development of trust and a more effective communication among the members of different teams. It also allows the team member to have better informal communication with other team members, as well as to experience the daily challenges of the team, facing a different culture among many other factors.
  • Encourage the collaboration and cooperation between the teams: This practice focuses on providing a collaborative environment that has the involvement of all team members and supplies them with tools and processes that favor interaction and ideas/decision sharing.

• Tools to support communication (TC):

  Goal: to make adequate use of the existing tools considering the scenario of distributed teams.

  • (2) TC1: Adopt asynchronous communication tools on demand.
  • (2) TC2: Adopt collaboration tools.
  • (3) TC3: Adopt synchronous communication tools (face-to-face).

  • Adopt asynchronous communication tools on demand: This practice focuses on defining the adoption of synchronous or asynchronous tools (or both) based on the specific needs of the projects. Asynchronous tools are those that do not need to be connected in real time at the same time. Therefore, even if the participants of the distributed teams are not connected at the same time, it is possible to continue the communication of the activities.
  • Adopt collaboration tools: This practice has as its main goal the adoption of collaboration tools seeking a greater interaction among the teams, as well as an increment in information sharing.
  • Adopt synchronous communication tools (face-to-face): This practice has as its main goal the adoption of a face-to-face communication tool in order to reduce the geographical distance, as well as maximize the understanding of the shared information. They are those tools that need the participation of distributed teams at the same time. Therefore, teams must be connected at the same time and interact in some way so that communication (especially activities) happens as planned.

• IT infrastructure (INF):

  Goal: to plan the infrastructure to be provided to the distributed teams.

  • (2) INF1: Define the infrastructure taking into consideration the level of the team’s dispersion.
  • (2) INF2: Monitor the infrastructure periodically.
  • (3) INF3: Maintain the infrastructure’s backup.

  • Define the infrastructure taking into consideration the level of the team’s dispersion: This practice defines the IT infrastructure taking into account the dispersion level (local, regional, national, continental or global) and also provides enough infrastructures for the project to run without any impediments.
  • Monitor the infrastructure periodically: This practice continuously checks if the infrastructure can support the project flow with no impediments.
  • Maintain the infrastructure’s backup: This practice keeps a backup of the IT infrastructure to minimize the impact of a failure.

• Management of the geographical distance (GD):

  Goal: to understand and improve the levels of perception of physical distance between teams.

  • (2) GD1: Plan face-to-face meetings.
  • (2) GD2: Plan and perform frequent communication.
  • (3) GD3: Establish a discussion forum in the project.
  • (3) GD4: Plan initiatives to mitigate occurrences caused by geographical distance.

  • Plan face-to-face meetings: This practice addresses planning meetings that can be held face-to-face or through use of a communication tool.
  • Plan and perform frequent communication: This practice plans and holds frequent communication, which can be performed according to the organization’s plans, but cannot be ceased. All the stakeholders must be informed about everything that happens in the organization and in the project.
  • Establish a discussion forum in the project: This practice establishes a communication channel that promotes debates regarding a theme, a question in evidence or any problem.
  • Plan initiatives to mitigate occurrences caused by geographical distance: This practice produces a mitigation plan for reducing the probability of occurrences or impacts caused by geographical distance.

• Management of the temporal distance (TD):

  Goal: to understand and improve the levels of perception of temporal distance.

  • (2) TD1: Plan and manage the synchronization of the team’s schedules.
  • (2) TD2: Plan and execute the tasks’ continuity (handoffs).
  • (3) TD3: Plan and manage the follow-the-sun strategy (almost continuous development).
  • (3) TD4: Plan initiatives to mitigate occurrences caused by temporal distance.

  • Plan and manage the synchronization of the team’s schedules: This practice holds a common shift for all teams that work in a distributed way (whenever possible). This practice also applies when the team is not physically distant but is temporally distant, i.e., work in different shifts.
  • Plan and execute the tasks’ continuity (handoffs): This practice has as its main goal the effective planning and execution of handoffs (activities/tasks), i.e., when a team ends its working day, another one continues the project.
  • Plan and manage the follow-the-sun strategy (almost continuous development): This practice has as its main goal the establishment of a follow-the-sun strategy with a focus on the reduction of the time-to-market, accelerating the development of the final product from conception to distribution.
  • Plan initiatives to mitigate occurrences caused by temporal distance: This practice creates a mitigation plan to reduce the probability of occurrences or impacts caused by temporal distance.

• Stakeholders’ management (SM):

  Goal: to perform the planning and management of stakeholders, considering the profile and proficiency needed for the project.

  • (2) SM1: Identify the stakeholders.
  • (2) SM2: Define roles and responsibilities.
  • (3) SM3: Plan the stakeholders’ management.
  • (4) SM4: Monitor the relationship with the stakeholder.

  • Identify the stakeholders: This practice identifies the stakeholders in the project. Some examples of people and organizations that might be of interest: I) Clients; II) Leader or manager of the project; III) Sponsors; and IV) Users.
  • Define roles and responsibilities: This practice defines and describes the roles and responsibilities. It is important that those are described clearly and objectively.
  • Plan the stakeholders’ management: This practice specifies the management of the concerned parties, as well as planning, managing and controlling the engagement of these stakeholders.
  • Monitor the relationship with the stakeholder: This practice monitors the stakeholders systematically and then evaluate the relationship’s level among all related to the project. Through this monitoring and evaluation, it will be possible, for example, to determine which teams/members communicate and interact more.

• Monitoring, measurement, and analysis (MA):

  Goal: to provide input to develop and maintain the capacity to monitor, measure and analyze distributed projects’ data, aiming to provide information to the business executive or manager responsible for running an organization.

  • (4) MA1: Establish the measurement objective.
  • (4) MA2: Establish procedures to gather, store and analyze the data.
  • (4) MA3: Communicate the measurement results.

  • Establish the measurement objective: This practice establishes the goals of communication measurement and other information needed. An organization/project has a set of needs of information communication that should be addressed. These needs for information must derive from goals.
  • Establish procedures to gather, store and analyze the data: This practice systematically analyzes the data that concerns the preparation, conduction and execution of communication in the project. The recorded data on the communication in the project and its planning, conduction and results must be analyzed in order to identify tendencies and continuously improve the communication process.
  • Communicate the measurement results: This practice ensures that the measured communication data will be passed on.

• Communication planning (CP):

  Goal: to plan the communication from the beginning to the end of the project.

  • (2) CP1: Establish a communication strategy.
  • (2) CP2: Establish mechanisms to confirm the understanding of the activities.
  • (2) CP3: Establish a standard language for the project.
  • (2) CP4: Establish a communication plan.
  • (2) CD5: Establish the commitment of stakeholders with the communication planning.
  • (2) CP6: Define a focal communication point (communication interlocutor).
  • (2) CP7: Manage the data (artifacts) of the project.
  • (3) CP8: Periodically provide information about the performance of the project and the team.
  • (3) CP9: Plan and manage the meetings.

  • Establish a communication strategy: This practice has as its main goal the establishment of a method or a group of methods chosen for the accomplishment of the communication goal, as well as the alignment of the communication process with the business’ goals and strategies. In this context, it is essential to specify the communication objectives.
  • Establish mechanisms to confirm the understanding of the activities: This practice creates means to verify if the distributed teams (receivers) clearly understood all the activities, information and communication, ensuring that the understanding (of the sender) is reliable. As the activities are changed, a new verification must be done in order to confirm the understanding of the involved teams or leaders.
  • Establish a standard language for the project: This practice defines a communication standard and promotes its comprehension to the members of the teams involved in the project.
  • Establish a communication plan: This practice aims to describe all the communication needs, i.e. where, when, how and in what format the information will be distributed/communicated to the stakeholders. Therefore, it is essential to define who will be responsible to provide the different communication means. The communication plan gives support to the project’s plan. Usually, a communication plan provides some significant information, such as:

    • Person responsible for the communication of information;
    • Person responsible for authorizing or liberating documents or confidential information;
    • Communication methods and media for transmission of information;
    • Resources allocated to communication activities (e.g., time and budget);
    • Glossary with common terminology;
    • Communication restrictions usually derived from organizational policies, laws or specific norms.
  • Establish the commitment of stakeholders with the communication planning: This practice verifies the understanding of the teams regarding all the information established in the communication plan and, then, the manager requires the commitment of the team members with everything that was established in the communication plan.
  • Define a focal communication point (communication interlocutor): This practice defines a person responsible for the communication in the distributed team. This action seeks to decrease noise in the communication and centralize it in order to avoid misunderstandings among the teams.
  • Manage the data (artifacts) of the project: This practice has as its goal to identify and plan artifacts and relevant data for the project, as well as describe ways to store and distribute them. There must be a mechanism established for the artifacts that includes privacy and safety issues.
  • Periodically provide information about the performance of the project and the team: This practice aims to provide the information needed about the project’s performance and team, as planned. Whenever possible, indicators must be used for assessing the effectiveness of the project or teams. For example:

    • Productivity growth of the project or team;
    • Reduction of turnover rate;
    • Indicators of organization climate surveys;
    • Intensity of communication between the teams.
  • Plan and manage the meetings: This practice defines the planning of meetings clearly, which consists of outlining and disclosing the agenda, defining the facilitator, the writer and the material to be used in the meeting, the time, place, objectives, expected results and, finally, the information for the participants. In what follows, we will present some types of meetings:

    • Kickoff meeting: Start the project engaging the stakeholders, mainly the project team;
    • Planning meetings: For discussing and elaborating the plans to be developed;
    • Follow-up meeting: known as monitoring meeting. Followed by project parameters, such as deadlines, costs, quality etc.;
    • Change control meeting: allow the analysis of change requests;
    • Audit meetings: assess products or processes;
    • Continuous improvement meetings: Representatives of every sector, together with the management, promote meetings in order to assess new processes, technologies and strategies that are to be applied in the company, if/when decided by the committee. This meeting focuses on continuous improvement.

• Continuous communication improvement (CC):

  Goal: to continuously promote the maintenance and improvement of the organization’s communication.

  • (4) CC1: Perform analysis of collected data.
  • (4) CC2: Provide guidance on the use of historical data (establishing reliable estimates).
  • (4) CC3: Research, evaluate and monitor new processes, methods and tools to apply in the organization.
  • (4) CC4: Establish, monitor and maintain the strategic action plan for improving the organization’s communication.

  • Perform analysis of collected data: This practice systematically analyzes the data regarding the preparation, conduction and execution of the communication in the project. The registered data on the communication in the project and its planning, conduction and results must be analyzed in order to identify tendencies and continuously improve the communicative process.
  • Provide guidance on the use of historical data (establishing reliable estimates): This practice establishes reliable estimates about the communication and other areas that the organization should consider relevant based on historical data.
  • Research, evaluate and monitor new processes, methods and tools to apply in the organization: This practice has as its main goal researching, evaluating and monitoring new processes, methods and tools in order to apply them in the organization, with the intention of discovering better ways to communicate with stakeholders. This practice tends to be related to the area of innovation.
  • Establish, monitor and maintain the strategic action plan for improving the organization’s communication: This practice has as its main goal the monitoring of the interaction between plan and execution and also seeks to make continuous improvements and corrections of diversions in the communication planning and, consequently, in the communicative process, according to the experience obtained from the plan’s execution.

• Risk management (RM):

  Goal: to identify threats and monitor risks.

  • (2) RM1: Identify communication risks.
  • (2) RM2: Evaluate, categorize and prioritize communication risks.
  • (2) RM3: Identify the relevant stakeholders associated to each risk.
  • (3) RM4: Elaborate plans of risk mitigation.

  • Identify communication risks: This practice identifies, analyzes and plans actions to deal with the communication risks, analyzing their impact, chances of occurrence and priorities for the treatment.
  • Evaluate, categorize and prioritize communication risks: This practice has as its main goal to identify, evaluate and categorize the risks. Furthermore, the priority of each identified risk must be determined. For the identification of the risks, some tools can be used, such as I) Risk taxonomy; II) Risk evaluation; III) Checklists; and IV) Brainstorming.
  • Identify the relevant stakeholders associated to each risk: This practice identifies the relevant interested parts associated to each risk, i.e. all the stakeholders that are impacted by the risks as well as the stakeholders who can manage and solve the problem if the risk occurs.
  • Elaborate plans of risk mitigation: This practice creates a document which lists the probability of a risk event in a project and also suggests actions to reduce the potential impacts if they occur.

• Communication patterns and policies (PP):

  Goal: to establish and maintain communication policies and practices that add value to the project.

  • (2) PP1: Establish a communication policy.
  • (3) PP2: Establish documentation and communication standards.

  • Establish a communication policy: This practice promotes the integrated communication in the organization, aiming to maintain a good relationship between the collaborators, in an aligned, coordinated and synergistic way, having as basis the guidelines of the strategic communication planning. The communication policies must communicate the expectations of the organization about the communicative process and make all these expectations visible to those who it affects. This policy must inform what is expected in the execution of the communicative process without specifying how it must be executed.
  • Establish documentation and communication standards: This practice aims to standardize the written documentation, as well as how it is communicated to the stakeholders. The main objective of the standardization is the reduction of the variability of the work processes, which is the way that documents are elaborated and communicated. Standardizing implies reaching the expectations of the stakeholders while not subjecting them to monotonous routines and tough/autocratic norms. The organization must seek a pattern for the documentation and communication that brings benefits to the project.

• Communication training program (CT):

  Goal: to develop abilities and knowledge in communication or in areas that support the communication between project members in order to perform their role effectively.

  • (3) CT1: Plan communication training.
  • (3) CT2: Provide communication training.
  • (3) CT3: Register communication training
  • (4) CT4: Assessment of the communication training benefits.

  • Plan communication training: This practice establishes an organizational training program. The strategic objectives of the organization must be analyzed to identify potential training necessities in communication (or in areas that support communication). The training planning must fill knowledge gaps and introduce new technologies and changes in the business area, among others. From the identified training necessities, a strategic training program must be created containing: training necessities, training topics, training schedules, and methods used for training. This training program must be periodically revised.
  • Provide communication training: This practice promotes training according to the established training program. Examples of training approaches that must be used include:

    • Formal training in a classroom or through video lessons;
    • Study group;
    • Mentoring;
    • Workshops.
  • Register communication training: This practice defines training records. These must contain a list of stakeholders who participated in the training, date, name of the instructor, and name of the course/training. In the case of the impossibility of someone’s participation, this event must be documented with management approvals when applicable.
  • Assessment of the communication training benefits: This practice performs assessments of the benefits (effectiveness) of the received training. Some forms of assessment of the training’s benefits/effectiveness include:

    • Questionnaires after the training’s execution;
    • Satisfaction questionnaires for the managers about the applicability of the knowledge obtained through the training.

• Configuration management (CM):

  Goal: to establish and maintain the integrity of the artifacts generated (work products) along the project, as well as align the communication regarding the code evolution and the revision of documents.

  • (3) CM1: Establish the control of versions and modifications.
  • (3) CM2: Establish access control to the configuration items.
  • (3) CM3: Establish a configuration plan for the whole project.

  • Establish the control of versions and modifications: Set of activities designed to control change by identifying the work products that will be changed, establishing a relationship among them, defining mechanisms for managing different versions of these products, controlling the changes and communicating them to stakeholders.
  • Establish access control to the configuration items: This practice defines access levels to maintain the control of configuration items. The description of this practice is detailed in the plan of configuration management.
  • Establish a configuration plan for the whole project: This practice creates norms, tools and templates that allow a person to manage the configuration items of a system satisfactorily.

• Requirements Elicitation and Specification (ES):

  Goal: to promote a better understanding of the elicitation and specification of requirements, in order to improve the spoken and written communication about the artifacts of this activity.

  • (2) ES1: Obtain the confirmation that the team understands the software requirements.
  • (2) ES2: Manage changes in the software requirements.
  • (3) ES3: Maintain the traceability of the software requirements.

  • Obtain the confirmation that the team understands the software requirements: This practice ensures that the software requirements are clearly written without redundancies or ambiguities. Some criteria are:

    • Clarity and correctness;
    • Completeness;
    • Traceability.
  • Manage the changes in the software requirements: This practice manages the changes that occur in the requirements during the project’s execution. We know that the requirements change for several reasons (e.g., changes in the needs of the client, changes in the law etc.). Thus, new requirements may be included and changes may occur in the existing requirements. It is necessary to analyze the impact of the changes in an effective way. Keeping track of all changes in requirements is mandatory. A way to perform the impact analysis of requirement changes is the use of traceability or the stakeholders’ point of view. Finally, data of the requirements and the changes should be made available to stakeholders.
  • Maintain the traceability of the software requirements: This practice establishes the capacity to trace a project requirement to other requirements or even to other correlated elements. The main purposes of the traceability are:

    • Understanding the requirements’ conception;
    • Managing the requirements;
    • Assessing the impact of change of a requirement in the project.

Appendix N: Identifying the Maturity of Communication Processes in Distributed Software Development of Two Software Organizations

The contents of this appendix can be accessed through the link: 10.5281/zenodo.6635009