Risk-driven development with the spiral model

The spiral development model is risk-driven, iterative, and incremental in nature. It is a hybrid software development model that contains elements of both waterfall and agile. In some startups, it is classified as one of the agile frameworks, as it emphasizes close cross-collaboration and continuous customer and market feedback. However, it also includes waterfall elements like heavy process documentation and extensive formal risk analysis.

So how does the spiral model work? When should you use it? And why should you care as a PM? This article will be the go-to guide for this unique, widely-used software development process.

What is the spiral model and how does it work?

The spiral model — also known as Boehm’s spiral model, the spiral development model, the risk-driven model, the cyclic model, and the incremental, iterative model — is a cyclic, iterative model for software development that involves a risk-driven approach to developing products.

It’s called a spiral because the overall process is illustrated like a spiral. Each spiral is a loop of activities to iterate on the product and improve it further. The goal of each spiral is to refine the product and improve it toward the overall product goal.

For a PM, the spiral model can be a framework that allows risk management, continuous improvement, and adaptation to the changing user conditions and requirements throughout the product life cycle.

The process works through a series of spirals (aka cycles). Each spiral focuses on building a specific set of requirements or user needs. The focus of each spiral should be enhancing the product incrementally.

Unlike other methods like scrum, the spiral does not necessarily output a shippable product. So, instead of concentrating on building a shippable product at the end of each cycle, the focus of the team shifts towards mitigating the top risks by tackling the highest-priority user requirements. The spiral model also tries to alter the product manager’s focus from feature factories to only building and iterating based on changing market conditions and user feedback.

Product teams should note that:

• Regardless of the spiral output, the product should still be functional and usable at the end of each cycle
• Each spiral should tack on a tangible product improvement. This can be in the form of massive significant changes, new features, improved UX, or increased stability and security (non-functional aspects of the product)
• The decision of whether a spiral should result in a shippable increment or not should be made collaboratively by the product team. It should be based on specific user needs and the overall goals of the products.

What are the four phases of the spiral model?

As we mentioned earlier, each phase (or cycle) should tackle a specific set of user requirements. Those requirements can be functional (tangible product improvements and features) or non-functional (security enhancements, code refactoring, or technical debt).

To achieve this goal, the spiral model utilizes four steps within each cycle. Those steps are:

1. Planning

The product manager focuses on defining the spiral’s objectives, identifying the requirements needed to achieve the objective, and, lastly, defining the scope of the spiral.

2. Risk analysis

In this phase of the cycle, the product manager pulls their risk register and identifies all of the potential risks associated with the spiral’s objectives and requirements. Risks can be technical, financial, market-related, operational, and/or environmental.

The product manager then established strategies to mitigate those risks and goes back to redefine some components of their requirements.

3. Engineering and development

In this phase, the engineers take what was documented in the requirements and translate it into a functional product. The product manager in this phase validates and ensures that what was built meets the requirements and objectives of the spiral.

---

Over 200k developers and product managers use LogRocket to create better digital experiences

Learn more →

---

4. Evaluation

This is the last step of the cycle. The product managers evaluate the success of the output of the spiral using the defined metrics in the spiral objectives. The product manager, with the internal and/or external stakeholders, identified areas of improvement that can be incorporated into future cycles.

Advantages of the spiral model

Each software development model has its own advantages and disadvantages. Here are a couple of unique advantages of using the spiral model.

Systematic risk mitigation

The spiral model emphasizes risk analysis. Throughout the product life cycle, the product managers will be continuously assessing and managing the risks. This can result in a more reliable and stable product.

Lower time to market

By breaking down the product into tangible implementable chunks, product managers can prioritize and identify the highest priority features for their customers and launch MVPs faster.

Close customer and stakeholder collaboration

In every cycle and in the evaluation stage, it is a must for the product managers to seek stakeholder and customer feedback and compare it with the planned success metric. By doing this regularly, the product manager can be more aligned with the customer’s problems, needs, and expectations.

When to use the spiral model

In general, the spiral model is best for teams working on high-risk, complex projects. It’s also a great option for teams that may be working on a product with a long development schedule or those with uncertain or up-in-the-air requirements. The spiral model’s iterative nature helps keep the risks that associate with these types of project at a minimum.

The spiral model is practiced in some product teams responsible for building internal products. Because such projects are associated with high risk and high complexity and are mostly not exposed to external users, those products mainly act as a critical component to the overall business success of the company. This is the most common use case for the spiral model.

An example product that was built through the Spiral model is NASA’s space shuttle program in the 1970s. The product was complex in nature, full of algorithms and features associated with high risk. Mainly, NASA’s team used the spiral model to identify and mitigate the risk early in the product development process. Here are the ways it benefited them:

• Risk management — the project team back then used it to manage the risks associated with the space shuttle program. The model allowed NASA to identify potential risks early in the development process and to develop strategies to mitigate those risks. Those risks were mostly operational and technical, so there was no way the team could tolerate any failure in the process. They moved slowly but surely
• Iterative development — the spiral model’s iterative approach allowed them to refine and improve the space shuttle over time by adding enhancements and features based on the collected feedback. Each iteration of the model involved testing and evaluation of the shuttle’s design, leading to continuous improvement of the vehicle
• Stakeholder involvement — the spiral model emphasizes the involvement of stakeholders, and NASA used this approach to involve engineers, scientists, managers, investors, and other stakeholders in the development process. This allowed them to incorporate feedback from different perspectives to ensure that the shuttle met all types of needs of all stakeholders
• Phased development — the spiral model allowed the tech team at NASA to divide the development of the space shuttle into more minor, manageable chunks of functionalities. This approach made it easier to manage the project and track the progress

Final thoughts

The spiral model is a complex software development process that tackles high-risk, complex projects. The model focuses on identifying the risk early in product development, developing strategies around it, and reflecting those strategies on what to build. This allows product teams to build the product through cycles.

In each cycle, objectives are planned, risks are identified, and features are prioritized and delivered. Feedback is collected and reflected in the overall strategy at the end of the cycle to make sure that the product is built according to the changing user requirements and market conditions.

Featured image source: IconScout

LogRocket generates product insights that lead to meaningful action

LogRocket identifies friction points in the user experience so you can make informed decisions about product and design changes that must happen to hit your goals.

With LogRocket, you can understand the scope of the issues affecting your product and prioritize the changes that need to be made. LogRocket simplifies workflows by allowing Engineering, Product, UX, and Design teams to work from the same data as you, eliminating any confusion about what needs to be done.

Get your teams on the same page — try LogRocket today.