9 Applying Essence in the Small – Playing Serious Games

In part 1, we have illustrated how the kernel and practice elements can be represented as poker-sized cards. A card provides a concise description of the most important information about its element. Additional details may be available in complementary guidelines.

Cards are handy and can act as reminders to the practitioners. In addition, since they look like playing cards, it is natural to use them to play different games to help the teams achieve goals when developing software. We use the cards to play games as facilitation tools in a variety of settings and purposes, for example, to help teams obtain a consensus about their work. Cards are also a good way to introduce the kernel and practice elements to people who are new to Essence. Software development is a highly intellectual and collaborative endeavor as described in part 1. To achieve good results most of the work is performed and planned by teams where the team performance is strongly dependent upon effective communication, common understanding and trust. All team members must understand the endeavor purpose, its benefits as well as its problems and resolve any conflicts within limited time.  For this reason, most of the serious games utilized in software engineering are collaborative in nature.

In this chapter, Essence is used in a tacit manner without explicitly described practices on top of it.  However, we will also introduce some simple, small but very useful techniques to facilitate working together within a team. We call these techniques games – serious games. Serious games may be entertaining, however, their purpose is beyond entertainment. By simulating lifelike events, serious games aim at achieving some specific goal. Usually, this goal is to solve a particular real-world problem or to learn something new. Games also provide a powerful tool aiding in the development of many different skills.  They help us in developing basic mental abilities such as perception, attention, and decision-making. Furthermore, in the context of this book, games can be highly reusable when carrying out practices resulting in, for instance, the software.  In the games, team members or as we will call them in this chapter players play in groups with one another rather than against each other. No one strives to become the winner who takes it all.  Consequently the games we play within software development are cooperative games rather than competitive games.  Serious games facilitate team communication that is needed because different members within a team often have different backgrounds and experiences and they have different perceptions about the progress and health of their software engineering endeavors.

To achieve common goals and maximal results, the players must express their thoughts clearly, listen to one another, share information and resources, learn from one another, identify solutions, negotiate, and make common decisions. Playing serious games with the Essence cards is one way to help team members observe how their teammates reason, and help them with their own reasoning in a structured way.  This is because by using natural words used by most software development teams in naming the alphas, states, and checklists, the cards stimulate a team to discuss the issues related to the health and progress of their own endeavors.

In addition, once the team members understand where they are, they can use the cards to look ahead at states and checklists not yet achieved thus stimulating discussion on what is most important to do next.  

In this chapter we will introduce four games using cards, specifically the alpha state cards:

  1. Progress Poker
  2. Chasing the State
  3. Objective Go
  4. Checkpoint Construction

Concerning the games in this chapter, what is important is to learn the purpose of each game. We only describe the games to help you understand one way the use of the Essence kernel can facilitate the work within the team and we only describe a few of the games that can be played using cards; however, there are many other games that can be played with the Essence cards to achieve similar or other goals and there are other techniques that can be used along with the Essence kernel to achieve other desired goals (see [10, 11]).  

9.1 Progress Poker

One of the most important questions teams often face is ‘Are we done?’ referring to a particular piece of work being completed. This has resulted in deep discussions of the definition of done. While there are several definitions of done, our definition relates to the movement of an alpha from one state to another state.  Take for example the software system alpha, which over the lifecycle of a software system moves over six different states.  The definition of done here is related to when have you done everything to qualify for a state change.

What does it take for example to move from Architecture Selected to Demonstrable?

Figure 35       Software System: Demonstrable state card

Let’s now look at the individual checklist items in Figure 35.  Take for instance the item, Key architectural characteristics demonstrated.  Is the meaning of this checklist item clear? Well some people would say they know what it means, but within a team members can make several interpretations.  One team member may say that this means that the key architectural characteristics have been agreed to and demonstrated to the team members, while another may think it means the agreement and demonstration must involve external stakeholders.  It is true that the checklist items do not provide a precise definition.  If they were they would likely be unintelligible to most developers.  They are not unambiguous, but they provide a hint of what needs to be done.  They are subject for interpretation by the team members, who may have different opinions on their meaning.  One way to reach an agreement is by playing the game Progress Poker.

