STSCs in the Commercial Software Development Cases

Three STSCs were identified in the eMaxx Case study namely Conway’s Law STSC, Code Ownership STSC and Betweenness Centrality Match STSC. Two of these STSCs namely Conway’s Law and Betweenness Centrality were also found in the Mendix Case Study. In this section we look at the STSCs in more detail and elicit the lessons learned from them. 8.1.1 Conway’s Law STSC

The Conway’s Law STSC as well as the Betweenness Centrality Match STSC was ob- served in both the Mendix and the eMaxx case studies, while, the Code Ownership STSC was only observed in the eMaxx case. The main reason for this is that the development tool followed a design science research methodology of iterative improvement. So, at the time of the Mendix case the TESNA tool did not have the functionality of displaying the Code Ownership STSC. It is interesting to investigate the broader managerial reasons be- hind the STSCs. In order to do that, we invoke the classic typology (Thompson 1967)) and build upon by Kumar et al. (Kumar, Fenema et al. Forthcoming).

Figure 54: Integration Interdependence versus Reciprocal with Integration Interdependence causing Con- way’s Law STSC

In both the eMaxx and Mendix case studies a Conway’s Law STSC was observed among the teams working on different parts of the architecture (Front Office, BPEL and Applica- tion Server Teams in the eMaxx case). In both cases, a particular team (BPEL in eMaxx

and Workflow server team in Mendix) were situated in different rooms (also in a different floor of the building in the eMaxx case). Hence, the way the development teams were de- signed resembled the Integration Interdependence typology as seen in the left hand side of Figure 54. But in reality, the teams had reciprocal interdependence with each other owing to the messaging (XML) between the parts of the architecture they were working on. Fur- ther, the dependence was also “sticky” (von Hippel 1994) as there was a cost attached to the transfer of information especially as some teams and even team members from the same team were seated in different rooms. The resulting changes done to the different parts of the mid office application architecture, required integration in order to make sure that the different parts work together and is free of major bugs. Thus, this integration of the differ- ent changes and the resulting typology of interdependence is Reciprocal with Integration Interdependence typology as shown in the right side of Figure 54. In Figure 54, the rectan- gles represent the teams working on the different parts of the software system architecture and the arrows represent the flow of tasks. By identifying the Conway’s Law STSC over a period of time in both the Mendix and the eMaxx case studies, we have added a temporal dimension to the concept of identification of coordination problems by Malone and Crow- ston (Malone and Crowston 1994; Crowston 1997).

On having such an understanding of the interdependence typology, the Project Manager(s) can restructure the organization so that the teams are closer in terms of physical proximity. They can also use new and improved Groupware technology to increase and improve the quality of sharing knowledge virtually among team members.

8.1.2 Code Ownership STSC

To better understand the Code Ownership STSC identified in the eMaxx case we use the extension to the classical interdependence typology from Kumar et al. (Kumar, Fenema et al. Forthcoming). Ideally, the Code Ownership pattern suggests that a particular developer is assigned or takes the responsibility of a particular software module and this was what the project managers anticipated at eMaxx. This situation requires discussion to split the work, before performing and review along with integration after the changes have been made. This can be described by the ideal integration interdependence typology shown in the left hand side of Figure 55.

Figure 55:Non-Sticky Integration Interdependence versus Fully Sticky Integration Interdependence causing the Code Ownership STSC

While, as in the eMaxx case it was seen that there were more instances of collective code ownership at the level of the software application module (packages in .jar file format). Such collective code ownership requires information transfer from the previous developers (who last made the changes to the software application module) to the developers who are currently making the changes. Such information transfer occurs at the beginning of the modification (answering the query of what must be done), during the modifications (an- swering the query about how can the changes be done) and after the modifications (discuss- ing what has been done). The information transfer is also “sticky” (von Hippel 1994), as the developers did not share the same room, or could have been away for some reason. Thus the actual Interdependence typology resembles the “fully sticky” Integration Interde- pendence typology (Kumar, Fenema et al. Forthcoming).

Like in the previous Conway’s Law STSC, identifying the Code Ownership STSC over a period of time in the eMaxx case study, we have added a temporal dimension to the con- cept of identification of coordination problems by Malone and Crowston (Malone and Crowston 1994; Crowston 1997).

On identifying the Code Ownership STSC, the project manager can restructure the devel- opment process in such a way that fewer developers have the responsibility of the software package module or the project can even consider adopting an more Agile development methodology like Extreme Programming (XP) (Nordberg 2003).

8.1.3 Betweenness Centrality Match STSC

The Betweenness Centrality Match STSC was observed in the both the commercial case studies (Chapters 5 and 6). This Structure Clash is related to who is in charge of coordinat- ing the project and as a result who decides what the resulting Socio-Technical Network looks like. Due to the nature of the Structure Clash, it is not possible to represent it using

Interdependence typology. Thus, we have added another dimension to the purely task and resource concept of Coordination Problem considered by Malone and Crowston (Malone and Crowston 1994; Crowston 1997), by considering the person who is coordinating the project.

In the Mendix Case Study (Chapter 5), we saw that the CTO noticed instances where some employees were coordinating the project when someone else had the responsibility or ex- pertise. While in the eMaxx Case Study (Chapter 6), the change in the Betweenness cen- trality of employees (developers and managers) in four large projects were considered. In each of the projects Betweenness Centrality STSCs were identified based on interviews conducted with the different members of the project.

Like in the Conway’s Law STSC and Code Ownership STSC, we also observed the Be- tweenness Centrality STSC over a period of time in both the Mendix and the eMaxx case studies. We have added a temporal dimension to the concept of identification of coordina- tion problems by Malone and Crowston (Malone and Crowston 1994; Crowston 1997). In the eMaxx case we also found that when some employees or even customers found that no one was taking the responsibility of coordinating the project, took the proactive initiate to coordinate (Chapter 6). In the case of a customer taking the initiative to coordinate, we found that only those customers who had a good technical knowledge of the product as well as the process took such an initiative.

Identification of Betweenness Centrality Match STSC can help the Project Manager or Controller identify employees who are not doing the job of coordinating that they are en- trusted with, while at the same time also identifying the employees who have taken a pro- active responsibility to manage the project. The project manager can then decide if he needs to re-assign the responsibility of coordinating the project and mark the proactive em- ployee for praise.