11 Developing with Essence

To achieve the Way of Working: Foundation Established state the team needed to agree on their approach to development, which included selecting their key practices or mini-practices and tools. They agreed to work in an agile way, splitting up the whole endeavor into smaller mini-endeavors, each mini-endeavor resulting in progressing the work on the software to be built.  This approach is called iterative development and each mini-endeavor is called an iteration. An iteration is a fixed period of time in which the team develops a stable piece of a software system. The length of an iteration is typically two to four weeks and can involve all kinds of activities, including requirements gathering and the deployment of the resultant software system.

Developing your software iteratively is like taking a journey in your car. You need to know where you are, where you are heading, how much fuel you have, and how much further you have to go before reaching your destination. You adapt to the road conditions, traffic and weather as you drive. You are continually planning, doing, checking and adapting[1] (see Figure 54). This is how Smith and his team ran their iterations. Each iteration was set to be one week in duration.

Figure 54       Plan-Do-Check-Adapt cycle

Plan – First Smith’s team determined the current state of the whole endeavor by determining the current state of each of the alphas. This was done by the team playing the Progress Poker game (section 9.1) to start. But after having done it for the first two alphas they continued to play the Chase the State (section 9.2) game for the other five alphas. Smith led the team in the Progress Poker game by placing the first alpha overview card in his deck in the middle of the table.  Each team member then thought about which state they believed that the Requirements alpha was in and then placed the selected state card face down on the table.  When everyone was ready, they turned the card face up. After the team discussed the results and reached agreement on the state of the Requirements alpha, the team members picked up their cards.  They agreed that the Requirements had reached the Coherent state. 

Smith then placed the second alpha overview card in the middle of the table; he selected the Software System alpha.  Smith and his team repeated the same steps conducted for the first alpha with this alpha and they agreed it had reached the Architecture Selected state.

It turned out that the team didn’t need to discuss too much to obtain consensus, they found that they were in agreement immediately. Then Smith suggested that instead they would play the Chase the State game for the other alphas; they discussed openly the state for each of the remaining five alphas.

For the Stakeholder alpha, the team agreed that they knew Dave and Angela were their stakeholders, but they had not yet agreed on how they would get them involved.  Thus, the Stakeholder alpha was in state Represented. For the Opportunity alpha, the team agreed that they had achieved the Solution Needed state, but no one thought they had achieved the Value Established state.  Joel and Tom started to discuss how they might go about convincing senior management on the value of the endeavor, but Smith quickly interrupted saying, “Wait.  We are just conducting the game now to agree where we are.  Let’s hold off discussing which states we need to focus on next and how we will achieve them.  We will do that after we have fully assessed where we are now and can then decide what is most important to do next.”  Everyone agreed and they continued with the Progress poker or the Chasing the State games reaching agreement with the other alphas (Work: Prepared, Team: Formed, and Way of Working: Foundation Established).  See Figure 55.

Figure 55       The alpha states agreed after playing the Progress Poker or Chasing the State games.

After finishing the games, knowing where they were, they discussed and agreed to what alphas and states to progress in the coming iteration. This was done by the team playing the Objective Go game (see section 9.3).  Smith started the Objective Go game by saying, “We now know what state we are in for each of the seven kernel alphas. Now we need to agree on which states to focus on achieving in our next iteration.”  Joel replied, “So does everyone agree that the most important thing in the next iteration is to convince management of the value of our endeavor?”  All of the team members nodded in agreement.  Smith then said, “This means we have concurred that we need to achieve Opportunity: Value Established state in the next iteration.

The team continued to discuss the other alphas and reached agreement on which states in the other alphas they needed to achieve in the next iteration.  From this discussion, the team agreed that they needed to get their key stakeholders, Dave and Angela, involved meaning reaching the Stakeholder: Involved state.  They also agreed that the requirements for the upcoming iteration were both coherent, which means they were consistent, and that they needed to address them by demonstrating the implementation of those requirements to Dave and Angela. That is they needed to achieve the Requirements: Addressed state.  They also agreed the team needed to be collaborating, the work needed to be started and the way of working needed to be in use.  See Figure 56.

Figure 56       Result after applying the Objective Go game

