aspects of this evolution. First, it does not merely entail hacking or patching code into the software system. Otherwise, as the software system grows in size, it will be harder to add new functionality. Consequently, teams often organize software systems into interconnecting parts known as components. Each component realizes part of the requirements and has a well-defined scope and interface. As a student, the lessons you will learn about object orientation, etc. are about organizing the software system into manageable components.
Second, code needs to be well structured and easy to relate back to the requirements. Just as the requirements will evolve, the software system needs to be extensible to such changes.
Third, the evolution involves transitioning the software system across different environments, from the developer’s machines, to some test environment, to what is known as the production environment, where actual users will be using the software system. It is not unusual to find that software that works on the developer’s machines will have defects (or bugs) in the test or production environment. Many senior developers get irritated when they hear novices say: “But it works on my machine.” A developer’s job is not done until they system works well in the production environment. A quality software system must:
• have a design that is a solution to the problem and agreed to;
• have demonstrated critical interfaces;
• be usable, adding value to stakeholders; and
• have operational support in place.
4.4 Software Engineering Is Also about Endeavors
An endeavor is any action that we take with the purpose of achieving an objective, which in our case means both delivering value according to the given opportunity and satisfying stakeholders. Within software engineering, an endeavor involves a conscious and concerted effort of developing software from the beginning to the end. It is a purposeful activity conducted by a software team that achieves its goals by doing work according to a particular way of working.
4.4.1 Team
Software engineering involves the application of many diverse competencies and skills in a manner similar to a sports team. As such, a team typically involves several people and has a profound effect upon any development endeavor. Without the team there will be no software.
Good teamwork is essential for high performance. It creates a synergy, where the combined effect of the team is much greater than the sum of individual efforts. But getting to a high-performance state does not come naturally; instead, it results from a deliberate attempt to succeed.
To obtain this high level of performance, the team members should reflect on the way they work together and how they focus on the team goal.
Teams need to:
• be formed with enough people to start the work;
• be composed of personnel possessing the right competencies/skills;
• work together in a collaborative way; and
• continuously adapt to their changing environment.
When working in TravelEssence, Smith belonged to a development team. Although members of Smith’s team had slightly different skill sets, they collaborated to achieve the team’s goal together. Smith was particularly focused on backend technologies (i.e., the part of the software system running on the cloud), whereas Grace, a colleague, focused on front-end JavaScript and React Native technologies. (Since these technologies are not the emphasis of this book, you don’t need to know them. Moreover, technologies change rather quickly. Instead, what we want to emphasize is that effective teams have to address the opportunity presented to them to satisfy stakeholders.)
4.4.2 Work
When a team comes together to do the work of making the opportunity a reality in the software system they build, the purpose of all their efforts is to achieve a particular goal. In general, there is a limited amount of time to reach this goal: they must get things done fast but with high quality. The team members must be able to prepare, coordinate, track, and complete (stop) their work. Success in this has a profound effect upon meeting commitments and delivering value to stakeholders. Thus, the team members must understand how to perform their work and recognize if the work is progressing in a satisfactory manner. Doing the work, then, involves:
• getting prepared;
• communicating the work to be done;
• ensuring that progress and risk are under control; and
• providing closure to the work.
In TravelEssence, Smith and his team managed their work through a backlog. The backlog is a list of things to do, which originated from requirements. They communicated regularly with their stakeholders to make sure that their backlog was accurate, up-to-date, and represented the stakeholders’ priorities. In this way, they could focus on getting 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