We describe here how the patterns relate to each other, forming a pattern language, where patterns precede and succeed other patterns.
5.4.1 Mentoring pattern relation
When a newcomer joins, one can either use Pioneer Onboarding, if the team mainly con-sists of pioneers. Over time, the team has a mix developers with Pioneer Identity and Early Onboarder Identity. At this stage when a developer with newcomer identity joins the team, the Generational Onboarding pattern can be used to sustain the community most effectively.
In terms of Buell’s mentoring models, we observe that all developers at TAI, given the opportunity to mentor, choose the “Nurturing Model” [13] where they create an environ-ment conducive to asking questions and learning through encourageenviron-ment, as opposed to the “Cloning Model” of mentoring where mentors typically expect their mentees to learn by replicating what the mentors are doing.
We also observe that the same mentor may use different mentoring patterns in different scenarios. Alex employs the Mentor as Interrogator pattern when reviewing or critiquing code, where he asks questions to drive the mentees to examine their work more carefully or consider all scenarios, and he employs the Mentor as Oracle pattern when working
Figure 5.1: Mentoring pattern relation
alongside less experienced developers, where they ask Alex different questions and he uses their questions as a guide for what to explain and elaborate on.
In our limited experience with Leon, we found that in critique and review, he employed the Mentor as Interlocutorpattern. Figure 5.1 on page 134 depicts this pattern relationship.
5.4.2 Knowledge sharing pattern relation
It benefits the larger community when the development team work together to becoming a community of experts. However, it isn’t always possible to only have experts, especially for growing teams. Even expert programmers may have lots to learn about the specific product or design they work on. In such a community, it becomes necessary to have mechanisms in place to share knowledge, to accommodate everyone’s journey towards becoming an expert.
Organizational patterns suggest an Apprenticeship pattern approach to move away from the Old People Everywhere pattern and encourage more communication and knowledge sharing between more experienced developers and less experienced developers to help less experienced developers gain the knowledge that they lack. This can eventually support a Domain Expertise in Roles model where the community makes or hires domain experts and then structures then structures teams around them to implement a Subsystem by Skill pattern approach.
134
We find that as Pioneers don’t know what all they know, a good approach towards knowl-edge sharing is in utilizing the Apprenticeship pattern approach, which facilitates experts or Pioneer Identity developers to communicate documented and undocumented knowledge in conversation and Communicate design rationale with the less experienced generation of developers, through Generational Onboarding to prevent the Old People Everywhere pattern environment.
5.4.3 Process evolution pattern relation
When we see instances of process or means of working together and communicating chang-ing at the software development community of practice at TAI, we observe the relationship of the new process related patterns we found at TAI and the existing organizational patterns that were practiced there.
To encourage pair programming in the development team, a means to allow the organic adoption of the process is described in the Encourage pair programming by doing it pattern where once a few developers start to adopt pair programming, subsequently who they work with are also likely to adopt the process. We witness that the existing pattern of Self-Selecting Team [22] facilitates the existing Develop in Pairs pattern allowing developers who want to work together to do so and not forcing incompatible pairings. Greater adoption of pairing also helps ensure the Someone always makes progress pattern, where successful pairings are more efficient and likely to make progress than individual work.
A process is more likely to be practiced and benefit the community when the developers who practice it, internalize the behavior and see immediate benefit in doing so. Creating a community where the Developer Controls Process pattern is effective, with support from the Patron Role, helps foster an environment where developers choose and adopt practices that they assess as working for them after they have tried it. We witness such a community in TAI, where the Patron Role supports and encourages the developers to decide and use the practices that work for them, by encouraging them to try new things, but not enforcing behavior.
Even when we see a Process Tug of war pattern, where the developers have a difference of opinion on adherence to prescribed process, the Patron Role encourages the team to determine what would work for them through dialogue and discourse.
Figure 5.2: Shape of Sprints pattern relation
5.4.4 Shape of sprints pattern relation
It can take a few sprints for a mix of diverse developers to find their work rhythm and determine what practices work best for them. This distinction in needs and expectations from a sprint can influence the ‘shape’ of the communication in the sprint. As depicted in figure 5.2 on page 136, the team can start with an Initial Turbulence Sprint pattern, char-acterized by bursts of energy and intense communication, where the nature of the work and communication is discussed, experimented with, sometimes at the expense of the ex-pected progress, following the patterns of Developer controls process and Self-Selecting Team. Taking advantage of a first sprint where the team decides how it works best can be followed by a Path to normalcy pattern where the team finishes up rolled over work and continues practicing good practices of collaboration. This can be followed by a BAU sprint pattern where the pace of work drops off as a lot of decision making and communication fine tuning occurred in prior sprints.
The Yesterday’s Weather pattern [20] discusses how the velocity of one sprint can affect the velocity of the next sprint, although it is also a good predictor of the next sprint’s velocity.