Progress Poker is a game played to facilitate the discussion and achieve understanding of the current state of a particular alpha.  It is played one alpha at the time.  This is a very important game that is reusable in many different situations in an endeavor.  For instance if you want to know where the endeavor is, you play this game for each alpha and then you will know very precisely the progress that has been achieved by the team. Just as in the original poker game, its tools are a deck of cards (in this case a deck for each of the players), a table and a set of rules and procedures. The difference lies in the act of playing with a goal of winning which is the case with the original poker game. Progress Poker, rather, is a consensus-based game. Its main objective is to assure that everybody is on the same page.  In order to play Progress Poker you need the Alpha Overview card and the Alpha State cards for the particular alpha the team is trying to gain an understanding of the current state.   Figure 36 shows these cards for the Requirements alpha.

(NOTE – original poker does not involve a deck of cards for each participant)

Figure 36       Tools needed to play Progress Poker (Alpha State Overview card and Alpha State cards)

Here, there is no single winner. The winner is the whole team and the winning hand is the team’s common agreement on the endeavor status.

Progress Poker may be played by any number of players.  However, experience has indicated that it is most effective in teams consisting of three to nine players. When you have less than three players often there are not enough different viewpoints to make the game worthwhile, and when a team gets larger than nine there is an increased risk of not reaching consensus.  There is no fixed duration of the game, however, for teams familiar with the states and checklists it may only take a few minutes to play.  The game ends as soon as a consensus has been reached on the current state that has been achieved for a particular alpha.

Let us now play the game of Progress Poker. The team decides that they will play the game with the Requirements alpha with the objective of reaching consensus on its current state.  Our players, the team members, gather around the table each with their own set of alpha state cards for the particular alpha.  To communicate that the Requirements alpha is under consideration, they place the alpha state overview card in the center of the table, just as it is shown in Figure 36. Each player then uses the set of state cards for the alpha and they identify the card that they think best represents the current state. Just as in the original poker game, they should keep a poker face that is keep the card of their choice confidential. After having selected their card, the players should place them face down on the table and wait until everybody has made his/her choice. By doing so, they make sure that everyone’s initial opinion is not affected by anyone else’s opinion.  After everyone has chosen his/her alpha state card, the players then, all at the same time, turn their chosen state card face up and compare the results.  

The result of playing Progress Poker may vary. In the simplest case, all players have selected the same state card, and therefore, they have the same understanding of the endeavor status. For instance, all team members have chosen the Bounded state. Hence, they have achieved a consensus among the players, and therefore, they do not need to continue playing Progress Poker for the Requirement alpha and the game is over.

Quite often, the players have different opinions about the state of the alpha under consideration. Therefore, the cards that they have chosen will differ. To gain a common agreement, the players have to discuss their choices. Usually, the players with the least and the most advanced states should start the discussion. They have to explain and motivate why they have chosen their alpha states. This in turn may lead to further discussions revealing the details of the endeavor status and the next round of progress poker may be played. The number of rounds required is dependent on how soon the team reaches consensus. It may take three rounds for the team to arrive at a common agreement. In some cases, it may be necessary to create an explicit list of requirements to resolve the issue. In contrast to the original poker game, everyone has to take part in all the rounds of the game. As pointed out earlier, the winning hand here is the agreement of the entire team. It is only achieved after everybody has pulled out the same state card.

There is another variant of Progress Poker that teams can decide to play.  In this game someone on the team plays the game alone, and then explains their results to the rest of the team.   When playing this variant of the game it is recommended that after the results are shared the team leader encourages the team to provide feedback as to whether they agree with the assessment or not.  This game can be effective at stimulating communication and collaboration in organizations that have cultures where decisions and direction are expected to come primarily from those in authority.

9.1.1 Benefits of Progress Poker

