10 Kick Starting Development Using Essence

What we have presented thus far in this part provides a quick overview of how to productively utilize the Essence kernel. In the remainder of this part of the book, we provide greater detail how the Essence kernel helped Smith and his team with the development of the recommendation engine.

In our story Smith used the Essence framework to help his team ask the right questions and get pointed in the right direction. To get started, his team needed to know where they were and where they needed to head towards. The Essence kernel, together with some of the games we saw in this part provides the tools to do just that.

Getting started with Essence involves the following steps:

  1. Understanding the context through the lens of Essence
  2. Agreeing on the development scope and checkpoints, including where the endeavor begins and ends
  3. Agreeing on the most important things to watch

10.1 Understand the Context through the lens of Essence

Software development is really a problem solving endeavor. Problems can exist in any dimension of software engineering.

  • First of all, software development is a result of recognizing some problem or an opportunity. As an example, when Apple invented the iPhone Steve Jobs saw an opportunity to improve the way people communicated.
  • There can be many sources of problems. Some of them may be related to the software system itself that is being built or has been built; for example, if the software system already exists you may not fully understand the original requirements and/or the solution that led to the existing software system.
  • Perhaps you have problems related to getting stakeholders involved; For example, you may need to talk to users of the software system to understand their problems better, but they may not have time to talk to you.
  • Perhaps you have problems related to getting your team to communicate. For example, a less experienced developer may not be getting the guidance needed from a more experienced developer who is very busy. 

Like all problem solving, it begins with understanding the problem, which may include multiple related problems each found in the different dimensions of software engineering. Examples of the dimensions of software engineering include stakeholders, requirements, software system and the team.  You have to understand the requirements for the software system, but you also have to understand the needs of the stakeholders. Essence helps you understand your context by helping you understand where your problems are in each of the dimensions of software engineering. For example, the alphas help by leading us to ask questions about the development endeavor and they help us collect useful information pertaining to each alpha.

As an example, which we will use continually throughout the book, we will look at how a team evolves and in a later part of the book as their endeavor situation increases in complexity. We will explain how the team increases their explicit knowledge.

We consider the needs of the development team that has been assigned to an endeavor within a company TravelEssence. As you recall, TravelEssence is a leading travel service provider that targets both leisure and business travelers, as discussed in part 1.

Figure 48       Understand Context with Essence

Smith and his very small team came together and started capturing what they knew about the endeavor using some Post-It Notes and the Essence alphas; the result can be seen in Figure 48. The text appearing to be handwritten in the figure is only a sample of the type of relevant information for each alpha intended to help you get a sense for the kind of information associated with each alpha. This information is discussed below.

From the perspective of the Customer area of concern:

  • Stakeholders – The stakeholders in this endeavor included Angela and Dave from the Digital Transformation Group within the company. This group was tasked with employing digital transformation to expand the company’s business. Digital transformation is the use of technology to radically improve a company’s performance through changes in business models and improvements to customer experience. An example is adding features to a mobile plug-in to help frequent travelers. In particular, Angela was leading this digital transformation effort in collaboration with Smith and his team. Dave was the Chief Digital Officer (CDO) in the company and Angela’s boss.
  • Opportunity – Frequent travelers were already logging information about their trips and sharing their experiences to social media sites, such as Facebook, and Instagram. Thus, TravelEssence already had a significant amount of data about travelers. This situation created an opportunity for TravelEssence to generate more business by using traveler data from repeat customers to attract new customers.

From the perspective of the Solution area of concern:

  • Requirements – The specific requirements for the new endeavor included analysis of traveler data to identify trends and relationships and to recommend more exciting travel options to travelers. A measure of success would be an increase in customers accessing these options (e.g. clicks on the options by potential customer looking for more information).
  • Software system – TravelEssence already had a mobile application (app) that was cloud-based, which means their customers didn’t need to download and install any software on their own digital devices to access the service. Therefore, Smith and his team only needed to develop a simple plug-in (e.g. addition to the software) that would allow customers to view the recommendations on the already existing TravelEssence mobile app. Figure 49 shows the additions needed to the existing mobile app and to the existing cloud service to provide the recommendation enhancements.  Some of the team members would also need to learn how to develop software utilizing a software architectural style that uses small independent processes to communicate. This architectural approach is referred to as microservices.  You will learn in part 3 how to express practices using the Essence language and specifically, you will learn one way to describe microservices as a practice. 

