23 Reaching Out to Different Kinds of Development

There is no one-size-fits-all. In a large organization it is common to see different types of development cases.  For example, new development, legacy migration, business process re-engineering, exploratory development, enhancements to the core, mobile development, and the list goes on. Will a single method work for all these development cases? Definitely not! Will an agreed set of practices work for an organization forever? Definitely not! The industry evolves and new knowledge and technologies emerge daily.  We do not live in a static world, but a very dynamic one.

Our goal has been to make the life of practitioners easier so that discussions about methods and practices become second nature, something that they do not need to worry about and spend too much time considering. We want them to focus on doing what they are best at doing to produce high quality software.

23.1 From A Practice Architecture to a Method Architecture

Let’s do a recap. So far in this book, we have introduced two different development scenarios: a small-scale development led by Smith, and a large-scale development led by Jones. Each applies a different method as we have seen previously. Instead of having each program and team identify practices, which they need, it is often times useful to provide pre-composed methods, as shown in Figure 161. This implies the need for a method architecture.

Figure 161 shows TravelEssence’s method architecture. It is very similar to the practice architecture shown earlier in Figure 151, with the addition of a pre-composed method layer at the top. Each method in the method layer is a composition of a set of practices to fulfill a specific purpose. For brevity, we only show two, one for small-scale development exemplified in part 2 and 3, and one for large-scale development exemplified in chapter 22.

Figure 161     Method Architecture with Practice Architecture and Pre-composed Methods

Having the method and practice architecture made explicit is not all there is to software engineering, albeit an important step. It is also important, in fact a lot more important, that members of an organization actually know how to find and apply the practices in a deliberate and disciplined manner.

Jones recognized that in addition to capturing practices, the practices must be made available to team members. Practice guidelines should not be on the shelves collecting dust or hidden in some folder that nobody accesses. Consequently, Jones with the assistance from Smith wrote a practice to help team members adopt and evolve practices (see Figure 162).

Figure 162     Practice to Adopt and Evolve Practices

As shown in Figure 162, TravelEssence’s (the organization’s) Way of Working was described by a Practice Architecture. An example of a Practice Architecture is shown earlier in Figure 161. Each team’s Way of Working comprises a set of Practices which the team chose to adopt. Each practice has a practice description. Throughout part 3, and part 4 of this book, we have provided a number of such practice descriptions. Essence provides a language and notation to describe these practices in a composable and actionable way.

The adoption of each practice takes time as team members learn. Jones used a Practice Adoption Progress work product to track how well a team adopted a practice and the lessons learn. Smith played the role of a Practice Coach to facilitate this process. As a Practice Coach, Smith helped teams select practices to adopt and instil a continuous improvement cycle to continually evolve their way of working by performing activities such as Coach Practice and Evolve Practice.

23.2 Establishing a Practice Library within an Organization

In practice, an organization will need to set up a practice library whereby practices can be added, and adapted and evolved to meet many different kinds of endeavors.  Such an organization is constantly renewing its way of working and its practice library. Figure 163  provides a simplified view of such an organization.

Figure 163     An Organization with a Practice Library at its center

The practice library is made available to programs and teams. The coaching network is a pool of coaches to help programs and teams select and apply practices effectively. Programs and teams will, while using the practices, likely improvise and adapt the practices to meet challenges in their specific contexts. Coaches will then bring these experiences to discussions and agreements to improve and update the practices in the practice library. This completes the continuous cycle in such a learning organization.

To allow teams to easily select the practices they need, organizations need to provide a practice library.  This is done by first essentializing practice candidates for the practice library. Once a practice library has been created teams can assemble practices found in the library into useable methods. 

Anyone can essentialize a practice but the best result is obviously achieved if an experienced developer does it and in particular someone experienced in the specific practice concerned.  Once an organization has essentialized their practices they will need to be maintained and improved. Improving essentialized practices can be done by anyone in the organization. Since a changed practice may only be used in some teams and the original practice may still be used by other teams, an organization needs to keep track of different versions of practices and which version has been used on which endeavor.  

First, one must realize that the objective of essentialization is to help an organization learn. Second, there is a cost associated with essentialization decisions such as deciding on alphas versus work products, and deciding on exactly what should be an explicit practice versus a pattern or a resource, or just a principle, such as simple design. In some organizations games or “mini-practices” are treated as resources that provide references to previously published books on these subjects.  Other organizations may decide there is value in describing these smaller practices more explicitly to aid their less experienced practitioners.  Third, the level of detail for each practice has to be worked out:

  1. Identifying alphas, states, work products, checklists, and activities in practices.
  2. Providing supporting material to supplement the practices, such as providing references to previously published books on these subjects. 

The greater the level of detail, the more effort is required. An organization that is growing with many new hires would probably need well-written practices. This organization could essentialize their own practices, or they could draw from the growing community of practice authors around the world. This book itself represents the authors’ contribution of practices to the community (e.g. Use Case Lite and Microservice Lite as we have discussed in this book). We encourage experts in the industry to essentialize more practices. As students, when you learn something new in software engineering and technologies, we encourage you to essentialize them as a way to summarize and capture your understanding of these practices.