One of the benefits of Progress Poker is that everyone on the team gets involved since each team member is forced to make an assessment and explain their views when their assessment differs from their teammates.  Each team member must think through and talk about why they assessed the state the way they did. This helps teams avoid making decisions that are not rational, and it avoids the situation where just a few team members’ decisions drive the team.  The game also helps to ensure that all checklist items are considered.

9.1.2 Example of TravelEssence Team Playing Progress Poker

We will describe how Smith introduces Essence and the cards to his team members.  After learning about Essence and the alpha state cards, Smith was eager to share and apply what he had learned.

Smith and his team had been assigned to work on providing some new functionality for TravelEssence, specifically a recommendation engine for travellers.  Based upon discussions with Angela, the business analyst, Smith found out that the goal of this recommendation engine was to recommend hotels and discount deals to travellers based on their travel history, promotions and so on.

Tom, Joel, and Grace were members of Smith’s team. After a brief introduction to what the alpha state cards are about, the team played the Progress Poker game seven times – one for each alpha - to determine their current state of development[1].  They were already initially in agreement for all the alphas apart from the Stakeholders and Requirements alphas. See Figure 37.

Figure 37       Differing views on state of Stakeholders and Requirements

Smith’s team couldn’t immediately agree on what the Stakeholder and Requirements states were.

  • Smith thought the Stakeholders were quite well represented and the members were actively involved helping the team.  For example, Angela, as a business analyst was a key stakeholder who he had been talking to about the requirements for the recommendation engine, and Angela had shared with Smith what she had learned from her analysis.  Therefore, Smith deemed the Stakeholders state to be Involved.
  • Smith thought the Requirements were fairly clear because of the work Angela had done.  Therefore, he assessed the Requirements to be in the Coherent state.

However, other team members begged to differ.

  • Grace pointed out that in the past, business analysts frequently did not represent stakeholders well. They would say one thing, and when it was close to delivery, some higher-level authority would say something quite different. This resulted in unplanned rework late in the endeavor.  Therefore Grace saw the Stakeholders as Represented, but not Involved. 
  • Grace also pointed out that it was not clear how the new requirements would affect the existing functionality of the Hotel Management System (HMS).  Therefore Grace saw the Requirements as Bounded, but not Coherent.

Smith agreed that while Angela had completed some relevant analysis she had not yet gone back to the customer stakeholders to gain their agreement, and that this created a risk to the endeavor. As a result the team agreed that the Stakeholders alpha had achieved the Represented state, but they still had some work to do to get to the Involved state, and the Requirements had achieved the Bounded state, but more work was needed to get to the Coherent state. 

Smith wanted to obtain a common understanding of the current state and what they needed to do to progress the endeavor.  He rounded up Angela, the business analyst, and his team together and played the Progress Poker game. Smith and his team had earlier played the Progress Poker game so they had a shared understanding of the current state, but this was Angela’s first contact with the alpha state cards. After a quick introduction, he asked Angela to lay out the cards, and he asked her which alpha states she thought had been achieved and what their current states were.

Angela was known to be rather terse when it comes to requirements. She would think that the team had understood her when in fact they did not. Smith and his team members held their breath, as Angela shifted the cards around.

But surprisingly, Angela also recognized that Stakeholder involvement was not sufficient because she had not gone back to the customer stakeholders to gain their agreement and that Requirements needed some more work. The source of the requirements was Dave, who was Angela’s boss. Dave needed more involvement, not just Angela.  So in the end everyone agreed that the Stakeholders were Represented, but not Involved, and the Requirements were Bounded, but not yet Coherent.

9.2 Chasing the State

With Progress Poker you can obtain consensus within a team on which state an alpha has reached.  You can of course also use Progress Poker for all alphas and agree on which states they all have.  This is normally required to be determined many times during an endeavor.  You need to find out where you are in the work. However, often teams are in agreement on which states most of the alphas have without having to play Progress Poker; they just look at the cards for each alpha and agree on which state has been achieved.  This faster way for achieving team agreement on where they are for all the alphas is accomplished by playing the Chasing the State game.

