14 Kick Starting Development with Practices

In part 2, we saw how a small team kick started development using Essence. In this chapter, we extend the process with the use of explicit practices to help the team with specific challenges they face. Note that our kick-start process now has been changed. The main difference is that the team is not just tacitly agreeing on the things to monitor as we saw in part 2, but is now agreeing on explicit practices that they will apply.  Thus, the kick start sequence is now as follows:

  1. Understanding the context through the lens of Essence
  2. Agree upon development scope and checkpoints (where it begins and where it ends)
  3. Agree upon practices to apply
  4. Agree upon the important things to watch

In the remainder of this part we will explain what each of these items mean, and we will describe how teams can use practices effectively in development along with the value explicit practices can bring to teams over the simpler tacit practices described in part 2.

14.1 Understand the Context through the lens of Essence

We have already explained in part 2, chapter 10 why it is important to understand the context of a development endeavor and how the Essence kernel alpha states can help. What we are illustrating in this part is the similar to that in part 2, except that the context is different. In part 2, Smith’s team was just starting and striving to produce a demo version of the product.

Following a successful demonstration, Dave, the Chief Digital Officer, the head of the Digital Transformation Group (DTG), decided to move ahead to the next phase of this initiative expanding the scope and vision of the endeavor.  As a result, there would be more people involved compared to the simpler endeavor described earlier in part 2.

  

Figure 68       Participants in our story

We have already introduced Dave, Angela, Smith, Tom, Joel and Grace in part 2 We will now introduce the new characters involved in the expanded initiative (refer to Figure 68). Cheryl was the Chief Information Officer (CIO) who was responsible for all IT systems operations including the development and enhancement of any IT system. Developers like Smith, Tom, Joel and Grace, worked for Cheryl.  Tan, from Operations, also worked for Cheryl.

Table 4 shows a mapping of Essence kernel alphas to the current state of the alphas at this point in time, and the rationale for the assessment of the current state achieved.

Table 4           Development Context through the lens of Essence

Alpha

State achieved

Rationale for achieving the state

Stakeholders

Involved

Cheryl, Dave, and Angela are key stakeholders in the endeavor.  The state is achieved because they were actively involved in helping the team achieve a successful demo.

Opportunity

Value Established

Achieved the state because the team had a successful demo supporting the objectives of the digital transformation group.

Requirements

Bounded

Achieved the state because they had successfully gotten the key stakeholders involved and those key stakeholders had reached a shared understanding of the extent of the proposed solution.

Software System

Architecture Selected

Achieved the state because they had made their decision to use the existing proven Mobile App, and to use an architecture approach referred to as microservices to host their recommendation engine

Work

Initiated

Achieved the state because all the team members had agreed that the source of their funding and the stakeholders who would fund the work were clear

Way of Working

Working Well

Initially tacit agreed practices as discussed in part 2 worked well for the team, but as we shall see the team eventually evolved to the more explicit practices of scrum, user stories, use cases and microservices due to changes in their endeavor as it progressed.

 

The state achieved of the Essence kernel alphas as described in Table 4 was based on where the team assessed themselves to be after their initial effort to produce a demonstration as discussed in part 2. As we move forward we will learn how the endeavor conditions changed and how this affected the way the team assessed their achieved state.

14.2 Agree upon development scope and checkpoints

As we have stated previously, a team needs to know where it is going. In part 2, chapter 10, we demonstrated how the Essence kernel alpha states can be used to discuss and come to an agreement on what should be achieved by a checkpoint[1], such as an internal demo as our team successfully achieved. In general, if a team had enough knowledge to accurately plan the road forward, it normally would look ahead and identify several checkpoints including a release roadmap,

Dave and Angela discussed how TravelEssence would introduce the recommendation engine to their travelers. They agreed on an incremental approach starting with a small number of internal users and gradually rolling the product out to travelers across various regions of the world as depicted in Figure 69.

Figure 69       Release Roadmap

Internal users were primarily folks from the sales and marketing department whom Joel interacted with. These users travel as part of their jobs and are excellent candidates for reviewing the mobile application before introducing it to real users.

