Choosing the Right SDLC Model for Your Project, Team and Risk Profile

Version note: This post is based on the Cynefin framework introduced in Dave Snowden and Mary Boone's 2007 article "A Leader's Framework for Decision Making" (with today's names for its domains) and on Barry Boehm and Richard Turner's 2003 book "Balancing Agility and Discipline".

Guess First

Bookstore has three projects ahead. The first is an integration with a bank's installment payment infrastructure: the bank's documentation is 140 pages, the audit team wants a record of every change, and the go-live date is fixed in the bank's calendar. The second is a new subscription product for libraries: nobody knows who will pay for which feature. The third is monthly sales reports for the finance team: it's clear what is wanted, and the users sit on the same floor.

Pick a model for each project: Waterfall, V-Model, iterative/Spiral, Agile with continuous delivery, or a mix. Then ask yourself: what information did you base your choice on? The team's habits, or the properties of the project?

A Model Is a Tool, Not an Identity

In the earlier posts of the series we saw that every model gives a different answer about the feedback loop. This post's claim is simple: a model is a tool chosen according to the project's risk profile. Sentences like "we're a Scrum company" or "we use the V-Model because we're an enterprise" turn the tool into an identity and take the project itself out of the question.

Barry Boehm and Richard Turner made this question systematic in their 2003 book "Balancing Agility and Discipline". They argued that plan-driven and Agile approaches each have a "home ground", an environment where they work best, and proposed assessing a project with five factors: team size, the criticality of failures, the dynamism of requirements, the experience level of the people, and whether the organization's culture leans toward chaos or order. The factors below are that idea adapted to a web team today.

Decision Factors

Requirements uncertainty is the first and strongest factor. If what is wanted is known and that knowledge doesn't change over time, planning up front is cheap. If what is wanted will only become clear once the user sees the product, an up-front plan is nothing more than a guess and short loops are needed.

Regulation and audit is the second. If an auditor wants to see that every requirement is paired with a test and every change was approved, that traceability has to be part of the model. This doesn't exclude Agile; but it makes the V-Model's traceability discipline mandatory.

Contract type is the third. A fixed-price, fixed-scope contract ties change to a formal request; a time and materials contract lets scope change from iteration to iteration. How Agile work fits with contracts is a subject of the Agile Mindset series.

Deployment cost is the fourth. A web application can be deployed dozens of times a day. A mobile app goes through store review and depends on the user updating it. A device's firmware may not be updatable in the field. The higher the deployment cost, the more verification each release needs in front of it.

Team distribution and access to feedback are the last two. A team that can't reach its users every week can't get the real benefit of short loops, which is real user feedback. A team spread across time zones and made up of different companies also needs written interfaces and contracts more.

Cynefin: Recognizing the Kind of Problem

The short way to weigh the factors is to ask what kind of problem you have. The Cynefin framework developed by Dave Snowden (a Welsh word, roughly "habitat") separates situations by when and how cause and effect can be known. Today the domains are called clear, complicated, complex and chaotic, with confusion in the middle for when it isn't known which domain you are in.

In the clear domain cause and effect are obvious to everyone; the right answer is found through a procedure: sense, categorize, respond. In the complicated domain cause and effect exist, but seeing them requires expertise and analysis; there can be more than one good answer: sense, analyze, respond. In the complex domain cause and effect are only understood in retrospect; up-front analysis doesn't give the answer, you find the way through small, safe experiments: probe, sense, respond. In the chaotic domain cause and effect can't be seen; you act first to stabilize the situation: act, sense, respond.

Translated into SDLC (Software Development Life Cycle) models, the picture becomes clear. A complicated problem, such as implementing a protocol the bank has documented, can be solved through analysis; up-front planning and the V-Model's discipline work here. A complex problem, such as finding out which feature libraries will pay for, can't be solved through analysis; short iterations, frequent releases and measurement are needed. A chaotic situation, such as a system on fire in production, needs incident management, not a model. A clear piece of work, such as the same report in the same format every month, should become a procedure and automation.