Figure 49       Enhancement to the software system to achieve recommendations.

From the perspective of the Endeavor area of concern:

  • Work – Smith and his team were asked by management to deliver a working demo of the new product in one month.
  • Team – Smith’s development team comprised himself and three other developers, namely Tom, Joel, and Grace, all of whom were familiar with mobile app development. Tom and Joel had used microservices before, but this technology was new to Grace.
  • Way of Working – Smith and his team would use the facilities of the Essence kernel as a convenient way to evaluate their progress and health.  The practices in their way of working were not explicitly described.  They would use the alphas, states and checklists of the kernel to help them figure out where their problems were and where they would need to focus their attention as their endeavor evolved. They would also use the kernel to help them decide about the activities they needed to conduct to help solve the problems they identified.    The team referred to this as “vanilla” Essence because it included no explicit practices as extensions to the kernel.  They just used the alphas, states and checklist items to help their team initiate discussions leading to the agreed  upon actions for each of the team members. 

The team was able to use Essence this way because they had played the games described earlier in this part in a training class.  However, they hadn’t yet used the games on an actual project.  Their plan was to learn more about Essence, and the games, using common sense and experience to guide them.  In this way they would evolve their understanding of the different ways to use both the games and the kernel alphas.  Below we will describe a few examples of what resulted from this approach.  For example, we will describe how the team decided to add some additional alphas, referred to as “subordinate” alphas or sub-alphas for brevity.  As another example, we will also describe below how the team applied a number of the games previously discussed to help them run their endeavor and conduct progress assessments.  Later in part 3 you will learn a different way to use the kernel when we discuss how the team extended the kernel beyond the games and the sub-alphas when the scope of their endeavor became more complex.

10.2 Agreeing on the Development Scope and Checkpoints

The states of the Essence kernel alphas, together with each state’s checklists, can provide a straight-forward way for the team to gain agreement about preconditions for starting development and on the criteria for completing development. One way to help you understand how the kernel can do this is to review the Checkpoint Construction game discussed earlier in this part. Smith started the game by laying out on a table the state cards for all seven alphas.  Smith then said to his team, “we need to define two key checkpoints which we will name ‘Ready for Development’ and ‘Development is Complete’ see Figure 50.

Figure 50       Checkpoints and Phases for enhancement of TravelEssence

Smith continued saying, “Let’s start by selecting the alphas that need to be inspected at our “Ready for Development” checkpoint. Then we need to conduct a second round where we agree on the states of each if these alphas that need to be reached to say we have achieved this checkpoint, This checkpoint must be reached before we can formally start the development” (see Figure 51).   

Figure 51       Defining the two key checkpoints using alpha state cards.

After all the team members had considered all the alphas and noted to themselves, which alphas they thought should be included, Smith said, “OK, let’s start with the requirements alpha.  Using a ‘thumbs up, or thumbs down’, who thinks this alpha should be included in our Ready for Development checkpoint?” After the team members all voted and reached agreement Smith proceeded to lead the team through the voting for the other 6 alphas.  As you can see in Figure 51 the team members all agreed that all 7 alphas should be included in their Ready to Start checkpoint. 

Smith then led the team through the second round where each team member voted on their choice for which state of each alpha needed to be achieved to meet their “Ready for Development” checkpoint.  During the second round Grace disagreed with her teammates who all felt the Work alpha only needed to achieve the Initiated state.  Grace said, “I cannot start my tasks until the funding is approved, and that checklist is in the Work alpha Prepared state.” Tom quickly replied, “We can’t wait for formal management funding approval because the schedule is too aggressive and our organizational approval process is way too slow.”  Smith then replied, “Yes Tom, you are right, but Grace has a very important point. We can’t work without funding approval. So I will go and talk to Grace’s manager and explain the situation. I am sure we can get approval to start while we wait for formal funding approval.”  Everyone agreed with Smith’s approach to solve this dilemma. 

