«This research has been partially sponsored by the Dutch Joint Academic and Commer- cial Quality Research & Development (Jacquard) program on Software ...»
• Second, the use of collaboration tooling can help to create a single, shared environment across development sites. A single, shared environment can improve the efﬁciency of the communication between different groups that is anyhow needed, despite possible communication reduction efforts. Such an environment should form the entry point to revert to when communication across development teams is required. The environment should provide an overview of ‘who is who’ in the teams at the different development sites. At a minimum, contact information, role and responsibilities, and a mugshot (Herbsleb et al., 2005) should be included in the overview. In addition, these tools need to provide awareness of the availability of practitioners at other development sites. Collaboration technologies such as instant messaging, a wiki, or message-boards can lower the threshold of actually establishing contact and communicating with another site. The most appropriate tooling for a given situation depends foremost on the time difference that exists between development sites. The tools should allow architects and other practitioners to record design decisions (Herbsleb and Grinter, 1999a) in an easy and accessible way.
One word of warning, though. Although the use of collaboration tooling adds value, they are not a panacea. Face-to-face communication (ad hoc) remains essential for successful GSD (Herbsleb and Grinter, 1999a).
Architectural rules can help to overcome the challenge of building a team. First of all, a list of all employees involved in the project can be provided, along with their responsibility towards parts of the architecture. Second, the architectural rules can provide conventions on the use of collaboration tooling, by addressing what information is stored, where it can be found, and who is responsible for keeping the information up to date.
No collective ownership When GSD organizations have dedicated owners of parts of the source code, this introduces delays in corrective maintenance. When it is not possible for practitioners to modify the source code that is not owned by them, additional (formal) communication with the owner becomes necessary to acquire a common understanding. In addition, it becomes necessary that the practitioner is able to transfer the sense of urgency he has to the owner of the source code.
The problems described above can be addressed by introducing collective ownership of (parts of) the source code and other documents. Collective ownership of source code and other documents means that all individuals collaborating in a software project (possibly located at multiple development sites) can work on any model or artifact in that project (Ambler and Jeffries, 2002). Often, collective ownership is supported by having one shared conﬁguration management system with a single source code tree that is accessible (Herbsleb et al., 2005). As such, collective ownership reduces the view of ‘them against us’ often experienced in multiple teams (Herbsleb and Mockus, 2003).
For large software development projects this could lead to collective ownership within
634. Reassessing the Need for Practices for Architectural Compliance
subteams (consisting of employees of all development sites) that work on a designated part of the system.
The possibility of changing source code freely should be accompanied by communication guidelines, a sound test set, and frequent builds of the software. Communication guidelines at a minimum should involve contacting other known users or developers of the source code and informing them that a change is being made. The test set ensures that a change does not introduce bugs in other parts of the source code or introduces non-compliance with architectural rules. Frequent builds address the possible delay between carrying out a change and verifying the correct behavior of the resulting source code (Herbsleb et al., 2005). Aforementioned topics need to be communicated uniformly across the GSD organization. Architectural rules can help to do that by deﬁning the mandatory policy on these topics.
4.3.4 Challenge 4: Work distribution In global software development, different teams from across the globe need to deliver working software in time. In addition to the communication challenges experienced by these teams (see Challenge 2), the organization of the teams itself and the variety of software development activities they need to perform play a signiﬁcant role. We
identiﬁed the following two issues in the literature:
6. Difﬁculty to align tasks and duties
7. No uniform process Difﬁculty to align tasks and duties The software architecture serves as a basis for distributing work. Ambiguities in the software architecture or frequent replanning of tasks leads to a lack of insight into the interdependence of tasks of the teams involved (Mullick et al., 2006). In addition, the distribution of work is hampered when engineering tasks are not understood.
This all results in long discussions that add up to the delays already experienced in GSD (Herbsleb and Mockus, 2003). Furthermore, Herbsleb and Mockus show that the amount of discussions generally does not decrease in the course of the project.
A possible solution to this lack of understanding of tasks is to distribute tasks and work only when the architecture is stable enough. Architectural rules could specify when such is the case. For example, architectural rules could describe that the architecture description should elucidate how all ‘must-have’ requirements are addressed and that an independent veriﬁcation of the architecture (e.g., by the quality assurance team) should have taken place.
No uniform process As Mullick et al. show, it is essential to have a uniform strategy towards software engineering processes and team processes. A development organization that has different strategies towards these processes experiences delays (Mullick et al., 2006). An example of different strategies towards software engineering processes can occur during integration. Different approaches towards this integration phase exist: 1) a dedicated
64 4.3. Challenges in Global Software Development
integration team accepts all subsystems and is responsible for the integration, or 2) integration is the responsibility of all teams involved in delivering the subsystems that need to be integrated. When an organization chooses to have a dedicated integration team that integrates the subsystems, the integration team needs to assure itself of the correct working of the subsystems supplied. Furthermore, when issues arise, members of the development teams should stand by to provide assistance. Although this solution is considered to be less resource-consumptive, it is hampered by time differences and causes delays because practitioners located at different sites communicate less effectively (Herbsleb and Mockus, 2003). Especially at integration time, the need is high for fast-paced interactions to quickly solve bugs once they are discovered (Herbsleb et al., 2005). Consequently, it can prove beneﬁcial to have a dedicated team consisting of representatives from the different development teams at a single location integrate the subsystems into the desired release.
The example above shows that it is of paramount importance to have a uniform description of how integration should occur in projects. A non-uniform description of the integration process leads to delays because of ambiguity in task description. Similarly, process guidelines should exist for other software development processes, such as build processes and change management processes. Mullick et al., for instance, make note of broken builds because of a lack of a uniform conﬁguration management strategy (Mullick et al., 2006). Examples on this topic are also given by (Herbsleb and Grinter, 1999a), reporting on problems when not having single-branched (Herbsleb et al., 2005) distributed change management across development sites.
Processes are an effective means to organize teams and their interrelationships and to distribute and communicate work that needs to be done (Herbsleb and Grinter, 1999a).
Organizations need to put emphasis on team organization and communication processes in addition to software engineering processes. The team organization and communication processes need to focus on a communication structure (including a description of the roles and responsibilities of the various teams) and interactions between various types of teams (including the knowledge they exchange, at what stages or milestones in the development process they interact, and the frequency of interaction (Mullick et al., 2006)). Especially, the tasks and role of the architecture team should be exempliﬁed so that all practitioners understand this pivotal role. Although these process are not specifically aimed at catering for unplanned and informal communication, they can provide insight into the responsibilities of teams and the communication strategy across teams.
In conclusion, organizations involved in GSD need to focus on a set of processes that aids team organization and work distribution. These processes can have a technical topic, such as integration, branching, and releasing, as well as topics like work distribution and communication structure. Having these processes for software engineering and team organization and communication alone is not enough, though. In addition, it is necessary to communicate the processes consistently (Mullick et al., 2006) and to ensure that the processes are understood and followed.
654. Reassessing the Need for Practices for Architectural Compliance
4.4 Organizations’ Solutions to GSD Issues Using the list of issues presented in §4.3, we studied two organizations involved in global software development. The aim of this study is to see how these organizations use architecture and architectural rules to overcome the issues. We conducted semistructured interviews with two architects at each organization to obtain responses to the issues. In addition, we used the information collected in the case study performed at Organization A on which reported in Chapter 3. We veriﬁed our interpretation of the answers with the interviewees. For each organization, we ﬁrst give a general impression of that organization. Next, we delve into the seven issues and show how the organization addresses each issue.
4.4.1 Organization A Organization A uses four sites located on separate continents to develop software for different consumer electronics products. The development of each product is done in a project, in which a number of subsystems need to be integrated. Each of these subsystems is developed by a subsystem team located at a single development site. The subsystem team owns the source code of that subsystem. Subsystem teams consist of a subsystem architect, a conﬁguration manager, an event manager, and several software engineers. Integration of the subsystems into the ﬁnal product is done by a dedicated team located at the main development site. In total, about 300 employees work in the various teams.
The organization uses a product-line architecture to support various projects in which the consumer electronics products are developed. The architecture is maintained by a central architecture team located at a single development site. The architecture team maintains the architecture, by a.o. describing architectural rules in small, textbased documents. These rules only cover issues that hold for all subsystems. Issues pertaining to individual subsystems need to be addressed by subsystem architects. This results in a certain degree of freedom for subsystem teams.
1. Difﬁculty to initiate contact – As a general policy of Organization A, architects visit the largest remote development site one week each month. Other key individuals, such as senior software engineers and members of the integration team, do not travel that much. Practitioners indicated that this travel policy did not overcome the lack of trust as part of cultural challenges completely. Recently, Organization A was conducting a transfer of software development activities to the largest remote development site and retained the architecting activities at the main development site. This resulted in a lack of motivation of some of the employees at the remote development site because they felt this would decrease their inﬂuence on the major design decisions.
2. Difﬁculty to exchange information – Organization A uses a collaboration infrastructure that provides a detailed overview of the teams involved in a software development project, including the members, the roles, and responsibilities. In addition, the mugshots of the team members are made available as well. The collaboration infrastructure is linked with the conﬁguration management infrastructure: information on builds,
66 4.4. Organizations’ Solutions to GSD Issues
releases, and problems is extracted from the conﬁguration management system and published on each subsystem team’s website. Together with a description of the members of the team and the team organization, this website is one of the primary sources of information for other subsystem teams. Besides using the website to obtain information, the organization uses email communication and instant messaging technology regularly to allow discussions between the subsystem teams and between the architecture team and subsystem teams. As a matter of fact, Organization A regards team composition and team contact details as the most important information, as was shown in Chapter 3.
Aforementioned collaboration infrastructure lowers the threshold for exchanging information at Organization A. However, other issues with GSD still burden fully effective exchange of information.
3. Difference in sense of urgency – The organization experiences difﬁculty in maintaining a shared sense of urgency, judging by an example given: