20 Essentializing Practices
The goal of this chapter is to introduce the reader to how we arrive at practices referenced in this book. Specifically, in this chapter the reader will be shown
- the ways practices are identified and essentialized;
- the important role of having practices described using a unified language, which Essence provides;
- how the explicit state within an alpha naturally provides the teams with a view of the whole process and keeps energy focused on full completion; and
- the concept of practice architecture as a layered composition of practices (with more generic practices at the bottom and more specialized practices at the top).
The first dimension of scaling, as presented in Chapter 19, is about zooming in on details and providing the necessary explicit guidance to practitioners. Back in Part III, we demonstrated how teams in TravelEssence took reusable practices and adapted and applied them to the specific situation they faced in their own endeavor. These practices were presented in their essential form, in terms of alphas, work products, and activities (i.e., using the Essence language to facilitate the understanding and use of the practices by the team). So, where do these practices come from, and how do these practices end up in this essentialized form? Moreover, how do we arrive at the practices like the ones we illustrated in Part III? We answer these questions in this chapter.
After studying this chapter, you should be able to
- list and explain the sources from which practices might emerge;
- explain why organizations typically define their own practices;
- explain the term “monolithic method,” providing some examples;
- give examples of different terms that are used in software engineering to denote the same thing, and explain why that is problematic;
- explain the term “alpha state progression” together with an example;
- give an example of a practice architecture; and
- describe the difference between development practices and program practices.