The first set of actual users outside of TravelEssence would be its fan club. This includes folks who were frequent and loyal users of the app and services provided by TravelEssence. After the fan club, the first target set of travelers would be frequent travelers to and through Singapore. TravelEssence had been approached by the Singapore Tourism Board and had been working with them. The Singapore Tourism Board had been actively seeking out collaboration with travel providers and TravelEssence executives agreed that this was a great opportunity.

With the first milestone (i.e. the internal demo) having been successfully achieved, it was now time for the team to set its sights on its next planned release, which had been agreed to be to internal users. While the Friday afternoon demo to Angela had been a success the team received feedback on areas that Angela felt should be improved before the next release. So, to get started the team decided to review the current state of the whole endeavor once again by playing the Chasing the State game to determine where they were, and then playing the Objective Go game as discussed in part 2 chapter 9. 

Below you will find a sampling of the results of the team discussions in playing the game and what the team agreed to be the next focus states to be achieved for the upcoming release to the internal users. 

Customer area of concern:

  • Stakeholders: Recognized -> Involved (see Figure 70) 

Figure 70       Stakeholders current and target states

While the team had agreed that they had achieved the Stakeholders Involved state during the internal demo, they realized that they now had new stakeholders joining the endeavor (i.e. Cheryl, marketing and sales) and so they would need to gain their agreement on their involvement and commitment.

  • Opportunity: Value Established -> Value Established (see Figure 71)

Figure 71       Opportunity current and target states

There would be no change in state for the Opportunity, except that the team would have greater confidence about the value of the recommendation functionality.

Solution area of concern:

  • Requirements: Conceived -> Coherent, Addressed (see Figure 72)

Figure 72       Requirements current and target states 

While the team had achieved their goal for the internal demo they knew there would be new requirements to be added during the next iteration as well as a need to address any specific issues that Angela had raised during the internal demo.

  • Software System: Demonstrable -> Usable (see Figure 73)

Figure 73       Software System current and target states 

While the team had successfully demonstrated critical parts of the system to Angela, the demonstration had also uncovered multiple defects that would need to be fixed before the system was usable. The team also knew there was more functionality that the marketing department felt would need to be added before the product was ready to be shown to real customers.

Endeavor area of concern:

  • Work: Initiated -> Prepared (see Figure 74)

Figure 74       Work current and target states 

Smith’s team had to quickly drill down the scope of the endeavor and come up with a credible plan and schedule for the initial release to the internal users and fan club.

  • Team: Collaborating -> Performing (see Figure 75)

Figure 75       Team current and target states 

While Smith’s team members had worked together before during the internal demonstration, they knew there were areas they could improve both their practices and tools, and there would be more team members to work with during the upcoming iteration.

  • Way of Working: Principles Established -> Foundation Established, In Use (see Figure 76)

Figure 76       Way of Working current and target states 

While Smith’s team had successfully established a development and test environment during the internal demo, the team members realized that there had been some miscommunications in the way they conducted certain activities.  As a result, the team members agreed that they would need more explicit practices to make sure everyone understood and agreed to how the team conducted these activities.

14.3 Agree upon Practices to Apply

Unlike the previous two steps, which we have also demonstrated in part 2 of the book, this third step is an additional step. In part 2 of the book, we were just using the Essence kernel and nothing else explicitly. In this third step, we are explicitly selecting a practice to apply. We assume that there exists a library of practices from which a development team can pick from to address its challenges. We also assume that the team is knowledgeable in selecting practices, or there is a convenient and easy way to do so. Of course, if a team does not possess this knowledge, there would be a facilitator or coach to help the team do so. Let’s assume for now in this part of the book that Smith is such a knowledgeable coach.

Smith’s development team was now no longer working on a demo or proof of concept. They would be working as part of a larger development team and as such would be using practices mandated for development

