The Incremental Commitment Spiral Model

The Incremental Commitment Spiral Model (ICSM) book is based on the initial work of Barry Boehm about the Spiral Model in 1988. According to the authors, ” Most of the problems in using the 1988 spiral model stemmed from users looking at the diagram and constructing processes that had nothing to do with the underlying concepts.” The book thus starts by explaining the four principles of the model before discussing it and explaining how to apply this process tailoring approach to your own software development organization and projects.

The four ICSM principles are:
1. Stakeholder value-based guidance.
2. Incremental commitment and accountability.
3. Concurrent multi-discipline engineering
4. Evidence and risk-based decisions.

The book “The Incremental Commitment Spiral Model” by Barry Boehm is an interesting iteration on the original spiral and provides a formal approach to incremental development. The book is written and structured in a formal style, but is still rather easy to read and a case study allows making some links between the concepts and their practical implementation. A book that I can recommend as a complementary reading to all Agile practitioners and that should be able to make more impact in organization that have a strong engineering culture with some mix of hardware and software development.

Reference: “The Incremental Commitment Spiral Model: Principles and Practices for Successful Systems and Software”, Barry Boehm, Jo Ann Lane, Supannika Koolmanojwong & Richard Turner, Addison-Wesley

Quotes

The ICSM is not a single, one-size-fits-all process. It is actually a process generator that steers your process in different directions, depending on your particular circumstances. In this way, it can help you adapt your life-cycle strategies and processes to your sources of change. It also supports more rapid system development and evolution through concurrent engineering, enabling you to develop and evolve systems more rapidly and to avoid obsolescence.

As systems have become larger and more complex, our development processes have evolved, but often failed to keep up. Too many times, the planned system never results in a usable product or the product is obsolete by the time it is ready for use. We are frustrated when others’ applications (e.g., mobile device apps) seem to appear overnight with very light, agile processes. We are also aware of agile and lean failures. In essence, we seek to answer the following questions:
* How can we more quickly get projects on a path to success?
* When are significant up-front investments still necessary for success?
* How can we provide value to the intended users and stakeholders quickly, no matter how large or complex the system is, and then allow the system to evolve at a pace close to the rate of change in stakeholder needs?
* Can we learn from recent lean and agile successes and failures, and find ways to scale up the successes?

Most of the problems in using the 1988 spiral model stemmed from users looking at the diagram and constructing processes that had nothing to do with the underlying concepts. This is true of many process models: people just adopt the diagram and neglect the principles that need to be respected. For that reason, it is important to carefully state the ICSM’s four underlying principles:
1. Stakeholder value-based guidance. If a project fails to include and address the value propositions of its success-critical stakeholders such as end-users, maintainers, interoperators, or suppliers, these stakeholders will frequently feel little commitment to (or even active hostility toward) the project and either underperform, decline to use the results, or block the use of the results.
2. Incremental commitment and accountability. Many success-critical stakeholders will object to making total commitments of their scarce resources to weakly defined ventures, but will incrementally commit to buying better information on them. Once a commitment is made, all stakeholders need to understand that they are accountable for keeping their promises.
3. Concurrent multidisciplinary engineering. If definition and development of (a) requirements and solutions; (b) hardware, software, and human factors; or (c) product and processes are done sequentially, the project is likely both to go more slowly and to make early, hard-to-undo commitments that cut off the best options for project success.
4. Evidence- and risk-based decisions. If key decisions are made based on assertions, vendor literature, or meeting an arbitrary schedule without access to evidence of feasibility, the project is building up risks. And in the words of Tom Gilb, “If you do not actively attack the risks, the risks will actively attack you.” Many of the hazardous spiral look-alikes described over the years conveniently dropped any consideration.