Changes in participation over time

As we see in Figure 4.12 on 103, our participant observer Natalie, was working on the maintenance team and this phase also included her onboarding time. Initially, Natalie and Nathan worked with Davin, and through the rest of time on the maintenance team, she primarily worked with Nathan, the other newcomer. Natalie would occasionally consult with other pioneers or early onboarders on different bugs, but the bulk of their programming was done either alone or in paired programming sessions together. Natalie would also be reporting to Philip during the daily stand up meetings. The work on each bug would last anywhere between one to three days. As the maintenance team was also responsible for ensuring the daily builds do not have problems, Natalie would often work with Moss, the infrastructure personnel to remedy any software build related issues. As the figure suggests, Natalie’s interaction was primarily with Nathan and Philip with several consults with pioneers like Alex or early onboarders like Davin or Ivan.

After a long stint on the maintenance team, Natalie and Nathan moved to the Pre-release team, where they were joined by pioneers like Alex and Quinn and early onboarders like Karoline, Ivan and Calvin and the third newcomer, Casey. As we see in Figure 4.13 on page 104, Natalie worked primarily with Alex and Karoline on different long running bugs together and on some short running bugs by herself. As we see in the time line for the first three weeks of the pre-release work in Figure 4.9 on page 100, Natalie worked on some bugs that ran as long as medium sized user stories did. During the pre-release work, the team met daily with Steve, who was the Scrum Master and with Douglas who was the Product Owner and the customer proxy on many stories. As many of the bugs that Natalie worked on had to do with infrastructure changes, she also extensively consulted with Moss on infrastructure matters.

When the product major version release finally took place, the teams were reconfigured again to form scrum teams. We observe who Natalie interacted with during the first sprint in Figure 4.14 on page 105. All her programming interaction was with Alex and Karoline, and during the sprint, Alex, Karoline and Natalie worked on two long running stories.

There was daily interaction with Steve, Douglas and the rest of team during the stand up meeting and the demo prep before the end of the sprint. The second story, which was developed by Natalie and Karoline was almost complete and even given approval by the customer after demo, but was rolled over into the second sprint was the final code commit.

This affected how the second sprint was shaped.

We see in Figure 4.15 on page 106 which describes who Natalie communicated with during sprint two, that her interaction was heavily with Calvin. Karoline and the customer proxy for the rolled over story were on leave for the beginning of the second sprint, so Calvin took

Karoline’s place on the story and a new customer proxy was appointed. During the demo, the new customer described additional scenarios for the functionality to work, that the first customer had not mentioned. This expanded the scope of the story. So Natalie spent some time with Calvin, bringing him up to speed on the story. As the base functionality was now working, extensive testing could be performed. Natalie then worked with Jenna, who was a new tester working with the team. As Jenna was also relatively new to the system, Natalie spent some time helping Jenna get accustomed to the new functionality and helped with setting up tests for it. Then Karoline, Leon and Natalie worked on a long story, where as the pioneer and expert in the functionality being changed in the story, Leon led the design effort on the story. Karoline and Natalie worked on different parts of the story individually, as dictated by Leon. This changed feature also required extensive testing, leading Natalie to work with Jenna some more. As with the first sprint, the development team met with Steve and Douglas daily for stand up meetings and towards the end of the sprint for demo planning and preparation.

Figure 4.16 on 107 depicts Natalie’s communication and interaction during sprint three.

We observe that Natalie’s interaction during this sprint was a lot less intense than prior sprints. As the stories during this sprint were related to stories already completed in prior sprints, the work in this sprint was largely performed in solo programming sessions with brief communication bursts to reconfirm and tweak design decisions that were established before. At this point, all the developers on the stories knew what they had to do, and the development effort was smooth, requiring limited interaction. Natalie pair programmed with Casey for a short time.

98

Figure4.8:Sprint1Timeline.

Figure4.9:Pre-releaseWeeks1-3Timeline.

100

Figure4.10:Fruchterman-Reingoldwithgroupingsforallinteractionat TAI.

Figure4.11:Fruchterman-Reingoldwithgroupingsforallinteractionat TAI.

102

Figure4.12:Fruchterman-ReingoldwithgroupingsforalltheMaintenance team.

Figure4.13:Fruchterman-ReingoldwithgroupingsforallthePre-release team.

104

Figure4.14:Fruchterman-Reingoldwithgroupingsforallthefirstsprint cycle.

Figure4.15:Fruchterman-Reingoldwithgroupingsforallthesecondsprint cycle.

106

Figure4.16:Fruchterman-Reingoldwithgroupingsforallthethirdsprint cycle.

Figure4.17:Perbugprocessfilteredtoa50%activitiesand50%ofpaths forMaintenanceTeamwork,outputfromprocessminingtoolDisco

108

Figure4.18:Perbugprocessfilteredtoa50%activitiesand50%ofpaths forPrereleaseTeamwork,outputfromprocessminingtoolDisco

Figure4.19:Perbugprocessfilteredtoa50%activitiesand0%ofpaths forMaintenancework,outputfromprocessminingtoolDisco

110

Figure4.20:Perdayprocessfilteredtoa80%activitiesand50%ofpaths forPrereleasework,outputfromprocessminingtoolDisco

Chapter 5 TAI - Results

From our study of TAI, we used qualitative data from the developers interviews and the observations and reflections of the participant observer to form more in depth observations and uncover the story, patterns and the social, historical and cultural context. We then used the quantitative data to validate and ratify some of our observations.

The greater purpose of our study was to capture patterns of communication related to men-toring and knowledge and process management that allow software development commu-nities of practice to evolve their practices, sustaining themselves through change. In a true grounded theory sense, part of the job was to ask the question: ‘what are the ques-tions?’ The search for patterns is in fact also the search for the questions. Our study of the software development community of practice has a broad focus and research questions.

Broader studies help capture different aspects of the subjects, while allowing researchers to see many facets at play together to assess what the important and unique aspects of the sub-jects and their relationships are. A purpose of our study was to identify potential questions for future research.

In this chapter, we discuss some of our findings based on our mix of quantitative and qualitative analysis and present the results of our findings in the form of patterns.

5.1 Discussion

In this section, we discuss some of our observations from the mix of quantitative and qual-itative data, but with more context than observations in the previous chapter. Some of these

112

discussions will allow us to identify and frame our findings as patterns in later sections.