Cheryl, the CIO, had after a series of successful pilots mandated that Scrum and either User Stories or Use Cases be employed by all development teams. By “pilots” we mean endeavors where certain practices are tested to determine if they will work well in an organization before deploying the practices formally across the full organization.

Scrum is a popular practice to help teams collaborate and work in an iterative manner effectively. To develop software Scrum is not enough. We need practices to come up with the right requirements, to design, code and test these requirements.  Since Scrum suggests an iterative way of working, requirements, design and test are done iteratively – a small requirement to start with doing requirements, design and test and when working well, more requirements, etc.

When it comes to requirements we will demonstrate that development can be done in different ways by applying different requirement practices. We will first use the user story practice and then the use case practice. These practices are not equivalent; they address requirements breakdown and other aspects of requirements differently. However, in this book we won’t create a “methods war” because our intent is not to tell our readers which practices or methods we may think are better. Rather our intent is to explain how you can do your own comparison and reach your own conclusions when using Essence based practices.  

Many Scrum teams use user stories to help them understand and agree to the requirements.  A user story is a written description of a story that describes functionality that will be of value to a user of a software system. User stories are first written without all the needed details. The details are fleshed out in discussions between the team and the stakeholders. By encouraging informal conversations, the real needs of the customer surface, along with the details of the requirements.  Direct communication between development team members and users can be an effective practice to help ensure that the requirements that eventually get written down are in fact the real requirements needed by the users. We will elaborate on the user story practice in chapter 16 of this part of the book. 

Some teams decide that the short informal descriptions that are created with user stories are not sufficient to help them flesh out the requirements details. In such situations, use cases provide one possible alternative. Use cases help teams capture and validate the completeness of requirements. Use cases provide a diagram that gives an overview of all the use cases in the system being built and their interactions with one or more users of the system. This diagram also helps some teams evolve their requirements by clarifying what the system will do, and what will be done by the users of the system. We will discuss use cases in greater detail in chapter 17 of this part of the book. 

As previously mentioned, we employ use cases and user stories only as examples to demonstrate how the reader can use a similar approach to compare any two practices using Essence and reach their own conclusion on which practice may be best for them given their own situation.

In our story after the development team discussed what worked well and what didn’t work so well after the internal demo they realized they needed a more disciplined approach to capturing requirements. They started out with a plan to use user stories, but, decided that use cases better met their needs.

After some discussion, the team also decided to use microservices to help them evolve the software system. Microservices are small independent processes that communicate with each other through well-defined interfaces that is a basic idea of a good software architecture approach. By building the recommendation engine as a separate microservice rather than as a new module within the legacy system in TravelEssence, they would be able to experiment and evolve the new functionality with less risk of causing new defects in the legacy system. We will elaborate on the microservice practice in chapter 18.

Thus, for the next release to internal users, Smith and his team agreed to use the practices in addition to the kernel.

Figure 77       Practices for TravelEssence Teams

You will learn more about how teams can use Scrum, User Stories, Use Cases and Microservices as explicit practices later on in this part of the book.

We want to point out that the practices in Figure 77 are examples to illustrate how essentialized practices can help teams do their work. They are a mixture of collaboration, engineering and technical practices. For example, scrum is about team collaborations. User stories and use cases are requirements engineering practices (any decent requirements engineering book will discuss these two practices). Microservices is a highly technical practice, and we would deem it a rather advanced practice, in which even rather senior software practitioners are learning and experimenting with it as we write this book. 

As a software professional, you come in contact with many other practices. They are simply too many for us to even attempt to enumerate in this book. We believe that in due time, popular practices will be essentialized, and as a student or professional who has a good understanding of Essence will learn these practices quickly. We will discuss more about how practices help teams grow and become more competent when we conclude this part of the book in Chapter 19. But first, let’s return to our story and continue to watch what Smith’s team is doing.

14.4 Agree upon the Important Things to Watch

