The second principle is relevant for empowering project teams:
|Starting with project inception, adopt a coherent Pattern Palette by beginning with a proven pattern language. Continue to mature your team palette throughout the project life cycle.|
Based on experience with “the Company,” we submit that successful “Pattern Palette adoption” is: based on coherent patterns from a proven pattern language, aligned with application architecture, a conversation best started during project inception, and usually not “frozen” after initial codification.
Coherence is a necessary condition for a set of patterns to be considered a Pattern Language, that is, patterns that “work together to solve problems.” (Manns and Rising 2005, 14) A judiciously adopted Pattern Palette can inherit the coherence of its parent collection, and thus become a “dialect” of the original language. Additionally, the pattern language should be “proven”— it has been previously used with success to deliver similar (business) solutions in equivalent (technical) contexts.
Some patterns carry architectural implications, while others do not. For example, a Business Facade class contains reusable logic that belongs within the business layer, whereas a Helper class could “reside” within any layer in the code base. Therefore, a team Pattern Palette is established in concert with the application architecture. Vetted patterns (or preferably a vetted pattern language) nudge a team towards application architecture durability while stimulating design inspiration. A suitable Pattern Palette incorporates “just enough” (and no more) up-front architecture as a foundation for long-term adaptability, and demonstrates “just enough” (and no more) richness and variety to kindle design insight.
Pattern adoption is a team design exercise that begins the process of aligning divergent technical perspectives. There is no need to wait for key stakeholders’ to fully articulate their complete set of project requirements. Technical alignment is particularly important for newly constituted teams during their “norming” phase.
We have observed project teams benefiting from face-to-face conversations when beginning with patterns from the PED Unified Pattern Language Collections, while enriching their palette from other sources. We concur enthusiastically with the sixth principle of the Agile Manifesto: “the most efficient and effective method of conveying information to and within a development team is face-to-face conversation.” A mature self-organizing team will leverage its collective wisdom by seeking opportunities to maximize the amount of work not done; collaborative adoption of patterns that guide effective development realizes one such opportunity.
Consider acknowledging a team champion to promote pattern adoption.
The roles of a pattern champion may include:
- Suggesting a viable initial palette
- Responding with palette adjustments for team consideration as business requirements emerge
- Making the pattern adoption process “big and visible”
- Ensuring that the pattern selection conversation within the team begins early
- Facilitating the revisiting of assumptions as circumstances warrant
- Focusing the team on closing emergent gaps between the Pattern Palette and the code base
- Leading a team towards discussions concerning the positive and negative consequences of implementation choices among design alternatives
We refer to patterns that the team has agreed to use as “on-palette,” whereas other patterns that are reflected in the code are labeled as “off-palette.” There is a natural tendency for the Pattern Palette and the code base to diverge over iterations, giving rise to two risks worth noting.
First, a team member may feel compelled to code to an on-palette pattern when an off-palette alternative is a better fit for their user story. The pattern champion helps the team recognize that, at times, an “off-palette” approach is appropriate. For example, if using an on-palette pattern would constitute its misuse, the champion may encourage an off-palette alternative.
Secondly, a team member could write code that incorporates an off-palette pattern, which is unknowingly picked up by other team members. This reuse of an off-palette pattern is presumably a good reason for including the pattern on the Pattern Palette. Should such circumstances materialize, the pattern champion facilitates a discussion about whether the pattern warrants promotion to the
Pattern Palette, or remains a valid, albeit off-palette, alternative.
 In 2002, Java was adopted as the standard platform for in-house development at a successful large automotive manufacturing enterprise (“the Company”).
 The metaphor of a Pattern Palette suggests an artist’s palette, and implies an adaptive, non-prescriptive adoption of patterns from one or more pattern collections, for use on a project.
 We are not arguing for the PED collections, uniquely. Our bias is, of course, that PED be consulted as a starting point, but the inclusion of other patterns may provide additional inspiration for a team adopting its own Pattern Palette.
Manns, M. L. and L. Rising. 2005. Fearless Change: Patterns for Introducing New Ideas. Addison-Wesley