This game is initiated by laying out all the cards on a table for each alpha.  To the very left is the alpha overview card with a picture of all the states of the alpha.  To the right are all the alpha state cards with the first state card on the left and the last state card on the right.  See Figure 38.

Figure 38       Initial position for playing the Chasing the State game.

Now the first card for the Stakeholder alpha is discussed.  The team studies the first Stakeholder card (left) and agrees that all criteria are fulfilled, this is that state Recognized has been achieved.  See Figure 39.

Figure 39       Stakeholder: Recognized before and after discussion.

As a consequence, that card is moved to the left on the table as in Figure 40.

Figure 40       The Stakeholder alpha has reached its first state.

The game continues and the second Stakeholder state card is examined.  The team agrees that this state has also been achieved so that card is also moved to the left close to the first state card. Thus, the third state card is studied.  Here the team agrees that the criteria are not fulfilled so this card is not moved; it stays where it is.  Now we have the position as in Figure 41.

Figure 41       The current state of the Stakeholder alpha is agreed to be state 2.

The Chasing the State continues with the Opportunity alpha, the Requirements alpha, etc. until the Work alpha and in this example we ended up in the following as portrayed in Figure 42.

Figure 42       The current states for all alphas have been identified.

The state of the endeavor can be described as Stakeholders: 2, Opportunity: 2, Requirements: 2, Software System: 1, Team: 2, Way of Working: 1 and Work: 1.

In this particular game it was assumed that everything went smooth and the team could easily agree upon the states that had been achieved.  That is not always the case, so if the team can’t easily agree, they can play Progress Poker for the particular alpha that is not easy to agree upon.

9.3 Objective Go

The Objective Go game is played to agree upon where you need to go next.  To know where to go next you of course need to know where you are.  This game is played after you have assessed the current states of all the alphas. Thus it is usually played after you have played the Chasing the State game. Let us therefore take the start position for the game as in Figure 42. In this position, the team asks the question “Which is the next step we should take to progress the endeavor?” or in other words “Which are the next set of alpha states we should achieve?” The team may decide that their objective is to move to the next state for all seven alphas, or they may decide that the next step should be to focus on just one or a few of the alphas to progress to the their next states. 

An experienced team would not deal with one alpha at the time but instead take a holistic view and agree on which alphas to progress next.  It would be a mistake to think that alphas progress independent of each other.  In fact we have learned through experience that the alphas often progress in “waves” that cross multiple alphas.  A simple example is that the Requirements alpha cannot be progressed without also progressing the Stakeholders alpha; to achieve the Coherent state of Requirements you need to have Stakeholders: Involved. See Figure 43.

Figure 43       Requirements and Stakeholders alpha wave

Let’s for example assume the team agreed that one of their next objectives is to reach the Software System: Demonstrable state.  This means the team agrees that there are checklist item(s) in the Demonstrable state that have not been achieved. See Figure 44.


Figure 44       The Software System alpha - where the team is and where they need to go next.

 As an example, let’s look at the checklist item, Key architectural characteristics demonstrated, in Figure 44.  The team may have differing opinions on the interpretation of this state, and they may have ultimately agreed that they had not achieved this checklist item.  Suppose this is the case and the reason is that the team felt they had not demonstrated a key performance requirement to a key stakeholder.  The team would then discuss and agree on what to do next, such as in this example, conduct a demonstration for that key stakeholder.  See Figure 45.

Figure 45       Team agrees demonstration to key stakeholder needed

In a similar way, the team looks at each alpha deemed interesting to progress in the next step. For each alpha they discuss the next state that should be achieved and which checklist items for that state are not yet achieved. Once they have agreed upon where they want to go next, they also discuss what tasks they need to do to get there. For each alpha the team has agreed to progress to a higher state, its corresponding state card is moved to the middle of the table as in Figure 46.

Figure 46       The next step is represented by the cards in the middle of the table.

In our example the team agreed to in the next step move to Stakeholders: Involved, Software System: Demonstrable, Way of Working: Foundation Established, and Work: Prepared.

