«This research has been partially sponsored by the Dutch Joint Academic and Commer- cial Quality Research & Development (Jacquard) program on Software ...»
Frequent interaction across sites – The organization uses a wide variety of means to ensure sufﬁciently frequent interaction across sites: periodic meetings (e.g., weekly or biweekly) to share concerns such as planning issues, bottlenecks, and estimates, the use of video-conferencing and Communicator for face-to-face interaction and desktop/code sharing, and of course email and phone communication. Our analysis shows that especially Communicator-tooling for e.g., video-conferencing is greatly appreciated and meant to lower the barriers of distance in collaboration with remote sites; these ﬁndings support the ﬁndings from (Damian et al., 2009). However, despite this variety of means, employees indicate that they do not automatically share the result of these local or informal discussions (e.g., coffee-talk) to other sites; rather, the request for that knowledge should be put forward by the other site. This is inherent in the philosophy of the organization: take responsibility, and ask colleagues when needed. We have identiﬁed clear differences in the preference to use either the phone (synchronous communication, a
Figure 9.2: Excerpt of mapping the content analysis results to a part of our validation model (negations shown in dashed lines, the architectural knowledge management practice ‘frequent interaction across sites’, site B).
higher sense of urgency transferred) or email to share information or ask questions;
some people ﬁnd themselves more conﬁdent in using email because it allows them to verify their writings before actually communicating them (i.e., sending the message).
These difﬁculties lie in language barriers (socio-cultural distance) and misinterpretation. At site A, the need for a single whiteboard for distibuted design meetings (such as described in (Cataldo et al., 2009)) was expressed. At site B, we observed that Communicator was used heavily and valued very much by the employees; they mentioned that the phone actually was not used that often; in case of an urgent matter, the issue is put forward via email and followed up with a Communicator call to attract attention at the other development site. This links to identiﬁed differences in communication styles and preference for selecting communication infrastructure, as reported in the literature and described in §4.3.2.
Prioritize architectural rules, Write down deviations, Verify compliance – These practices are not used by Organization E. Given the philosophy of entrepreneurship and pro-activity as elaborated on in §9.2.2, Organization E does not pose restrictions such as architectural rules (see Chapter 3) to the employees. Rather, the organization promotes that employees actively request knowledge at the source (i.e., their colleagues) and correct and improve any subobtimal situation they observe along the run.
Cross-site delegation – The organization heavily relies on cross-site visits to estabish trust. Several of the key players (project managers and integration managers) at all sites involved in our study have monthly and bi-monthly visits scheduled in their agendas.
Although the interview participants mention that it is necessary to prepare the visits well (to get the most out of them), the general opinion is that the beneﬁts outweigh the drawbacks, as supported by (Sadun, 2010). As an example, an employee from site A
“And when you are in the mindset where you just say well, the Dutch people are not right then you’re not really building a good relationship. (... ) And when you really start to go there and to work with them and ﬁnd out that there are lot of people that really communicate well and you can make friends there as you can make friends here. But this can only happen if you go there. You cannot make friends by email.” Gaining trust is particularly important for employees working at site B, the site that was added most recently to the organization. The respondents indicate that cross-site visits explicitly were initiated when site B was started ﬁve years ago. Currently, however, the respondents indicate that not all employees from site B are eligable for travelling to the other sites; nor are there any regular team-building events to build trust that include employees working at site B, according to the employees working there.
Face-to-face project kick-off – Although this practice is not mentioned very frequently by the interviewees, all sites report on having a face-to-face meeting at the start of a project. Apart from that these meetings help to gain trust early in the project (and thus provide a solid basis for future cooperation across sites), employees from the Dutch site indicate that project kick-offs were conducted at site B when this site was started about ﬁve years ago.
132 9.3. Results
Urgent request – The organization promotes a low threshold for knowledge sharing and coummunication; hence, we observe that the Dutch site often poses and receives questions (either via email or Communicator-chat) that quickly need resolution. This shows that the helpfulness and willingness to share knowledge with the other sites (site A and B) is signiﬁcantly present. A shared goal exists for each of the two projects (delivering correctly functioning software in time), and an urgent request mechanism clearly contributes to that goal by minimizing knowledge sharing delays.
Collocated high-level architecture phase – The practice that promotes the development of the architecture is collocated (i.e., at a centralized location) is not that often mentioned. There is an Architecture Council where decisions that cross-cut projects and affect multiple units are taken. Decisions at the level of an individual unit are left to the unit architect – who may reside at another site –, who has regular meetings with the lead architect of the project.
Clear organization/project structure (with communication responsibilities) – The employees at site A indicate a more hierarchical project organization with clear responsibilities as compared to the Dutch site and site B. As an example, employees from site A indicate that most of the knowledge sharing occurs via (delegation to) the socalled ‘function responsible’ instead of contacting possible knowledge sources directly.
Hofstede (2001) shows that this can be attributed to a difference in the degree to which members of organization accept that power is distributed unequally; in other words, a more ‘hierarchical structure’. The organization perceives a change in the difference in
hierarchy between the site A and the Dutch site, as indicated by this example:
“Just as an example, when I talk about maybe ﬁve, 15, 20 years ago, I was [at site A] and I know people who work in a certain problem; (... ) then in a coffee break, I asked a developer about the problem, (... ) which was not very much appreciated by my colleague [at site A] (peer) (... ) This has changed I think so people are much more lets say equal and its the same ﬂat organization as it is here.” (single) repository for architecture artifacts – Architectural documents containing architectural decisions and rationale are not stored in a single repository in this organization. Our analysis reveals various examples in which e.g., employees from site B send an e-mail to ask if the information put onto the SharePoint environment is up-to-date. In addition, in the Netherlands, employees ask their colleagues via email to provide them with an architecture document.
Again, these examples show that the organization relies on the pro-activeness of its employees to initiate and promote knowledge sharing across the development sites, and rely little on codiﬁed knowledge.
Know who is who across the project – As with the other sites, it is important for the employees at site A to build a trust network with employees at the other sites. Key to building this network is to know ‘who is who’ and to know ‘who knows what’. Means to achieve this include installing a so-called directory (or ‘yellow pages’) as we have observed earlier in (Clerc et al., 2007a) and further elaborated on in (Lago et al., 2010).
1339. The Use of AKM Practices in Agile GSD
We have not observed any such implementation at this organization, yet the goal (to know ‘who is who’) is deemed important.
(single) Conﬁguration management system – No shared conﬁguration management system is in place as a knowledge base or for document storage. In the Netherlands, the employees indicate that a myriad of means exist to store information: SharePoint, wikis, a proprietary ‘document ﬁnder’ tool, network drives, and email; all are possible locations where information is stored. As a result, artifacts that should be shared (e.g., problem records, meeting minutes) are in fact not shared and employees rely on their
colleagues to ﬁnd out where a certain piece of information is stored:
“There is data management on both sides; some [documents] are shared, some not, and some are duplicated. So sometimes it is difﬁcult to ﬁnd the right information or the most recently updated documentation.” With respect to the validation of the architectural knowledge management practices for GSD, we observe that practices that are used most frequently focus on the interaction between employees (by knowing ‘who is who’), using a variety of communication means, travelling, and the possibility to quickly obtain information when needed. On the other hand, practices that focus on capturing and storing knowledge in shared, single respositories or other systems are not used heavily.
9.3.2 Additional architectural knowledge management practices While analyzing the survey results, we found practices for the management of architectural knowledge that were performed or mentioned by the organization, but that were not part of our initial model. In this section, we describe these practices.
At all sites, we found that absence of a policy for strategy for knowledge sharing was mentioned. Moreover, some respondents mentioned that more directing management statements and management support towards knowledge sharing would be beneﬁcial.
In addition, at the Dutch site several employees indicated that a cross-site architecture team (the Architecture Council) is in place, including members from site A. The organization promotes a balance in the amount of and frequency in which knowledge is shared across sites. Nevertheless, some employees indicate that there is a imbalance in that the Dutch site sometimes is dominant in e.g., taking architectural decisions and “(... ) having the ﬁnal say on quality (... )”; this imbalance causes difﬁculties in that employees at other sites feel less involved with the decisions taken. Communication occurs towards other sites, where “(... ) [we] hope that they receive it well (... )”.
These ﬁndings are supported by (O’Leary and Mortensen, 2010); the conﬁguration of the development sites and the conﬁguration at each development site individually signiﬁcantly affects the dynamics of the organization. Furthermore, an imbalance in the size of the teams at each site can even invoke competitive and coalitional characteristics (O’Leary and Mortensen, 2010).
9.3.3 Major ﬁndings In this section, we provide the major ﬁndings of our validation.
Organization E performs several activities that lead us to uncover an additional AKM practice for GSD that can be leveraged for organizations involved in GSD: ‘peered sites’. This practice covers the combination of activities that support a balance in decision-making power: establishing a cross-site architecture team, balancing the frequency of information exchange, and setting and promoting a shared goal for the project activities across development sites. In addition, it is suggested to have balanced teams in terms of number of employees working at each site.
In addition, we ﬁnd that Organization E puts great emphasis on architectural knowledge management practices for GSD that promote decentralization: all sites involved in our study interact frequently with each other without having a pre-deﬁned top-down communication structure. The key players of a site travel to other project locations to share knowledge, employees voluntarily respond to urgent requests for knowledge from their colleagues, and, ﬁnally, project kick-offs are held with members from all sites (physically) present. Practices that place a stronger emphasis on centralization, such as establishing a single repository for artifacts or having a single, shared conﬁguration management system are not used; rather, the opposite is true; knowledge and artifacts are stored in multiple locations, causing some difﬁculties to retrieve the information. Several employees denote a need for having a central repository for artifacts in general and for artifacts that contain architectural knowledge in particular.
The tendency towards decentralization has two major consequences. First, Organization E places a great emphasis on practices that support a personalization approach towards knowledge management as opposed to those that support a codiﬁcation approach towards knowledge management. This corresponds with the nature in which software development activities are undertaken at this organization: in an agile approach, the pro-activeness and entrepreneurship of individual employees promotes practices that focus on collaboration and bringing the knowledge workers together (see (Hansen et al., 1999)), rather than on codifying all knowledge in a single repository. Yet, the employees denote a clear need towards having a repository for artifacts in general and for artifacts that contain architectural knowledge in particular. The myriad of means to store and share knowledge that are in place at the organization result in that several employees do not know where (the latest version of) a document is and whether it is up-to-date or maintained. Following (Desouza and Evaristo, 2004) and (Farenhorst et al., 2007a), a more hybrid knowledge sharing approach combining codiﬁcation and personalization practices can prove beneﬁcial.