This fourth step to kick start development is similar to that in part 2, except that we have explicitly selected practices in addition to the Essence kernel. Recall in part 2, that the important things to watch out for in a software development endeavor are the alphas. The kernel has defined some universal alphas namely Stakeholders, Opportunity, Requirements, Software System, Work, Team, and Way of Working. These things exist independent of whatever way you choose to develop software. In addition, the kernel provides definitions of states and checklists as a reminder for teams to evaluate the progress and health of these things, and hence that of the software development endeavor. 

However, the alphas from the kernel are not the only things to watch. There are others. In part 2, we saw that Smith’s teams had other things to watch as well, specifically Requirement-Items. These are also alphas. In general, the practice you apply will explicitly call out specific things to watch out for, which we see in our TravelEssence story.

Having agreed on the practices to apply, Smith’s team now had inputs as to the important things (i.e. alphas) to watch to ensure health and progress (see Table 5).

Table 5           Practices that TravelEssence Applied

Practice

Description

Things to Watch (alphas)

Scrum

A practice for the iterative development of software systems working off a backlog

Sprint

Product Backlog-Item

User Stories

A way to capture functionality that will be of value to a user of a software system.  

User Story

Use Cases

All of the ways of using a system to achieve a particular goal for a particular user.  

Use Case

Use Case Slice

Microservices

A   software architecture style that uses small independent processes to communicate.

Microservice

Further explanation will be provided in subsequent chapters, but we want to provide a look ahead, to help you be aware about the important things to watch for in the practices that we are going to introduce.

  • Scrum is a practice for iterative development, where each iteration, or timebox, is called a Sprint. The Sprint is an alpha, something we need to watch. Scrum guides teams to complete work items in a backlog. These work items in the backlog, known as Product-Backlog-Items using Scrum terminology can also be treated as alphas.  
  • User Stories is a practice about expressing requirement-items more succinctly, focusing on values. Specific User stories can also be viewed as subalphas similar to  Requirement Items subalphas of Requirements.
  • Use Cases ([20] and [21]) is a practice that helps team identify and organize requirements in the form of Use Cases and Use Case Slices. A use case slice is a part of a use case that is suitably broken down to an appropriate sized piece of work for the development team to tackle. Specific Use Cases can be viewed as subalphas of Requirements and specific Use Case Slices can be viewed as subalphas of a specific Use Case. This is discussed further in the chapter on Use Cases in this part of the book. 
  • Microservices is a practice that helps teams break down a complex software system into a set of cooperating small independent modules each with its own purpose and each with its own well-defined interface to other modules.  Specific microservices can be viewed as subalphas of the Software System kernel alpha and monitored as alphas.

From the discussion above, it should be very clear that alphas are very important things in a software engineering endeavor to help understand progress and health. The kernel calls out universal alphas explicitly, while practices call out practice-specific alphas. It is important to identify the right alphas because there is a cost in making something an alpha due to the need to explicitly assess and track the alpha's state. As an example, small teams with lean budgets that have experience working together may decide to track their progress and related risks through tacit knowledge only, whereas large teams working on more complex efforts are more likely to see the need and payback in explicitly tracking progress and key risks as alphas. 

It is also important to identify the right states and the right checklists for each alpha since this is what a team uses when assessing their progress and health.  It is the explicit practices your team agrees to use that helps your team progress your alphas through its states by achieving the checklists. 

14.5 Journey in Brief

Summarizing what is displayed in Figure 77, moving from bottom to top, the TravelEssence team began with just the Essence kernel as we discussed in part 2. In this part, we examine how the team uses more explicit practices including Scrum, User Stories, Use Cases and Microservices as their endeavor becomes increasingly complex.   We summarize the topics in the remaining chapters in this part of the book as follows:

  • Chapter 15 – development team using Scrum
  • Chapter 16 – development team using User Stories
  • Chapter 17 – development team using Use Cases
  • Chapter 18 – development team Microservices

In these chapters, we will walk through TravelEssence’s journey of applying the above practices. In each chapter, we will briefly present an overview of the practice, the problems it solves, how TravelEssence adopted and applied the practice and the benefits they achieved, along with the benefits achieved by representing each practice in an essentialized form.

 

[1] Another commonly used word for checkpoint is milestone.