19 Putting the Practices Together: Composition

In this part of the book we have motivated the need for explicit practices and discussed how explicit practices described on top of Essence are used by small development teams to help solve common challenges teams often face. We provided in this part just a few examples of the kinds of practices that teams can use explicitly. Our purpose is to show you how to go about representing practices using the Essence language so you can do comparisons yourself and make the best decisions on which practices are best for your team given your own endeavor situation. We used examples such as Scrum, User Stories, Use Cases and Microservices. To demonstrate the use of the Essence language, we only essentialized what we deem as the real core of these practices. This is why we referred to the practices we described with the “Lite” adjective. It is also not our intent in any part of this book to present arguments for or against any particular practice, nor to present arguments as to why one practice may be better than another. Moreover, it is not our position to show that these lite practices are everything you need to know about them. Rather, we focused only on the absolute core. The core will act as the solid foundation to learn and master more about these practices.

When adopting practices, teams do not need to adopt all practices at the same time. Instead they do so one at a time. In fact, this was how Smith’s team learned and grew. They started with the kernel. Then they added Scrum Lite to improve their collaboration. They tried User Story Lite, but decided to go for Use Case Lite because it gave them a better requirements structure. They then chose Microservice Lite to help make their software system rapidly deployable. Each time they added a practice, they received explicit know-how. Their knowledge about software engineering grew. 

Although teams adopt one new practice at a time, in reality they apply several practices at the same time.. In short, teams apply a composition of practices. In this chapter, we will explain what composition is and how essentialized practices facilitate the composition process, and thereby help teams to learn and apply practices better.

19.1 What is composition

As mentioned in part 1, composition of practices is an operation merging two or more practices to form a method. The composition operation has been defined mathematically in Essence to achieve precision. The precision is achieved through the essentialization of practices, i.e. describing practices using alphas, work products, activity spaces, activities, competencies and patterns as you have observed in earlier chapters.

The merging operation can be understood intuitively like overlaying overhead projector transparencies on top of one another to form a new image as shown in Figure 144. In the case of Figure 144, we have a set of Christmas decoration transparencies. These transparencies comprise the following images:

  1. An empty corner of a room
  2. An undecorated Christmas tree
  3. A Christmas star
  4. Streamers
  5. Decorative balls
  6. Three presents

Figure 144     A set of transparency overlays.

If you overlay the above transparencies in sequence, one on top of the other, you will gradually form the following pictures in sequence (see Figure 145). This is probably what you expected.

Figure 145     Composition as overlaying the transparencies in sequence.

Consider what would happen if you replace transparency (c) and (e) with transparencies (c2) and (e2) shown below. What would happen if you overlay or compose them in sequence?

Figure 146     A different set of transparencies.

If you do the composition, you find the Christmas star on the floor and the decorative balls become red instead of yellow. Herein lies some important concepts behind valid composition:

Although the transparencies are physically separate, they are drawn such that the coordinates must match, otherwise you would have the situation where the Christmas star appears on the floor. The Christmas tree anchors the position of all other images. The corollary is that while practices are separate, they are not independent. They are dependent on the namespace (e.g. kernel alphas and activity spaces) by which they are composed. The Essence kernel defines such a namespace. It acts as the unifying anchor.

As long as the namespace is adhered to, practices for the same purpose can substitute one for another. In the example above, we can swap the transparency (c) with (c2) and get red balls instead of yellow balls as Christmas decorations. Theoretically, you can substitute one sub-alpha with another, for example, substituting the ser Story alpha with the Use Case alpha under the Requirements alpha. In this case, the Requirements alpha acts as an anchor. However, when you replace an alpha, you will likely need to replace activities as well. So, in general the substitution happens by replacing practices. In Smith’s story, you see his team replace the User Story practice with the Use Case practice. We say that the User Story practice and the Use Case practice are alternative practices.  With alternative practices you can usually replace one with the other.

There is another kind of practice, which we refer to as an “extension” practice. For example, Smith found that there was value in having greater stakeholder participation in their Sprint Review activity to help gather better feedback. Initially, the team only had the Product Owner present, but in some cases Smith decided more people should be involved. For this reason, Smith created a “Stakeholder Sprint Review” practice that provides further guidelines to conduct this review. This includes additional activities to prepare the stakeholders for the review, preparing the team for the review and acting on review feedback. It is more than just adding simple guidelines to the one single Sprint Review activity in that it includes many new activities as mentioned. These activities progress the Stakeholder alpha, as well as the Sprint alpha. It does not however add any alphas. This “Stakeholder Sprint Review” is an example of an extension practice to the Scrum Lite practice. 

Alternative practices and extension practices are but just two of the many kinds of practices you can overlay on top of the kernel. In fact, there are many kinds and combinations which we will not discuss in this book. Regardless, all practices must conform to the namespace structure of the kernel including the practices that have already been composed.