One of the mistakes Snowden often stresses is treating a complex problem as complicated and looking for its answer in expert analysis. The thought "if we write the right requirements document, the product will succeed" is exactly that mistake.

Decision Table

A rough table that puts factors and models side by side is a good tool for starting a discussion within the team. The table is not an algorithm; look at which question a cell pushes you to ask:

Three Scenarios and an Honest Description of Hybrids

The bank integration: the protocol is documented, the audit is heavy, the go-live date is in the bank's hands. This is a complicated problem. The fitting model is the V-Model's traceability combined with iterations. Requirements are derived from the bank's documentation and each is tied to an acceptance test; but development doesn't happen in a single pass, it happens in iterations that connect to the bank's test environment every two weeks. The trait-based tests from the third post of the series give the auditor an up-to-date pairing table in every iteration. The honest description of this hybrid is this: the outer frame is plan-driven, the inner work is iterative. The plan is built around a date that won't change; only the internal order of the work changes.

The library subscription product: nobody knows who will pay for what. This is a complex problem. The fitting model is short sprints, frequent releases and experiments measured with feature flags. Writing a long requirements document here would be a way of efficiently building the wrong product. Which experiment to run first and how to measure the results is the subject of the Introduction to Product Management series; the day-to-day way of working is in the Scrum and Kanban series.

The finance reports: it's clear what is wanted, the users are close by, the risk is low. This is mostly clear work, a bit complicated at the edges. A heavy process is unnecessary; a light, flow-oriented method such as Kanban is enough. The first version of the reports comes out within a few days together with the finance team, and the rest goes into the maintenance flow.

What the three scenarios have in common is that none of them uses a pure model. In the real world most teams work in hybrids, and there's nothing wrong with that. The problem is an unconscious hybrid: like water-scrum-fall, where one model's language mixes with another model's reality. In a conscious hybrid the team can say in one sentence which part is plan-driven and why, and which part is iterative and why.

Production Notes

Write the model choice down once at the start of the project: which factors, which domain, which model and why. Keep it short, like an ADR (Architecture Decision Record). The factors can change as the project progresses; a product that starts complex turns into complicated maintenance work as its market settles, and a light process becomes enough. The record lets you notice that change.

Choosing a model without choosing practices is a decision that stays on paper. A team that chooses "Agile" must also have chosen continuous integration, automated tests and small PRs (pull requests); a team that chooses the "V-Model" must actually maintain the pairing between requirements and tests. A model is only as real as the sum of its practices.

It is normal for different teams in the same organization to use different models. Instead of trying to standardize that, standardize the interface between teams: the release calendar, API (Application Programming Interface) contracts and shared metrics.

Common Pitfalls

Imposing the same model on every project is the most common pitfall. A single organization-wide process makes management easier but forces half the projects to work with a model that doesn't fit them.

The second is mistaking a complex problem for a complicated one. Six months of requirements analysis for a new product is looking for an answer through analysis to a question analysis can't answer.

The third is using hybrid as an excuse. If nobody can say which part is that way and why, "we're hybrid" is usually the new name of the old process.

The fourth is making the decision once and forgetting it. The project's risk profile changes; the model must be able to change too.

A Small Experiment

★☆☆ Assess the project you work on with the six factors in the decision table. Does the model you use today match the column the table points to?

★★☆ Place three pieces of work ahead of your team into Cynefin domains. Can you find an example where you treated complex work as if it were complicated?

★★★ Write a "model choice" record for your team: factors, domain, chosen model, chosen practices and the condition under which this decision will be revisited. Have a teammate read it and see whether they can say in one sentence why you use this model.

The SDLC series ends here: we saw the phases, the models and how to choose between them. To understand why Agile is so widespread today and what is really Agile in a team that says "we're Agile", the next series is Agile Mindset; its first post looks at the four values of the manifesto written at Snowbird in 2001.