Together they then planned how to achieve the target states by identifying tasks to be completed that would achieve these states.  As an example, they agreed that part of the work they needed to do was to set up a meeting with Dave and Angela to discuss how they would get them involved.  They also knew they needed to set up a test environment. 

This enabled them to connect the detailed day-to-day work of the team with the progress of the endeavor as a whole. If the effort to complete the tasks exceeds that available in the iteration, then it will take more than a single iteration to achieve the objectives and the target states. This means the team would need to break their tasks down further and agree on the pieces to complete in the current iteration.  As an example, they knew they could not get all four requirement-items done in the first iteration so they concurred to work on just the first three.

Do – Each iteration Smith’s team worked on the identified tasks to progress the endeavor as a whole towards the target states. This involved setting up environments, discussing requirements, capturing agreements, writing code, testing, and so on.  See Figure 57.

Figure 57       Task list

Check – Smith’s team tracked the objectives and tasks to make sure that they were completing what they had planned as they used their agreed way-of-working. The team discussed the healthiness of all alphas; unhealthy meant the alpha had a checklist that had not yet been met but it should have been met, or that the checklist had previously been met, but it was no longer met due to some change in the condition of their endeavor. The team placed green stickers next to the alpha state cards they had agreed represented healthy alphas. They also agreed that anyone could place a red sticker next to a card if they felt during the iteration that an alpha had become unhealthy.

Adapt – Smith’s team reviewed their way of working, identified obstacles and found better or more suitable ways of doing things. This often resulted in changes to their plans and their way of working.

11.1 Planning with Essence

When you plan an iteration, the alphas can help you understand where you are and where to go next. By aligning the objectives, they set for each iteration Smith’s team made sure that they progressed in a balanced and consistent way.  The alphas help by reminding you what is essential for success as your team decides what is most important to focus upon next.

As mentioned, Smith and his team agreed that they would work on cycles where each iteration was one week. It was the first day (Monday) of the first iteration week. Using Essence, they reviewed their current state and the states they had previously agreed they wanted to achieve by the end of the first iteration. Based on that they identified a set of tasks. Below you will find task descriptions that were agreed to by the team after discussing each alpha, the state they had achieved, and the next target state(s). The first state on the left in each diagram is the current state, and the state(s) listed after the arrow is (are) the target state(s).  Sometimes we have more than one target state for a given alpha. This is because teams often work to achieve checklist items in more than one state at the same time. When a team works iteratively they often are working to get some of the requirement-items both coherent and addressed in the same iteration.  For example, when our TravelEssence team was working on Req-Item #1 they needed to get the code to actually produce recommendations on hotels, and they needed to get clarification on how far from the traveler’s current location they should search for possible hotels.

From the perspective of the Customer area of concern:

  • Stakeholders: Recognized à Involved (see Figure 58) 

Figure 58       Stakeholders - current and target states

The team knew that two of their key stakeholders were Dave and Angela, but they had not yet gained agreement on their involvement and commitment. The team agreed to set up a meeting with Dave and Angela to clarify their involvement. (Task: Stakeholder Involvement Meeting).

  • Opportunity: Solution Needed à Value Established (see Figure 59)

Figure 59       Opportunity - current and target states

A solution was needed to exploit the traveler’s data, but what the solution required was still up in the air. The value of that solution still needed to be established to convince senior management at TravelEssence to move forward and fund the effort. The team’s immediate priority was to set up a test environment where they could quickly experiment with different ideas for using the traveler’s existing data to generate more traveler interest leading to increased revenue. This could help them quantify the value of the new system to Dave and Angela, the key stakeholders. (Task: Experiment with different ideas to increase business).

From the perspective of the Solution area of concern:

  • Requirements: Conceived à Coherent, Addressed (see Figure 60)

Figure 60       Requirements - current and target states

There are two target states, Coherent and Addressed.  To achieve their objectives in the current iteration the team needs to get three requirement-items into the Coherent state, and then they also need to move these requirement-items to the Addressed state. In the discussion below you see an example of how the team works toward these two target states at the same time.  Smith already had a simple requirement list. In the first iteration, Smith and his team would attempt to complete the following requirement-items:

  • Req-Item #1: System generates recommendations for a traveler
  • Req-Item #2: Mobile plug-in displays recommendations
  • Req-Item #3: System handles user’s selection to view or discard recommendations

