19.)
What eventually becomes a method or a practice is just a practical decision. To reiterate, a method is closer to the complete guidance you need whereas a practice (composed or not) is just one aspect (or several) of what you need to guide the team(s) to deal with all the “things” they need to deal with when developing software. An individual can create one or a few practices based on experience, but a method is always too big to be created by one individual without “borrowing” practices from others. We say “borrowing” within quotes, because it is an act without consent of the originator. Practices are successful because of the knowledge they provide, whereas methods are usually branded (like RUP, SAFe, DAD, Nexus, Less) and success is more about great marketing than about knowledge being provided.
When we say that a practice guides a team, we mean it is described one way or another to indicate what to do. How explicit a practice should be, i.e., how detailed the descriptions should be, depends on two factors: capabilities and background.
Capability. Capability refers to team members’ ability, based upon the knowledge they already have, to figure things out for themselves. Team members with high skill and capability need only a few reminders and examples to get going. Others may need training and coaching to learn how to apply a practice effectively.
Figure 3.1 How explicit practices depend on capability and background.
Background. If the team has worked together using a practice in the past or have gone through the same training, then they have a shared background. In this case, practices can be tacit. On the other hand, if team members have been using different practices, e.g., some have been using traditional requirements specifications while others have been using user story (a more modern way of dealing with requirements), then they have different backgrounds. In this case, practices should be described to avoid miscommuni-cation.
How these two factors interact and influence the form that your practices should take is summarized in Figure 3.1.
As an example, in the case where a team’s requirements challenges relate to different backgrounds and members do not know that much about requirements collaboration techniques, the team needs explicit practices and some coaching which a more experienced team member can provide out of the box. Additional factors to be considered, contributing to the need for practices, include the size of the team and how its members are geographically distributed.
3.3 There Is a Common Ground
Using a common ground as a basis for presenting guidelines for all practices will make it easier to teach, learn, use, and modify practices and easier to compare practices described using the same common ground.
Figure 3.2 Essence and its parts.
Figure 3.3 Essence method architecture.
Figure 3.2 illustrates Essence as this common ground, providing both a language and a kernel of software engineering.
The Essence language is very simple, intuitive, and practical, as we will show later in this section.
As previously described, it was left to the software engineering community to contribute practices, which can then be composed to form methods. Figure 3.3 depicts the relationships between methods composed using practices, which are described using the Essence kernel and the Essence language. As you can see in Figure 3.3, the notation used in the Essence language for practices is the hexagon, and for methods it is the hexagon enclosing two minor hexagons.
The practices are essentialized, meaning they are described using Essence—the Essence kernel and the Essence language. Consequently, the methods we will describe are also essentialized. In Part III you will see many examples of essentialized practices.
Figure 3.4 A method is a composition of practices on top of the kernel.
Essentializing not only means that the method/practice is described using Essence; it also focuses the description of the method/practice on what is essential. It doesn’t mean changing the intent of the practice or the method. This provides significant value. We as a community can create libraries of practices coming from many different methods. Teams can mix and match practices from many methods to obtain a method they want. If you have an idea for a new practice, you can just focus on essentializing that practice and add it to a practice library for others to select; you don’t need to “reinvent the wheel” to create your own method (see, e.g., Figure 3.4. This liberates that practice from monolithic methods, and it will open up the method prisons and let companies and teams get out to an open world.
As mentioned earlier, a team usually faces a number of challenges and will need the guidance of several practices. Starting with the kernel, a team can select a number of practices and support tools to make up its way-of-working. The set of practices that they select for their way-of-working is their method.
When learning a new practice or method, perhaps about use cases, or user stories, it is sometimes difficult to see how it will fit with your current way-of-working. By basing the practices on a common ground, you can easily relate new practices to what you already have. You learn the kernel once and then you just focus on what is different with each new practice.
Even if there are many different methods (every team or at the least every organization has one), they are not as different as it may seem. Examples of common practices are user story, test-driven development (TD), and backlog driven development. These terms may not mean much to you now, but in Part III we will give meaning to them. Right now, this combination serves just as an example of the relationship between a method and its practices.
Sidebar 3.1 How Much Does a Developer Need to Know About Methods?
You may be asking yourself at this point, do I really need to care about all of this method theory? Remember, a method is a description of the team’s way of working and it provides help and guidance to the team as they perform their tasks. What the kernel does is help you structure what you do in a way that supports incremental evolution of the software system. In other words, it puts you in control of the way you work and provides the mechanism to change it.
The idea of describing practices on top of the kernel is a key theme of this book. A further discussion of how they are formed this way is found in Part III (see also Sidebar 3.1).
3.4 Focus on the Essentials
Our experience is that developers rarely have the time and interest to read detailed methods or practices. Starting to learn the essentials
