3 Essence in a Nutshell
The goal of this chapter is to present key ideas resulting in Essence as a common ground for all software development methods. Basic concepts of Essence, the notion of a method and the entire architecture of Essence is presented. Thus, the specific goals for this short chapter are for the reader to attain the ability to
It also shows that the main idea behind Essence is to focus on the most important things to think about when developing software.
As a response to “the craziest thing in the world” presented in chapter 1 and 2, Essence became a standard in 2014.
In this chapter, we will present some key ideas used as input when designing Essence. We will also separately motivate each idea and describe how it has been realized with Essence.
3.1 The Ideas
Essence relies on the following insights:
- Methods are compositions of practices:
- There are a huge number of methods (guesstimated to be >100,000) in the world, some of which are recognized and have a large user base.
- There are only a few hundred reusable practices in the world. With n practices the number of theoretically possible combinations of these practices can grow quickly very large with growing n.
- There is a common ground, or a kernel, shared between all these methods and practices.
- Focus on the essentials when providing guidelines for a method or practice.
- Provide an engaging user experience when teaching and learning methods and practices.
3.2 Methods are compositions of practices
Composition of practices is an operation merging two or more practices to form a method. The operation has to be defined mathematically in order to be unambiguous and precise. Such a composition operation has to be specified by an method expert with the objective to resolve potential overlaps and conflicts between the practices concerned, if there are any. Usually most practices can be composed easily by setting them side by side because there are no overlaps and conflicts, but in some cases, these have to be taken care of. We will later come back to compositions when we have more details about practices in our knowledge bag. If you already now want to have a peek into more on compositions take a look at part 3, chapter 19.
Resolving overlaps and conflicts means that while practices are separate, they are not independent. They are not like components which have interfaces over which communication / interoperation will happen. They also share elements, so let us briefly look at what is inside a practice. Inside a practice are for instance guidelines for activities that a user (e.g. a developer) is supposed to perform, and guidelines for work products (e.g. components) that a user is expected to produce. As two practices may share the same work product, then they contribute separate guidelines to this work product, and composing these two practices will require that you specify how the contributions must be combined in a meaningful and constructive way.
It is worth repeating that a practice is like a mini-method in that it guides a team in how to carry out one particular thing in their work. For instance, ‘requirements management’ is a potential practice dealing with what a software system should do. It is obviously not all you need to do when you develop software; you need many other such practices, for instance ‘design, implement and test’, ‘organize your team’, ‘project management’, etc. For small endeavors, it is not uncommon that you need a dozen such mini-methods/practices.
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.
As we have said a method is a composition of practices with the intention to guide the team(s) to deal with all the “things” they need to deal with when developing software, that is with all the practices they need. However, not just methods are compositions, but also practices can be compositions of smaller practices. Scrum for instance can be seen as a composition of three smaller practices: Daily Standup, Backlog-Driven Development and Retrospective. We will discuss these later when we come to Scrum in part 3 of this book. What eventually becomes a method, or a practice is just a practical decision – a method is closer to the complete guidance you need whereas a practice (composed or not) is just one aspect (of several) of what you need.
When we say that the practice guides a team, we mean it is described one way or the other to suggest 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 – Capabilities refers to people’s ability to, based on the knowledge they already have, 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.
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 miscommunication.
How these two factors interact and influence the form that your practices should take is summarized in Figure 10.
Figure 10 How explicit practices depends on capability and background
As an example, in the case where a team’s requirements challenges relate to different backgrounds and not knowing 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, contributing to the need for practices, to be considered include the size of the team and how they 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 11 illustrates Essence as a common ground providing both a language and a kernel of software engineering.
Figure 11 Essence and its parts
The Essence language is very simple, intuitive and practical as utilized in describing the Essence kernel with the elements that constitute a common ground. We will later in this part present the language.
It was left to the software engineering community to contribute practices, which can then be composed to form methods. Figure 12 describes the relationships between methods composed using practices, which are described using the Essence kernel and the Essence language. As you can see in Figure 12 the notation used in the Essence language for practices is the hexagon, and for methods it is the hexagon enclosing two minor hexagons.
Figure 12 Essence Method Architecture
The practices are essentialized, meaning they are described using Essence - the Essence kernel and the Essence language. Consequently, the methods we describe are also essentialized. In part 3 of this book you will see many examples of essentialized practices.
Essentializing means that the method/practice is described using Essence and it 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. 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 would need the guidance of several practices. Starting with the kernel a team selects 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 3 of the book we will give meaning to them. Right now, this serves just as an example of the relationship between a method and its practices.
Figure 13 A method is a composition of practices on top of the kernel.
Side Bar 6 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 practices are formed on top of the kernel is found in part 3 of this book.
3.4 Focus on the essentials
The experience is that developers rarely have the time and interest to read detailed methods or practices. Starting to learn the essentials gets teams ready to start working significantly earlier than if they first have to learn “all” there is to say about the subject.
The essentials are usually just a small fraction of what an expert knows about a subject – we suggested 5%, but with the essentials you can participate in conversations about your work without having all the details. It helps to grow T-shaped people - people who have expertise in a particular field, but also broad knowledge across other fields. Such people are what the industry needs as work becomes more multi-disciplinary. Once you have learned the essentials it is relatively straightforward to find out more by yourself from different sources.
Some teams and organizations need more than the essentials, so different level of details must be made optional.
3.5 Provide an engaging user experience
Many books have been written to teach software engineering. Some people interested in learning about ideas and trends in this space read these books, but the vast majority of software development practitioners don’t do that – not even if they have bought the books. Thus, textbooks are not the best way to teach practices to practitioners. Modern methods have taken a different approach by presenting the method as a navigable web site.
Essence has taken a different approach by providing a hands-on, tangible user experience focused on supporting software professionals as they carry out their work. For example, the kernel can be touched and used through the use of cards (see Figure 14). The cards provide concise reminders and cues for team members as they go about their daily tasks. By providing practical check lists and prompts, as opposed to conceptual discussions, the kernel becomes something the team uses on a daily basis. This is a fundamental difference to traditional approaches, which tend to over-emphasize method description as opposed to method use and tend to only be consulted by people new to the team.
Figure 14 Cards make the kernel and practices tangible
Cards have proven to be a lightweight and practical way to remember, but also to use in practice in a team. Cards make the kernel and the practices easy to digest and use. For this reason, we will throughout the book use cards to present elements in the kernel and in practices.
What should you now be able to accomplish?
After studying this chapter, you should be able to
Again, we point to additional reading, exercises and further material at www.software-engineering-essentialized.com.
Given those aims have been reached the reader is equipped with knowledge to distinguish essential i.e. the important steps / aspects / decisions from those which are of minor importance. This means that more knowledge is gained by proceeding in a given project and by working on the project with the other people/stakeholders involved.