Of course, some details needed clarification. As an example, the algorithm (calculation formula) to generate a recommendation, and which target set of travelers they would use as a test data set. This meant the next target state for requirements was to get to the Coherent state by working these issues. The team agreed that this would be done by Smith collaborating with Angela to reach agreement on the plan. Once agreed, the team would need to move forward quickly to address these requirements for the upcoming planned demonstration as discussed below under Software System. This means they need to move their requirement-items to the Addressed state.  (Task: Smith to work with Angela to reach agreement on recommendation algorithm, and which set of travelers they would use as their test data set).

  • Software System: Architecture Selected à Demonstrable (see Figure 61)

Figure 61       Software System - current and target states

To get to the Demonstrable state the team would need to code, test and integrate critical parts of the system and demonstrate the result to Angela. The team agreed to work on their respective requirement-items and integrate their work by Wednesday evening to be ready for a demo to Angela by Friday. (Task: Team members work on implementing their respective requirement-items).

From the perspective of the Endeavor area of concern:

  • Work: Initiated à Prepared, Started (see Figure 62)

Figure 62       Work - current and target states

To get to the Work Prepared state the team needed to make sure their tasks were broken down into sufficiently small pieces to fit in the agreed iteration, understand any related risks, and be sure they had a credible plan in place that extended beyond the current iteration. While Tom, Joel and Grace focused on the planning for the first iteration, Smith reviewed the work the team had agreed to do. As part of Reqt-Item #1 the team had discussed providing recommendations for both hotels and restaurants, but Smith decided this was too much for the first iteration and suggested the team limit the work in the first iteration to just providing hotel recommendations.  (Task: Team breaks work down to fit in iteration).

  • Team: Formed à Collaborating (see Figure 63)

Figure 63       Team - current and target states

Smith’s team members had successfully worked together before. They each knew their responsibilities and how they would work together, but the team had not yet showed that it was working as one cohesive unit. By setting the goal of integrating their work by Wednesday they would be able to verify that they were working as one cohesive unit. (Task: Integrate work by Wednesday).

Way of Working: Principles Established à Foundation Established, In Use (see Figure 64)

Figure 64       Way of Working - current and target states

To get to Foundation Established, the team needed to establish a development and test environment. Tom agreed to set up the development environment that included the team’s chosen repository version control tool and the test environment. Grace agreed to prepare the test environment and supporting scripts. Following the setup of the environment, the team would start to use the environment to complete their tasks during the first iteration. (Task: Establish development and test environment).

11.2 Doing and Checking with Essence

With the goals (expressed as target alpha states) and the tasks identified, Smith’s team proceeded to work on their respective tasks.

Smith and his team members were co-located sitting near each other in the work place. Angela’s work area was located on a different floor near Dave. They had an internal corporate chat application for collaboration. They could access each other when needed. In general, work went rather smoothly as the members were familiar with each other and the technology they were using.

On Friday afternoon, they did indeed achieve their goals and demonstrated the implementation of the designated requirement-items to Angela. They reviewed their health and progress by playing the Chase the State game again and comparing the results to the previous time.   In the following results the target state for each alpha is listed in parenthesis with the actual results of the team’s effort described afterwards:

From the perspective of the Customer area of concern:

  • Stakeholders (Involved) – Following the Friday demo Smith had a side meeting with Angela and Dave where they discussed and agreed to their involvement in future demonstrations.
  • Opportunity (Value Established) – The Friday demonstration was successful and convinced Dave and Angela that the system could potentially produce significant user interest leading to increased business. As a result Dave was ready to move forward and fund the effort.

From the perspective of the Solution area of concern:

  • Requirements (Coherent, Addressed) – The team had successfully clarified the open issues related to the agreed requirements, and then they successfully addressed those requirements in the Friday demonstration.
  • Software System (Demonstrated) – The team successfully demonstrated the critical parts of the system that had been agreed to for the Friday demonstration.

From the perspective of the Endeavor area of concern:

  • Work (Prepared, Started) – The team had successfully broken their agreed tasks down for the first iteration, understood the risks, and moved forward coding, testing and integrating the pieces in preparation for the Friday demonstration.
  • Team (Collaborating) – The team successfully integrated their work on Wednesday in preparation for the Friday demo. This activity verified that the team was working as one consistent unit.
  • Way of Working (Foundation Established, In Use) – The team had successfully gotten their environment set up and used it during the first iteration to complete the work for the Friday demonstration.