9.4 Checkpoint Construction

Usually, organizations have defined lifecycles that consist of phases that are separated by checkpoints. Checkpoints are intentionally independent of the practices a team agrees to use because one of their main purposes is to assess the endeavor from different viewpoints such as value, funding, readiness.  In this sense checkpoints can be viewed as critical points in the life cycle of an endeavor where the definition of “done” for the phases needs to be specified.  At each checkpoint, a decision is made whether to proceed to the next phase or not. A checkpoint can be defined using alpha states as we have shown in section 6.5.2. 

Since an endeavor can have many teams working in parallel, to synchronize between the teams, they usually all need to have the same checkpoints. Thus, the checkpoints for an endeavor are normally specified by the stakeholders of the whole endeavor and not by every team participating in the endeavor.  Therefore, this game is played by the stakeholder team, or a few of the key stakeholders.  When in this section, we refer to team we mean the stakeholder team - a few key stakeholder members that can represent the views of the stakeholders.

Checkpoint Construction is played to gain consensus on the checkpoints in an endeavor’s lifecycle. To illustrate the use of this technique, we will use the same simple lifecycle example as in section 6.5.2. The lifecycle of the software development endeavor comprises three phases, pre-development, development, and post-development.

Let us now play the Checkpoint Construction game. Our players, the stakeholder team members, gather around the table.  The game is played for one checkpoint and in two rounds.  One team member accepts the role of facilitator and lays out on the table the seven Alpha Overview cards.  The facilitator next describes the checkpoint being considered.  Let us assume we are going to specify the Ready for Development checkpoint. 

In the first round each team member considers each of the seven alphas and decides which ones should be considered as part of the checkpoint.  They each jot down their choices.  Then the facilitator for each Alpha Overview card asks the team whether that alpha should be considered in the checkpoint.  Each player responds to that question using a thumbs up/thumbs down. Thus, in this round the team just agrees on which alphas should be considered for the checkpoint. After going through all seven alphas the team agreed all alphas should be considered except for the Opportunity alpha, which Angela was handling. See Figure 47. 

Figure 47       Results of team playing first round of Checkpoint Construction game

Now, the second round is played.  The facilitator lays out all of the alpha state cards horizontally across the table for all of the selected alphas to be considered for the checkpoint.  Each player considers the set of states for each alpha and without informing the other players he/she identifies the state he/she believes the alpha needs to be in to pass the checkpoint.  When everyone is ready the players simultaneously raise their hand with the number of fingers indicating the state they believe the alpha needs to be in to pass the checkpoint.  A closed fist is used to indicate the sixth state.  If all players have selected the same state there is consensus.  If not, the players with the least and most advanced states explain their reasoning.  After discussion the players again simultaneously raise their hand indicating the state they have selected. This step is continued until consensus is reached.

Once the state is agreed the facilitator leads the group through a discussion of potentially additional checklist items to be added for this checkpoint.  In this way the generic checklist items on the cards can be tailored to the context of the specific endeavor.

We have now showed how Essence can be utilized in helping to define a checkpoint.  By applying the Checkpoint Construction game several times a whole lifecycle can be defined, for instance the lifecycle in section 6.5.2.

9.5 Reflection

What we, as authors, have found is that serious games using Essence can provide effective facilitation techniques. Ideas are never absent when knowledgeable workers come together. Cards provide a good avenue to bring these ideas to reality very quickly.  They engage all members of the team, not just the most vocal or the most experienced or competent.  The fact that the states and their checkpoints are not unambiguous is not just negative; it results in engaging discussions, which helps the team to think about issues they might not think of from just their own personal experiences.  They need to agree what those issues mean to their endeavor.  Ultimately this helps the team address issues and risks early before they become major problems.   This not only helps to keep the endeavor on a healthy course, but it also helps team members learn to collaborate effectively, as well as bringing the team together.


[1] If the team had been more experienced they could  have discovered that they, without playing Progress Poker, were in agreement on all alphas apart from the Stakeholders and Requirement alphas.