Just as you can overlay multiple transparencies in sequence to form a final image, you can compose multiple practices in sequence to form a final method. When composing two practices together, we compose their things to work with, their things to do, competencies and patterns separately. The composition of things to do best illustrates the composition operation. Activity spaces (see Figure 147) provide a useful visualization tool with regards to how the two practices being composed help Smith’s team and where potential gaps may occur in the future. The figure shows all activity spaces in the kernel, and the activities that cover them. Note that, Figure 147 only comprises activities from Scrum Lite, Use Case Lite and Microservice Lite.  Smith had eventually moved from user stories to use cases.

Figure 147     Activity spaces populated with activities from Smith’s practices

It is quite clear that a number of activity spaces are not populated, in particular all activity spaces in the customer area of concerns. Not all activity spaces in the solution and endeavor activity spaces are covered. At this point in time, Smith’s team was shielded from these challenges because Angela the Product Owner had been dealing with the opportunity and external stakeholder aspects, and Smith’s team was focusing on internal stakeholders In subsequent releases, when Smith’s team needs to deal with larger user groups, they would need practices to fill the gap (i.e. the gaps in the Deploy the System and Operate the System activity spaces). Examples of such practices include Continuous Integration, Continuous Delivery, and so on, which we will not go into any further detail.

The composition of things to work with is a little more complicated. The complication lies in the relationships between alphas. Figure 148 shows the composition of the alphas from the Scrum Lite, Use Case Lite, and Microservice practices. The kernel alphas Work, Requirements and Software System provides the top-level structure under which sub-alphas are group. The composition operation is like hanging decorations on a Christmas tree. The kernel acts like the Christmas tree by which you hang the decorations, which in this case are the sub-alphas Sprint, Use case and Microservice respectively.

Figure 148     Composition of alphas in Smith’s Endeavor

There is additional work to relate sub-alphas from one practice with sub-alphas from another practice. For example, there is a relationship between Microservice and Use Case. The realization of a use case may cut across several sprints; each sprint implements some use case slices; a use case or a use-case slice may be realized by more than one microservice. The composed set of alphas give a simple map of all the critical things that Smith’s team must keep track of. It is also a map of checklists for the team.

In terms of progress and health, Smith relied on ensuring his team members know all the alphas, their states and their checklists. Smith was happy that these alphas had entered their daily conversational vocabulary. For example, during their sprint planning and daily standups, team members would say that they have moved a particular use-case slice to say the “Implemented” state and everyone would understand what was meant. When someone wasn’t that sure, he/she could easily refer to the state cards.

When Smith’s team was first adopting the practices, team members had to learn about how to conduct activities and the work products to produce. However, gradually as they got more familiar with the practices, what the team members still relied on were the alphas and their checklists. They were gentle self-reminders as the team progressed through each state.

19.2 Reflecting on the Use of Essentialized Practices   

As we have shown from the preceding chapters, Essence helps teams apply practices more effectively in multiple ways.  First practices described on top of Essence gives practical guidance visible to development teams. Second, essentialization help teams translate agreed to principles into practices. Third, essentialization supports regular team feedback and adaptation through its simple graphical language. Fourth, practices described on top of Essence keeps the relationship to kernel alphas and states visible across all essential dimensions of software engineering including Opportunity, Stakeholders, Requirements, Software System, Team, Work, and Way of Working. This helps teams stay focused on the most important things as they go about their job making daily decisions. This is because the essentialized practices have been organized and streamlined through the use of the kernel.  Fifth, the kernel serves as a reminder, and substitute for practices that may fall outside the current scope of interest. For example, a team applying the Microservice practice may focus only on the Software System alpha and may become blind towards other important software engineering dimensions such as Stakeholders and Team. So, even though practices provide more direct guidance for the teams, it is always useful to refer back to the kernel to evaluate the overall progress and health, such as we saw with the Radar diagram in part 2. In this sense, the Essence kernel serves as a practice agnostic lens that the team uses to continually be mindful of the progress and health of their overall endeavor.  As an example, the alpha state checklists provide practice agnostic reminders of necessary outcomes to keep an endeavor healthy such as the need to keep stakeholders involved and the need to listen to their feedback.

Overall, one of the goals of Essence is to enable team members to become masters of their craft practice-by-practice as they learn more and more By explicitly essentializing practices, novice practitioners have a guided on-boarding path supporting their growth as professional software practitioners.

Now that you know what a practice comprises, you will know what to look for when being introduced to a practice new to you. As an example, assume you are introduced to a new practice named Behavior Driven Development (BDD), which we will not explain. By now, you know that a practice addresses a specific challenge in software engineering. You also know that a practice comprises alphas (and their states), work products (and their level of details), activities and patterns. Thus, when trying to learn about BDD, you will be thinking about these same factors. Once you understand the elements of the practice, you can understand how it fits and contributes to your software engineering endeavor. It is from this discovery that you will get a sound understanding of the practice and thereby achieve mastery.

