the right things done.
4.4.3 Way of Working
A team can perform their work in different ways and this may lead to different results. It can be performed in an ad hoc manner, meaning that you decide how to work while doing the work. For instance, while cooking a soup, you may not follow a recipe—you might decide on the fly which ingredients to use and in what order to mix and cook them together. When following an ad hoc way of working, the result may or may not be of high quality. This depends on many factors: among them, the skill of the people involved and the number of people involved in the process.
All of us are acquainted with the saying “too many cooks spoil the broth.” If too many cooks cook the soup in an ad hoc manner, the soup won’t taste good. Translating the analogy to software, if too many people participate in agreeing on how to do the job, the job will probably not be done well. There are many reasons for this. One of them is that each person has his/her own idea of how to conduct the job and, often, they do not work in an orchestrated manner.
Smith’s team addressed this issue by regularly looking at their prioritized backlog. They made sure that they correctly understood the scope of each item in the backlog, checking with stakeholders and getting feedback from them. Smith’s team regularly examined their method or, in other words, their way of working. If things did not seem right, they made changes.
It is therefore important for team members to come into some kind of consensus regarding their way of working. Disagreements about the way of working are significant barriers to team performance. You would think that coming to an agreement would be easy. The truth of the matter is that it is not. On a small scale, within a single team, there is still a need for members to agree on the foundations and principles, followed by specific practices and tools. This would of course need to be adapted to the team’s context, and evolve as the environment and needs change.
The way of working must:
• include a foundation of key practices and tools;
• be used by all the team members; and
• be improved by the team when needed.
In an industry scale, one of the things we hope to achieve through Essence is to simplify the process of reaching a common agreement. We do that at this scale by identifying a common ground or a kernel and having a way to deal with diversity of approaches. In the subsequent chapters, we will discuss the approach taken by Essence in greater detail.
In this chapter, we have introduced the following terms: opportunity, stakeholders, requirements, software system, work, team, and way of working. Essence will give these terms greater rigor and provide guidance to software teams on how to build a stronger foundation to achieve their goals.
What Should You Now Be Able to Accomplish?
After studying this chapter, you should be able to:
• list and explain the things involved in all development endeavors, related to the customer (i.e., opportunity, stakeholders), solution (i.e., requirements, software system), and endeavor (i.e., work, team, way of working);
• give examples of different types of stakeholders, together with their interests and concerns;
• explain the mediating role of requirements;
• name and explain the three key characteristics of software systems (i.e., functionality, quality, and extensibility); and
• explain what makes a good team.
Understanding the facets of software engineering covered in this chapter provides an overview of the main core of Essence. This core may seem fairly abstract at this point, but as you read on, you will recognize all these facets in the Essence alphas, and be able to apply them in more and more practical and detailed ways.
5
The Language of Software Engineering
The goal of this chapter is to present how the concepts discussed in the previous chapter are expressed as a language similar to how a programming language is expressed in computer science. Thus, we learn the concepts of alpha, alpha state, work product, activity, activity space, competency, and pattern, and how these concepts are expressed. We will show in this chapter
• the language constructs of Essence;
• the role of alpha states in two alphas and related checklists;
• the meaning and benefits of essentializing a practice; and
• the concept of cards as a practical way to use the various language elements of Essence.
What you learn here provides the necessary handles to use Essence in practice!
5.1 A Simple Practice Example
Essence provides a precise and actionable language to describe software engineering practices. Just as there are constructs like nouns and verbs in English, there are constructs in the Essence language in the form of shapes and icons. Just as a child learns a language by first using sentences without understanding the underlying grammar, we will introduce the Essence language through a simple pair programming practice. We choose this very simple practice because it is easily understandable even for students new to software engineering. We will introduce more sophisticated ones in later parts of the book.
We describe this programming practice as follows.
• The purpose of this practice is to produce higher quality code. In this case, we assume that the concept of code quality is understandable to the different members of the team.
Figure 5.1 Simple programming practice (pair programming) described using Essence language.
• Two persons (students) work in pairs to turn requirements into a software system by writing code together.
• Writing code is part of implementing the system.
Essence uses shapes and icons to communicate the Things to Work With, the Things to Do, and Competencies. We shall describe each of these categories in turn and at the same time demonstrate how Essence provides explicit and actionable guidance for them, delivered through associated checklists and guidelines.
Figure 5.1 shows the elements in our simple programming practice. The shapes and icons are the constructs, i.e., the “nouns” and “verbs,” in the Essence language.
These different shapes and icons each have different meanings, as quickly enumerated in Table 5.1. As the text continues, we will go into greater depth for each one of them and explain their significance.
5.2 The Things
