Figure 5.3 Requirements alpha state cards.
The other alpha in our example, the Software System, has the states shown in Figure 5.4.
The states are defined on the basis of an incremental risk-driven approach to building the Software System, first by establishing a sound architecture, and then by demonstrating key decisions about the Software System. These states are summarized as follows.
Figure 5.4 Software System alpha card.
Architecture Selected. Key decisions about the Software System have been made. For instance, the most important system elements and their interfaces are agreed upon.
Demonstrable. Key use of the Software System has been demonstrated and agreed.
Usable. The Software System is usable from the point of view of its users.
Ready. The Software System has sufficient quality for deployment to production, and the production environment is ready.
Operational. The Software System is operating well in the production environment.
Retired. The Software System is retired and replaced by a new version of the Software System, or by a separate Software System.
5.2.3 Work Products
Work products, again, are tangible things such as documents and reports, and may provide evidence to verify the achievement of alpha states. An example of a work product for the Requirements alpha might be some kind of a requirements specification—a description of the software system to be built. When a complete and accepted requirements document has been developed, it can be one way to confirm having achieved certain checklists within a state of the Requirements alpha. Yet the fact that you have a document is not necessarily a sufficient condition to prove evidence of state achievement. Historically, documentation has not always provided an accurate measurement of progress. Thus, you may reach the same state without any documentation or with very brief documentation, as long as the checklist for that state has been achieved satisfactorily.
Figure 5.5 The Code work product card.
Code is the example of a work product for our programming practice. We provide a concise description of this work product in the form of a poker-sized card, as shown in Figure 5.5.
Note that the work products you produce do not belong to the common ground represented by the Essence standard. They are dependent on how you want to work (which practices you want to use). Thus, Essence does not specify exactly which work products are to be developed, but it does precisely specify what work products are, how you represent them, and what you can do with them.
Work products can have different levels of detail. In a development endeavor, the degree of detail needed in work products can vary greatly, depending on many factors such as past history of team members working together, customer requirements, regulatory requirements (e.g., regulation for software validation of medical devices), and organizational policies.
In TravelEssence, for example, Smith’s team expressed requirements through use case narratives, which we will cover in Part III. These also have different levels of detail. For simple requirements, Smith’s team did not need as many specifics, but relied on more direct communication with their stakeholders. However, for more sophisticated requirements involving complicated calculation and decision rules, Smith had more complete explanations in his use case narratives.
Practitioners often have trouble figuring out how detailed the various work products they produce should be. Explicit practices, which we will cover in later parts of the book, can provide guidance on this.
5.3 Competencies
The team members applying the programming practice must, of course, be able to program; that is, they must have a development competency. Competencies are the abilities needed when applying a practice. Often, software teams struggle because they don’t have all the abilities needed for the task they have been given. In these situations, a coach can help by explaining different ways the practitioner can address the problem, such as learning something that is missing in their competencies.
Figure 5.6 shows the card for the Development competency. Similar in format to the alpha and work product cards, the top of a competency card has the competency icon (a star) and the competency name followed by a very brief description of the competency. Then a list of competency levels follows.
Figure 5.6 The Development competency card.
The Development competency has five levels of achievement.
1. Assists. Demonstrates a basic understanding of the concepts and can follow instructions.
2. Applies. Able to apply the concepts in simple contexts by routinely applying the experience gained so far.
3. Masters. Able to apply the concepts in most contexts and has the experience to work without supervision.
4. Adapts. Able to apply judgment on when and how to apply the concepts to more complex contexts. Can enable others to apply the concepts.
5. Innovates. A recognized expert, able to extend the concepts to new contexts and inspire others.
Teams should be encouraged to conduct a self-assessment of their competencies and compare the results to the competencies they believe they need to accomplish their specific endeavor. This useful exercise can help software teams objectively determine any competency gaps they may have, which they can raise to management for resolution before serious problems occur that could hurt their team’s performance.
5.4 Things to Do
To make progress in a development endeavor, or for that matter, any endeavor, all participants must do something. In our programming practice, this concerns writing code. The Essence language calls this an activity.
5.4.1 Activities
Activities are things that practitioners do, such as holding a meeting, analyzing a requirement, writing code, testing, or peer review. Similar to the challenges practitioners often face with determining the appropriate level of detail in work products, they also often struggle to determine the appropriate degree of detail or formality with an activity, or exactly how to go about conducting it. This is another motivation to specify explicit practices as they can provide guidance to practitioners in selecting appropriate activities, as well as in how to go about conducting each activity. A practice may include