11.3 Adapting a Team’s Way of Working with Essence

The kernel has helped the team capture and apply the essence of software engineering. It has reminded them to:

  • involve your stakeholders
  • think about the opportunity
  • break your work down to fit in your agreed way of working
  • think about risk
  • clarify requirements
  • integrate your work with your teammates work
  • focus on the most important things now.

But still there will always be better ways of doing things. So after the successful Friday demonstration the team decided to discuss what went well, what did not go so well, and how they could do better during their next iteration.

During this discussion, Smith reminded the team of their agreed target alpha states from the first iteration.  See Figure 56.

Smith then asked:

  • What went well with our planning, doing and checking related to the above alpha states?
  • What did not go well with our planning, doing and checking related to the above alpha states?
  • What can we do better with our planning, doing and checking related to the above alpha states?

Joel said, “We achieved a successful demonstration and now Dave is going to fund our full endeavor so that certainly went well.”

Tom said, “The way you achieve the Requirements: Addressed state was not clear to me at the start of the iteration. I learned that I had to talk to Angela and get her to agree to the requirement-items to be implemented. I didn't understand this just by looking at the state checklist.”

Grace said, “Actually, Smith, for me to do my job better I would like to have better guidance regarding how to work on a requirement-item.”

Smith considered Tom’s request. That was easy, all Smith had to do was to supplement the state checklist with some additional guidance. He scribbled two lines of text onto the Requirements card as follows (see Figure 65):

  • Gain agreement on requirement items that are within scope of Addressed.
  • Implement these requirement items.

These notes were additional guidance on how to achieve the Addressed state.

Figure 65       Additional guidance beyond the standard on achieving a state

Then Smith considered Grace’s request. This request was not as easy. It meant making the way of working on requirement-items more explicit. We will discuss how to do this in part 3.

The way of working affects all team members, and every team member can contribute. This is another area where the kernel is useful. By talking about the alpha states after their successful demonstration, as we have just observed the team came up with a number of good ideas on how they could do better during the next iteration.

11.4 How the Kernel Helps You in Adapting the Way of Working

The kernel helps you adapt your way of working in multiple ways.

11.4.1 Helping a team reason about their way of working

First, it helps a team reason about their way of working and decide if there are improvements they should make.

Developers who come straight from an educational program often know more about programming than developing software and more about developing software than working as a team and improving their way of working. Because their experience is limited they often need a little help. The alphas and their states can help a team reason about their way of working as they try to improve.

When reviewing their way of working, we make the alpha states visible to the team members to help them think about their “process”. If you are conducting a review of your way of working for an iteration, you only need to make visible those states relevant to the current iteration (i.e. the target states for the iteration). This helps the team stay focused on reviewing just their way of working related to that iteration.

By visualizing the states, a mental transition takes place. The team is now looking at the “process”. We then look at each state specifically, and ask the same questions:

  1. What went well during this iteration and have we achieved this alpha state?
  2. What did not go well during this iteration and do we know what is keeping us from achieving this alpha state?
  3. What can we do better in the next iteration that will help us achieve this alpha state?

11.4.2 Making changes to the way of working

The daily contact your team has with the alpha states (and hence the kernel) help you find simple improvements to adapt your team’s way of working. This may mean adding additional items to the alpha state checklist to meet your team's needs. Teams can also define new alphas or add checklists to help team members, such as the text Smith added to Requirements Addressed to help Tom. How you extend the kernel elements further with more explicit practices is discussed in part 3 of the book.

Keep in mind that the team should only add information to the kernel elements and their checklist items. Changing the information that is already there would undermine the value that we gain through the use of a standard kernel. The standard is the basis for essentializing methods and practices, a subject discussed in part 1. You will learn more about essentializing in part 3 of the book; namely how to express explicit practices using the Essence language. 

You can just think of “essentializing software engineering” as representing the way your team is working using the Essence language and the Essence kernel common ground.     This can help your team understand more clearly what they might be missing that they need to be focusing upon in order to be successful in their endeavor. 


[1] We have modified Deming's PDCA cycle (https://en.wikipedia.org/wiki/PDCA replacing Act with Adapt as this is more descriptive of the intent.