Case 5: Introducing Customer Involvement

We now introduce the Customer Involvement gene, which means that there will be some requirements churn, however requirements uncertainty will be reduced as sprints progress, since the customer/user is available for feature demonstrations and immediate feedback.

Running a simulation with the above parameters yields the following results:

It seems that Customer involvement has improved both cost and schedule. The root of this is due to the effect of requirements uncertainty on the FCC.

Figure 78 shows the graph for Effect of Uncertain Requirements on FCC for cases 4 and 5. In case 4, there was no customer involvement, and thus no reduction in uncertainty (effect is linear at 0.85). In case 5, as each sprint nears completion there is less uncertainty (thus higher FCC) as the development team is able to demonstrate features to customers and clarify any uncertainty on a regular informal basis.

Case 6: Introducing Pair Programming

In the final case, we look at the effect that the pair programming has on our projects’ performance. In industry, pair programming is not practiced 100% of the time. Typically developers spend 20% to 50% of their time doing pair programming, thus we have set the value of Percent Time Spent on PP to a conservative 0.5.

Performing a simulation with these parameters produces the following project performance measures:

We see that our project performs even better in terms of schedule compared to case 5 (52.6 weeks vs. 55.2 weeks), as well as in cost (roughly 14000 fewer tasks in development effort). This is also counter-intuitive: Pair Programming has a significant effect on productivity, as described in section 5.2.6. This is visible in our graph of development productivity in case 5 vs. case 6, seen in Figure 79.

So, why does Pair Programming improve project performance? The answer lies in the amount of rework that is generated in each case.

As we can see in Figure 80, our FCC is significantly better when employing Pair Programming. It is well understood that this practice produced higher quality code, as it serves as a form of real-time inspection. However, what is not immediately obvious is that better quality code begets fewer defects in subsequent development. Thus, the loss in productivity is more than made up for by the lower defect generation rates when employing this practice.