As you can see in the figure the team agreed that they needed to get the key Stakeholders Involved, and they needed to establish the value of the Opportunity and show that it was Viable.  They also needed to agree that the Requirements were Bounded and that Software System had reached Architecture Selected so that the key technical risks had been addressed.  They also agreed that the Work had to be Initiated, the Team Formed and they had to agree that their Way of Working had reached the Foundation Established state.   After the states were agreed to, the team discussed the checklists associated with each state and reached agreement on any additional checklist items they thought should be included.  Once this discussion completed Smith next led the team through a similar process to define the “Development is Complete” checkpoint (see Figure 51). 

10.3 Agreeing on the most Important Things to Watch

The team agreed that watching just requirements was too coarse for their endeavor because it would not be able to show them progress on a day-to-day basis. Often, the Essence kernel alphas need to be broken down into smaller items to measure progress.

Tom said, “in order to measure our progress with requirements we need more than just the Requirements alpha.”  

Angela, Smith and the team therefore agreed that they would track requirement items, defects and issues that would occur during development. The team’s work at this level could be reported each day. They agreed to use a simple spreadsheet to track progress for these items.

Sidebar 1       Sub-Alphas

When using the kernel it is unlikely that you will progress the alphas as a single unit. In each case you will drive the progress of the alpha by progressing smaller parts of the alpha. For example, the Requirements will be progressed by progressing individual requirement items.  Requirements Item is an example of what we refer to as a sub-alpha to Requirements.  Sub-alphas are alphas in their own right that help to move forward or slow the progress of the kernel alphas. As an example of slowing progress, Defect could be a sub-alpha of the Software System alpha that slows the progress of the Software System kernel alpha.

As another example, Requirement Item is a sub-alpha that helps to move forward the progress of the kernel Requirements alpha. The Requirement Item sub-alpha has states with checklists just like the kernel alphas that can help practitioners when assessing the state of the sub-alpha. 

Now, you may be wondering whether or not these sub-alphas, such as Requirement Item or Defect are part of the kernel?  The answer is that they are not part of the Essence kernel because they are not always needed – they are not essential. Depending on your specific endeavor and the practices your team agrees to use, sub-alphas may or may not be needed. You will learn more about practices in part 3 of the book where you will also see more examples of sub-alphas that are important to monitor once you have chosen to use certain explicit practices. 

After the team agreed that they had reached their ‘Ready for Development’ checkpoint, they decided to play the Chase the State game and the Objective Go game (see sections 9.2 and 9.3) to determine where they were and what they should focus on next. Smith handed each team member a set of Alpha State cards.  Smith then placed the Requirements Alpha Overview card in the center of the table. Each team member thought about which state they believed they were in and then placed that state card face down on the table.  When everyone was ready, they turned the card face up. As a result of playing this game the team agreed that they had already achieved the Requirements: Conceived state because they knew who their stakeholders were, and they knew which stakeholders would fund the new system.  However, they had not yet achieved the Requirements Bounded state. This was because the team agreed they had not yet achieved a clear understanding of what success meant for the new system.  See Figure 52.  Note: In the interest of brevity we are not discussing every checklist item in these states.

Figure 52       Requirements Conceived and Bounded states

They also knew from playing the Checkpoint Construction game (section 9.4) earlier that they needed to get to Requirements: Bounded and to Way of Working: Foundation Established state to get to their agreed to “Ready for Development” Checkpoint.  The team discussed the way they planned to work. They agreed that they would work in an iterative way, which meant they would provide frequent software deliveries to the customer. This discussion led to their agreement that they had reached the Way of Working: Foundation Established state.  To achieve the Requirements: Bounded state, Angela, Smith and the team sketched out the requirement items that would be part of their first month delivery (see Figure 53).

Figure 53       Requirement item list for the enhancement of TravelExchange

Having agreed on the Requirement-item list in Figure 53, the team agreed that they had reached Requirements: Bounded.  As can be seen in Figure 51, the team also needed to agree on the work that needed to be done to achieve the other five kernel alpha states for that checkpoint: Stakeholders: Involved, Opportunity: Viable, Software System: Architecture Selected, Work: Initiated, Team: Formed, and Way of Working: Foundation Established. This is an example of what we mean by stating that software engineering is multi-dimensional, and what we mean by stating that Essence helps the team stay focused on the most important things throughout their endeavor. In the following chapter we discuss how the team reached agreement on additional needed work.