Aaen presents an interesting argument against using the traditional software process improvement (SPI) model for an organization’s existing software process, where SPI can be viewed as blueprint that is rigid, and that is unlikely to reach its full potential in practice. The author presents an idea to optimize SPI, and suggests that SPI can be viewed more as a recipe than a blueprint. The recipe view can be thought of as a set of guidelines used to tailor specific conditions that arise using the traditional SPI model, and that would otherwise fall short using the blueprint view, thereby leaving potential process improvement gains on the table.
By relaxing aspects of the traditional SPI model, the author suggests that the optimized recipe version provides the practitioner with a better view of an organization’s software development culture. In addition, the open-ended nature of using a recipe (instead of a blueprint) enables the practitioner to better understand the future needs of the organization’s software development culture.
The SPI model is known to be problematic, however, as suggested by the author, where a practitioner’s beliefs, values, emotions, perceptions, and behaviors could potentially alter the outcome of the traditional SPI model (and yield less than optimal results). So why is it better for the practitioner to use a recipe over a blueprint when it comes to the cost associated with this optimization? Also, doesn’t the open-ended nature of using a recipe instead of a blueprint actually introduce process complexity instead of reducing it, and translate into higher costs associated with the improvement? These are just a couple of questions related to potential costs that are not addressed by the author, but are important questions for practitioners to ask if they are considering SPI (since a benefit/cost analysis is usually required to justify an SPI project).
The author makes a bold attempt at an argument to optimize the traditional SPI model. The SPI practitioner should think very carefully before making any such changes to his or her organization’s software development culture, in order to yield improved gains in its software process. Otherwise, he or she might introduce inadvertent process complexity, which might result in higher costs associated with the improvement project.