There are certainly many more practices than what we have touched upon in this part.  In your software engineering career, you will encounter many practices, some which haven’t been invented yet.  After all, software engineering is knowledge centric and mastery is really about being able to apply appropriate practices effectively, and discovering improvements as you apply them leading to continual adaptation to the needs of your own environment.  Essence helps teams achieve this mastery by providing a common ground reference for teams to use as they continually reflect on their way of working and improve. In part 4 of the book, you will learn how practices help large teams collaborate better and how they help them work with a much larger set of practices.

19.3 Powering Practices through Essentialization

The value of Essence to teams are twofold: serving as a lens from which they can evaluate the progress and health of their software engineering endeavor, and making practices explicit through essentialization. We have seen the latter in action in part 2, when the team did not use any practices explicitly, but found guidance through the kernel. The kernel alphas help the team determine its overall progress and health. When teams apply practices through the lens of Essence, both the strengths and weaknesses of their approach become more visible to the entire team.  This is unlike how the term “practices” has been used in general. Rather than a vague concept, Essence make practices concrete and actionable by calling out the alphas and work products. For example, the essentialized Scrum Lite practice identifies alphas such as Sprint and Product Backlog Item and work products like Product Backlog, Sprint Backlog, and Increment. These come with alpha state checklists and level of detail checklists that can help team members clarify the definition of done at an appropriate level of detail. These checklists are above and beyond the checklists provided by the standard Scrum literature. These checklists are also above and beyond the kernel as they are specific to a particular practice. Moreover, we have seen in this part of the book how the Scrum Lite practice, User Story Lite practice, Use Case Lite practice and Microservice Lite practice can be defined explicitly on top of Essence to give greater guidance to Smith’s team and to help the team see where they still may have weaknesses and need of improvement.

The explicit structure of each practice supported by the use of the Essence language provides the skeleton by which additional team members can contribute their experiences. For example, they can update the checklists in the cards, add other hints and tips to any practice elements.  This, of course, depends to a large degree on the policies and constraints within each organization.  However, the Essence language has been intentionally developed with the goal of being easily used by practitioners, and not just method development professionals.  By reusing a consistent and widely accepted structure as we now have with the Essence kernel language, it makes it easier for team members to evolve and share their knowledge with other team members as well as other teams, which we will elaborate more in the next part of the book.

 

Recommended additional reading

This part of the book introduces a number of practices in a lite manner. To understand more of these practices, we recommend that you refer to more authoritative sources.

  1. Sutherland, Jeff, Schwaber, Ken. "The Scrum Guide. The Definitive Guide to Scrum: The Rules of the Game.” Scrum.org. 2016. This is the latest version of the Scrum Guide (at the time of the initial publication of this book) and should be read by anyone interested in learning more specific details on the “official” rules of Scrum.
  2. Derby, Ester, Larsen, Diana. “Agile Retrospectives: Making Good Teams Great,” The Pragmatic Programmer, 2006
  3. Beck, Kent. “Extreme Programming Explained: Embrace Change, Addison-Wesley, 2000. This book should be read by those interested in learning more about Extreme Programming. 
  4. Cohn, Mike. “User stories applied: For agile software development.” Addison-Wesley Professional. 2004.  This book should be read by those interested in learning more about the User story practice.
  5. Bittner, Kurt, Spence, Ian. “Use Case Modeling”. Addison-Wesley Professional, 2003. This book provides a comprehensive treatment of Use Case Modeling. Though the book was written before agile became the trend, it is still a valuable treatment of the subject.
  6. Booch, Grady, Rumbaugh, James, Jacobson, Ivar, “The Unified Modeling Language User Guide (Second Edition), Addison-Wesley, 2005. This book should be read by anyone interested in learning more about the Unified Modeling Language.
  7. Jacobson, Ivar, Spence, Ian, Bittner, Kurt, “Use Case 2.0: The Guide to Succeeding with Use Cases, December, 2011, https://www.ivarjacobson.com/publications/white-papers/use-case-ebook. This ebook provides detailed guidance in applying Use Case 2.0 and should be read by anyone interested in learning more about Use Case 2.0.
  8. Jacobson, Ivar, Spence, Ian, Kerr, Brian. "Use-Case 2.0." Communications of the ACM 59, no. 5, 61-69. 2016.  This article is recommended for those interested in learning more about Use-case 2.0, and comparison of user story and use-case practices.
Newman, Sam. “Building microservices". O'Reilly Media, Inc. 2015.  This book should be read by anyone interested in gaining a more in depth understanding of the microservices practice.