Defining and applying suitable processes in an organization can be difficult since processes have to support the specific goals and needs of the organization.
The book The Incremental Commitment Spiral Model: Principles and Practices for Successful Systems and Software by Barry Boehm, Jo Ann Lane, Supannika Koolmanojwong and Richard Turner takes a different approach to process management by describing a process model generator.
It can help organizations to explore different process models and combinations of models to come to a solution that would fit each project’s stakeholder goals and current needs.
You can download a sample of the book which contains the chapter describing the principle of concurrent multidiscipline engineering.
InfoQ did an interview with Barry Boehm and Richard Turner about the principles underlying the Incremental Commitment Spiral Model (ICSM), applying the ICSM, benefits that organization can get from it, and how the ICSM can be used to help organizations determine under what conditions to use software-intensive agile frameworks like Scrum, DSDM, SAFe, or DAD.
InfoQ: Can you briefly explain the Incremental Commitment Spiral Model (ICSM) for the InfoQ readers?
Richard: The ICSM is the latest instantiation of the original software-oriented spiral model concepts Barry introduced in his 1988 paper, and includes the insights we have gained over the last 3 decades of experience implementing it in real world projects, including extensions to cyber-physical-human systems. While maintaining the fundamental risk-based, iterative approach, ICSM has been extended, adapted and refined from the original model. To avoid common misunderstandings (something known as hazardous spiral look-alikes), we have also emphasized the underlying principles as a means of focusing attention less on the spiral diagram and more on the rationale that leads to successful systems.
Barry: It is not a single one-size-fits-all process model, but a process model generator that enables projects to use their risk patterns to determine their best-fit process. It has a set of common risk patterns that indicate when it is best to use various forms of agile, plan-driven, or other forms of development. Its incremental commitment decision points enable projects to adapt their processes as new needs and opportunities arise.
InfoQ: What is the purpose of the ICSM, and how can projects apply it?
Barry: Its main purpose is to provide organizations with increasingly diverse classes of projects with an alternative to trying to fit them all to a one-size-fits-all process model, but also to use its four guiding principles as a basis for achieving shared project values.
Richard: As Barry indicated, ICSM is a model generator - a framework from which organizations can create, manage and evolve life cycle models that are supportive of their often unique development environment. It is fairly easy to begin to apply the 4 principles, and there is information in the book on how to incrementally implement the ICSM. It does, however, take some serious thought about your current processes, why they are defined as they are, and clear insight into the values of all the critical stakeholders.
InfoQ: There are four key principles which are underlying the ICSM. Which are they, and what makes them so important?
Barry: The four principles are:
- Stakeholder value-based guidance. Neglecting success-critical stakeholders generally leads to an unsuccessful project or enterprise.
- Incremental commitment and accountability. In an era of increasingly rapid change, single-step, fixed requirements projects generally lead to obsolete systems.
- Concurrent multi-discipline engineering. Sequential requirements-first or hardware-first approaches take too long and often over-constrain attractive cyber-physical-human systems solutions. Multiple stakeholder value propositions require concurrent attention to their reconciliation.
- Evidence- and risk-based decisions. Shortfalls in evidence of a proposed system’s superiority or feasibility are uncertainties and risks of unsuccessful projects. Chapters 13 and 14 elaborate on how to develop and evaluate evidence.
Chapters 1 through 4 elaborate on the principles via failure and success stories and implementation guidance.
InfoQ: Can you name some of the benefits that organizations can get from using the ICSM.
Richard: Given the current and most likely continuing instability resulting from rapid change in both stakeholder needs and the technology to address them, adaptability of the development process is a key competitive advantage. It provides both a significant market discriminator as well as a higher probability of success.
Barry: Some of the benefits are ensuring project success by making winners of the project’s success-critical stakeholders, reducing rework, technical debt, and project overruns by using risk- and evidence-based decision milestones and better adapting to increasing rates of change via incremental system definition and development. As cyber-physical-human systems become more prevalent (Internets of Things, autonomous devices, Google, Amazon), it can help software-intensive organizations succeed in developing and interacting with more complex cyber-physical-human systems. Summaries of benefits are provided at the end of Chapter 0 and in Chapter 12.
InfoQ: The ICSM is not a monolithic one-size-fits-all process model. Organizations can use the model to define and enhance their processes. Can you elaborate on that?
Barry: Table 11.3 in Chapter 11 provides criteria (size/complexity, rate of change, criticality, non-developmental item support, personnel capability) for determining agile and 9 other common process cases. These can provide a starting point, but the ICSM also has milestone decision criteria for adjusting the process to meet a changing or better-understood situation. This can include using different processes for different parts of a large system.
Richard: I think this needs a bit of amplification. In some environments, there may be multiple processes, with multiple development cadences, in play concurrently, and the ICSM provides a means of coordinating and synchronizing these processes. In other situations, particularly long developments or complex operational environments, the processes must evolve to meet the needs of the system and the environment.
InfoQ: I like the case studies that are provided in the book, for me they visualize how the ICSM can be deployed. Could you highlight one of the case studies?
Barry: A good one to highlight is the successful Intravenous Medical Pump project in Chapter 1. It had complex combinations of hardware, software, and human factors to address, stringent safety requirements, and a very competitive schedule, and used the ICSM approach to produce a technical award-winning and highly successful marketplace product line.
InfoQ: Is it possible to combine the ICSM with agile frameworks like Scrum, DSDM, SAFe, or DAD? Can you give some examples showing how it can be done?
Barry: One of the common processes referred to above, Architected Agile, is very similar to DAD. Table 12-1 in Chapter 12 identifies a couple of dozen good practices that are compatible with various of the common cases, including Scrum, DSDM, and SAFe.
Richard: The coordination and evolution capability allows ICSM to incorporate component-specific methods (e.g. RAD, SAFe, and Scrum, as well as DO-178C and other compliance-driven methods) without overwhelming the other components that may be more effectively developed using other approaches. Again, regarding question 6, it might be reasonable to say that most of the modern agile software techniques are heavily based on the concepts captured in the original software version of the spiral model, and so that common heritage is key to the ease of their inclusion within ICSM-based processes.
InfoQ: The ICSM also covers dealing with risks and opportunities, suggesting an incremental approach. How can you do this, and what is the advantage of addressing risks and opportunities incrementally?
Barry: The longer a risk is not addressed, the more risky commitments the project will make, causing an increasing buildup of technical debt that is increasingly expensive to pay off. Chapter 15 addresses the five major ways of dealing with risk: buying information, risk avoidance, risk transfer, risk reduction, and risk acceptance. Buying information via prototyping, modeling, simulation, stakeholder interviews, reference checking, or other methods is the best way to determine which of the other four approaches to take. The three ICSM system definition stages, Exploration, Valuation, and Foundations, are all about buying information to reduce risk and acting on it, as discussed in Chapters 6, 7, and 8. Chapter 9 provides an approach in which a separate agile systems engineering team addresses emerging changes and risks, and rebaselines the plans for the next development increment while the developers are thereby stabilized in completing the current increment. Each of these chapters include a list of most frequent risks to watch for at the end of the phase, and illustrates the practices via a single-thread Medical First Responder System example.
InfoQ: If an organization would like to deploy the ICSM, what would be a way for them to start?
Barry: It is best to start incrementally with the practices that would be most cost-effective to implement, such as adding feasibility evidence to the items to be evaluated at decision milestones, prioritizing increment features to support timeboxing, and adding an agile change assessment and increment rebaselining team to the development phases, as discussed on Section 0.5 of Chapter 0. As a bottom line, given that incremental commitment is one of the four ISCM Principles, it is not a bad idea for organizations to incrementally commit to the adoption of the full set of ICSM practices. Other ways to start would be to visit the ICSM web site at http://csse.usc.edu/ICSM, which will include times and locations for upcoming ICSM tutorials.
About the Book Authors
Dr. Barry Boehm is the TRW Professor of Software Engineering and the USC Distinguished Professor of Computer Science, Industrial and Systems Engineering, and Astronautics. He is also the Director of Research of the DoD-Stevens-USC Systems Engineering Research Center, and the founding Director of the USC Center for Systems and Software Engineering. He was director of DARPA-ISTO 1989-92, at TRW 1973-89, at Rand Corporation 1959-73, and at General Dynamics 1955-59. His contributions include the COCOMO family of cost models and the Spiral family of process models. He has honorary Sc.D. degrees from the U. of Massachusetts and the Chinese Academy of Sciences. He is a Fellow of the primary professional societies in computing (ACM), aerospace (AIAA), electronics (IEEE), and systems engineering (INCOSE), and a member of the U.S. National Academy of Engineering.
Dr. Richard Turner has over thirty years of experience in systems, software and acquisition engineering. He developed and acquired software in the private and public sectors and consulted for government and commercial organizations. He is currently a Distinguished Service Professor at the Stevens Institute of Technology in Hoboken, New Jersey. A core member of the author team for CMMI, Dr. Turner is now active in the agile, lean and kanban communities. He is also an author of the IEEE Computer Society/PMI Software Extension for the Guide to the PMBOK. Dr. Turner’s current research includes using kanban and service concepts to transform systems engineering and applying lean and complexity concepts to critical system development and acquisition. He is a Golden Core awardee of the IEEE Computer Society, a fellow of the Lean Systems Society, and co-author of four books: The Incremental Commitment Spiral Model, co-authored with Barry Boehm, Jo Ann Lane, and Supannika Koolmanojwong, Balancing Agility and Discipline: A Guide for the Perplexed, co-authored with Barry Boehm, CMMI Survival Guide: Just Enough Process Improvement, co-authored with Suzanne Garcia, and CMMI Distilled.