Delighting Customers

A delighted customer experiences two things with software: exceptional features and problem free usage. The project team can plan and track both of these during the development phase.

Is your development effort focused on the most important features?

Exceptional features come from customer intimacy and from motivated staff. Timely execution of the desired features to completion is the challenge. These features, better known as requirements, must be grouped by business priority. The business priority groups are managed as "feature bundles" and in their simplest form represent: must complete (bundle 1), should complete (bundle 2), and would be nice to complete (bundle 3).

Is your development plan "all or nothing," or flexible to achieve schedule?

Too often a majority of debug / rework effort waits until the end of the entire development plan. All the features are coded by the scheduled ship date, but are not necessarily in stable condition. The instability results in schedule slip and a lower shipping quality. When development occurs and completes in prioritized bundles, the lower priority requirements are forced off the schedule to allow timely, stable completion of the higher priority requirements.

What is your capacity to change requirements to meet unexpected market opportunities and threats?

An unexpected market-driven requirement carries a benefit and a priority. With a bundled development plan, the new requirement readily fits into an incomplete bundle. It fits without unduly disturbing the features already or nearly completed. Its addition merely forces lower priority requirements off the development plan.

Requirements Completion

Does every project team member know the priority of features / requirements and their completion status?

 Not completed, not required
 Not completed

 Bundle 1 % complete
 Bundle 2 % complete
 Bundle 3 % complete

Goals and priority only succeed when communicated. The above pair of graphs quickly communicates the current situation and the completion trend.

Each bar in the left graph represents the progress to date of one development bundle. The green area is the percentage of the bundle that is completed. The red area is the percentage remaining. The second and third bars have a yellow area. This indicates that those development bundles have requirements that are considered optional for shipment. Completion of those "stretch features" would be a bonus. With one glance at this graph, anyone can see the current progress and how much work is remaining.

The right graph gives the history of completion progress and the trend toward the completion goals. Each line represents one of the bars, the development bundles, from the left graph. The lines depict the percentage complete, the green area of the bars, on each date. Team members and senior managers can estimate when a bundle will complete by visually extending each line to its goal completion percentage.

Should developers fix bugs now or code out more features?

Each person on the project should first contribute his/her time to finishing requirements associated with higher priority development bundles. A given software feature has four typical tasks: design, coding, test, and rework. Only when all four tasks are complete, is the feature / requirement complete. Rework of higher priority bundles should interrupt design and coding of lower priority bundles.

Do your source code management practices support overlapping, but independent development bundles?

The typical source code repository tool is misunderstood. The misunderstanding is so severe that source code management actually reduces project team performance and introduces defects into a development plan. This can undermine efforts to organize and manage development bundles.

Each development bundle needs an independent repository branch from a common starting / shipping code base. This allows higher priority bundles to be polished without contending with raw code from later bundles. It is not reasonable to assume that any bundle can be 100% completed before the next bundle starts. Certain resources cannot contribute to every bundle or to every task within a bundle. These resources are best utilized on lower priority bundles while other team members finish higher priority bundles. However, the simultaneous work on two or more incomplete bundles must not be entangled. Once source is entangled, the development bundles are effectively merged. When all work is maintained in a single repository area, the development plan essentially falls back to "all or nothing" delivery.

Problem Free Usage

Problem free usage means the customer can install and use the software without undue effort or support. Software bugs, poorly designed usage scenarios, and overly restrictive operating environments cause hassle. The customer's hassle results in phone support costs, developer rework costs, and sometimes future sales loss. Also a developer doing rework is not contributing to the next product.

When is a development bundle complete? When is a product ready to ship?

The graph above shows the rate bugs are found over time. This graph's shape is typical. The find rate reaches a plateau for a period of time. Later the rate begins to drop as the code stabilizes. Finally it reaches a lower find rate, referred to as the basin. The plateau exists because there is an upper limit to how many bugs a team can setup, locate, and report over a given period of time.

A graph like this one should exist for each development bundle. Once the bundle's code is completed, open bugs fixed, and the graphed find rate approaches the basin, the bundle is complete.

The same graph can be drawn for the entire development plan. The graphs of each bundle are combined. The combined graph now shows the find rate for the entire project. Like each bundle, the project is complete when the code is completed, open bugs fixed, and the graphed find rate approaches the basin.

How often is your development code stabilized?

It is often difficult to estimate when the find rate will drop off the plateau, and further, how long it will take to get the find rate down to the basin. All or nothing development plans can get stuck with an extended plateau and substantial delays in reaching the basin. There is little the project team can do. They ship late and / or ship poor quality. The bundled development forces portions of the project to achieve the basin rate early. Therefore, there is always at least a portion of the project that is ready to ship. This gives the project team options.

Two other great benefits occur. First, the amount of time spent stabilizing the early bundles then becomes a better predictor for the later bundles. The team can review more options earlier. Second, the early stabilized code is available for sharing with internal and external reviewers. Limitations and key incremental improvements to the design have the opportunity to be detected well before shipment and potentially incorporated into later development bundles.

How do you "pull in" the schedule when the defect rate is too high?

Occasionally even the best executed development bundle experiences overruns in development time or an extended plateau in the bug find rate. It does not matter if this happens in an early, high priority bundle or a later, low priority bundle. The remedial action to maintain schedule is the same: drop lower priority requirements / development bundles.

Industry Experience

Intuit Customer Support Cost Reduction

In 1993, Intuit shipped Quicken 5. The effort was an "all or nothing" development plan. In contrast, the following product, Quicken 6, used a development plan with bundles. Quicken 6 achieved a 50% drop in customer support calls over those of Quicken 5. Intuit handled thousands of support calls per week, free of charge. Quicken 6 also had a larger sales base than Quicken 5. This 50% drop was significant to both the user community and Intuit profitability.

Boeing Customer Reported Defect Rate

Boeing Computer Services observed a direct correlation between software process maturity and software defect density. The company calculated cost of poor quality (COPQ) over the years during which their initial process improvement activities were gaining traction. Business savings came from lower rework costs, lower support costs, and greater capacity to respond to customer problems.

At the same time, the amount of software being developed at Boeing was exploding. Had Boeing not, in parallel, improved its development maturity, the COPQ would have seriously damaged their profitability.

Copyright 2002 On-Fire Associates. All rights reserved.