Incremental Commitment with Spiral Development

Unless you're building software as a hobby, someone is paying you for that work. Those paying are likely doing it as something other than a hobby, too. They expect to get their money back sometime in the future. The notion of writing software for money was lost somewhere in the discussion of?writing software for money.?

Those with money pay those with software writing capabilities to produce products that can be sold or used to create value in return. Along the way was a disconnect that software is an end in itself and that the needs of developers trump those providing the money for the developers. Those spending the money get to say what they'll do, how they'll do it, or what they won't do with that money.

Writing software for money as practiced in a?sole contributor paradigm provides nearly infinite flexibility on requirements, cost and schedule forecasting, and the current notion of making business, programmatic, and technical decisions without estimating the cost and impact of those decisions.

When that paradigm leaks into a larger domain of producing a?return on the investment from that cost, two variables must enter every conversation—tValuelue generated by expending a?Cost to assess both variables.

ROI = (Value - Cost) / Cost

A Value at Risk?is one approach to assessing what processes should be in place when spending other people's money—the larger the?Value at risk, the Value required to manage the cost and Value.?AgiValues many values, and the domain and context of software development or any project must be assessed before stating that any method is applicable outside the speaker's anecdotal domain.

The first assessment is always?Value at Risk. That is, what is the cost of making a wrong decision? This is the basis of Microeconomics. This is the?opportunity cost assessment of decision-making.

Microeconomics studies the behavior of individuals and small impacting organizations in making decisions on the allocation of limited resources. Cost, schedule, and technical capabilities are certainly a limited resource.

Those conjecturing decisions can be made without estimating the cost and impact, but the viability of those ideas in practice has yet to show, at least outside small projects with low?Value at Risk.

The Incremental Commitment Spiral Model (ICSM) is a process framework that uses principles to define life-cycle processes for projects and programs. It's based on a project's characteristics, risks, and constraints. The ICSM is applicable to projects of all sizes but is especially useful for projects that require multiple life-cycle models.?

The ICSM is based on the following principles: Stakeholder value-based system evolution, Incremental commitment and accountability, Concurrent multi-discipline engineering, and Evidence and risk-based decisions.?

The ICSM is a process generator, meaning it can steer a process in different directions depending on the circumstances. It combines systems engineering, lean, and agile approaches and can address a wide range of system sizes and time scales.?

The ICSM can help reduce rework and technical debt, improve maintainability, and handle emergent requirements.?

The ICSM is rooted in the Iterative and Incremental Development (IID) methods, which have been used since the mid-1970s.?

The Incremental Commitment Spiral Model: Principles and Practices for Successful Systems and Software, by Barry Boehm and Jo Ann Lane, is a good?bridge book between small, low-value, at-risk agile, Scaled Agile for Enterprise, and the full-up formal DOD 5000.02 acquisition processes that are trying very hard to move into the agile domain.

The book starts with four principles:

1. Stakeholder value-based guidance
2. Incremental commitment and accountability
3. Concurrent multi-discipline engineering
4. Evidence and risk-based decisions

There are extensions to these principles:

• Risk Meta-Principles of Balance - balancing the risk of doing too little and the risk of doing too much to find the middle course?sweet spot.
• Theory W (Win-Win) theorem - in which a system will succeed if and only if it makes winners of its success-critical stakeholders.

System Success Realization Theorem - in which making winners of success-critical stakeholders requires:

• We are identifying all of the success-critical stakeholders.
• It is understanding how each stakeholder wants to win.
• Having the success-critical stakeholders negotiate among themselves a win-win set of product and process plans.
• I am controlling progress toward the negotiated win-won realization, including adapting it to change.

Here's more depth about ICSM from the Boehm Center for Systems and Software Engineering.

And, Craig Larman's?Iterative and Incremental Development: A Brief History?describes two programs where Barry Boehm worked in the early 1970s.