12 The Development Journey

In chapter 10, we have shown how Smith’s team conducted one single iteration using Essence through the Plan-Do-Check-Adapt cycle. In this chapter, we will walk through how Smith’s team’s journey would continue to successful completion and discuss how Essence helps the team ensure progress and health.

12.1 Visualizing the Journey

Let’s look at Smith’s team’s development progression in terms of how its requirement items evolve across their journey. Figure 66 shows what is referred to as a cumulative flow diagram. Such a diagram provides a visual way of showing how the requirement-items progress. The diagram has time on its horizontal axis, and the distribution of requirement items across different states on the vertical axis. In this figure, you can see the states of the Requirement Item alpha (Identified, Described, Implemented and Verified). The team can use these states to help assess their progress and health in the iterations after the first one.

Figure 66       Cumulative Flow Diagram

Smith’s team’s list of requirement-items was not static. Not every item was identified upfront as shown on the y-axis. Instead, items were added at the end of each iteration cycle until the end of the third iteration. You can also see from this diagram that some items were verified in the first iteration. Those are the three requirement-items that were discussed in chapter 10 that the team would work on in the first iteration and demonstrated to Angela. As the team continued into iterations 2, three more requirement-items were identified, and more requirement-items were implemented and verified by demonstrating them to Angela. In part 3 we will discuss how the team used an explicit requirements practice (user stories or use cases) as their endeavor started to become more complex, and they realized they needed to improve their requirements approach.  

12.2 Ensuring Progress and Health

Most practitioners are concerned about progress; how much stuff gets developed; how many defects are found; how many defects are fixed, and so on. But the health of the development endeavor includes far more than these individual progress measures. The Titanic was progressing very well until it hit an iceberg and the rest was history. Similarly, often software endeavors appear to be progressing very well when limiting your view to only a few dimensions. The role of Essence alphas is to surface all of the essential dimensions so that an accurate progress assessment is always visible and timely actions can be taken when necessary. 

Table 3 shows the numerical evolution of the Essence kernel alpha states. By numerical, we mean that each number represents the nth state of the kernel alpha, e.g. state 1 of Requirements alpha is Conceived, state 2 is Bounded and so on. The column Start of Iteration 1 represents the time when Smith’s team received the work. End of Iteration 1 represents the end of the first iteration, which we discussed in detail earlier in chapter 10.   The complete story is four iterations.

Table 3           Kernel State Evolution

 

Start of Iteration 1

End of Iteration 1

End of Iteration 2

End of Iteration 3

End of Iteration 4

Target

Stakeholders

2

3

4

4

5

5

Opportunity

2

2

2

3

3

3

Requirements

1

2

5

5

6

6

Software System

1

2

2

4

4

4

Work

1

3

4

4

5

5

Team

2

3

4

4

4

4

Way of Working

1

2

3

4

5

5

 

Note: The numbers in the table indicate the achieved state.

For example, in our simple story in chapter 10 the team was able to get their key stakeholders (Dave and Angela) involved and therefore they achieved the Stakeholders: Involved state (state #3) in iteration 1. The team also successfully addressed all three requirement-items that were agreed to for the first iteration. However, Smith’s team agreed to apply Essence to the complete four iterations when assessing their progress. This means that although they completed all the requirement-items they planned to address in iteration 1, they did not assess their state of Requirements to have achieved the Addressed state at that point because they had not addressed all of the requirement-items needed for the full four iterations. Although the Requirements alpha doesn’t seem to progress in iteration 1 by introducing requirements-item sub-alphas the team can track more accurately the progress of each requirement-item and thus of the requirements as a whole. 

In the simple case, we described the states all progressed forward throughout the four iterations.  But when new requirement-items are added in later iterations it is possible that the requirements alpha state may fall back to a previous state.  This is because the new requirement-items may not have achieved the same state as the original requirement-items.  For example, they may not have achieved the Coherent state (state #3) or even the Bounded state (state #2). So the states of the alphas do not always move forward linearly as depicted in the figure and in our simple example.

We can also picture the evolution of the kernel alpha states as a radar diagram [12] (see Figure 67).

Figure 67       Radar diagrams for the start of iteration 1 and the end of iteration 3.

The endeavor evolved gradually with alphas progressing from lower states to higher states. If a particular axis in the radar diagram, i.e. an alpha, is progressing slower than planned such as Software System, this prompts the team to consider what is getting in the way and what needs to be done to keep progressing as planned. One possible way is to reduce the scope of the requirements or look for a different approach to implement the software system so that it can be validated earlier.

Thus, the individual alphas progress one by one and together the alphas progress in waves. In order to make progress for the whole endeavor, the alphas need to progress in a balanced way. For instance, you cannot progress the Software System alpha without also progressing the Requirements alpha. These parallel progressions in waves are critical for the success of the endeavor.

12 .3 Dealing with Anomalies

Well, the reality is that things don't always go according to plan. This means once you reach a certain alpha state things can happen to cause your endeavor to fall back. For example, stakeholders who were involved at the start of the endeavor may stop participating because of other priorities, and even though your work may be under control one day, the next day you may discover new risks that you never expected, and teams that are working well together collaborating may lose team members and new members with less experience may join the team. All of these kinds of situations can cause your endeavor to fall back. This is why teams should periodically use the Essence kernel alphas to provide a very straight-forward health check.