“Minimum viable process” is one of those phrases that seems sensible almost by definition. The leanest process that still delivers the quality, control, and efficiency an organization actually needs is worth aiming for.

In my experience, though, the emphasis often lands on “minimum” when it should land on “viable”.  The purpose of any process is to ensure that all necessary steps are taken to meet the development goals. I believe in tailoring, and some steps that may be useful for a team in one domain may only get in the way in another. 

The difficulty is that many teams do not approach it that way in practice. They build around the objectives, activities, and artifacts they believe a governing standard expects, then stop as soon as they think they have enough to pass inspection. The result can be defensible, but thin in important ways.

Certainly, the minimum viable process is a sensible objective.  The problem is that a process created from the ground up around compliance to a standard will often need several projects before it evolves into something that truly supports the team's quality objectives without unnecessary burden, and in some cases, that evolution never happens.  Supporting practices may be absent because they were never part of the narrow compliance picture at the start.  Gaps tend to become visible only later, when problems surface as weak evidence, late rework, or issues discovered too late to address cleanly.

That is probably one of the strongest arguments for starting from a fuller reference process and tailoring downward rather than starting from a compliance minimum and trying to build upward under pressure. When starting with a comprehensive process, a team can decide deliberately, with respect to any given step of that process, whether to shorten it, combine it, or remove it. If a step is missing entirely, the team may not discover the absence or why that step would have been useful until the project is already in trouble. Starting from a fuller baseline forces people to consider the consequences of removal. That is usually far easier than discovering a missing discipline halfway through a development cycle.

One common mistake is to treat visible artifacts as the problem. A team sees a design document, a traceability matrix, a review record, or a test specification and assumes it adds no value.  If this were true, then they would be well justified in eliminating the item.  However, artifacts such as this came to be for a reason.    The right question to ask is what engineering purpose it serves. If the artifact disappears, what clarity, control, or evidence is lost?  Is that loss worth the effort that was saved?  The answer might be yes, but it might not.  Too often, these questions go unasked.

It’s also important that these evaluations are made with the participation of someone who understands the larger engineering and regulatory context, especially in highly regulated environments. Some process steps look excessive only to people who do not understand what those steps are protecting. In those settings, the danger is not just over-trimming. It is the introduction of habits of thought that treat requirements, design definition, verification planning, and supporting evidence as optional burdens rather than as part of the discipline that keeps the work safe, coherent, and defensible.

When teams reduce process without a clear understanding of what each part was doing, the result is often not less process but deferred process. Requirements do not disappear; they reappear as arguments during implementation, when the original rationale has faded, and intent is less clear. Architecture does not disappear; it reappears as integration problems when locally reasonable decisions fail to compose into a coherent whole. Verification does not disappear; it reappears late, when test becomes the first place anyone is seriously checking whether the system is understandable, consistent, and defensible. Rework does not disappear either. It simply arrives later, when it is more expensive, more disruptive, and the original context is less fresh and harder to reconstruct.

At this point, it may help to examine what a more complete process actually contains. A useful reference is the Correctness-by-Construction model, which describes a lifecycle made up of distinct development steps and a set of supporting activities that run throughout the project. It is explicitly presented as a flexible process that can be tailored by project nature and criticality, but it still begins from the premise that each step exists for a reason and should be carried out with the most rigorous techniques appropriate to the problem.

In compact form, the process outline looks something like this:

1. Process planning — define what parts of the process will be used, what techniques apply at each stage, and what validation activities will be performed.
2. Requirements — define objectives, system context, required functions, scenarios, and nonfunctional characteristics such as safety, security, reliability, and performance.
3. Software specification — describe what the software must do as a complete black-box behavioral specification, separate from internal structure.
4. High-level design — define the architecture, major structures, interfaces, and the way components work together.
5. Detailed design — add further design detail where architecture and specification are not enough to guide safe implementation directly.
6. Test specifications — derive tests from the specification, requirements, and design rather than improvising verification at the end.
7. Module specifications — define lower-level contracts where the gap between design and code still needs to be closed explicitly.
8. Code — implement from defined artifacts using languages, tools, static analysis, and review appropriate to the project.
9. Building and integration — assemble the system incrementally, regression-test builds, and assess coverage as the system matures.
10. Commissioning and release — configure, deliver, install, and validate the final build in its intended operational context.

That list should not be read as a rigid waterfall recipe; it is only a semi-ordered listing of steps or phases. The source process should be explicit that real projects include overlap, parallelism, incremental builds, and iteration back to earlier deliverables when validation finds faults. High-level design can proceed in parallel with parts of specification, builds can act as test harnesses for later code, and defects found in one place can force corrections in earlier artifacts. The point of the outline is not to deny iteration. It is to show the full set of concerns that must somehow be addressed if a project is to remain coherent.

Just as important are the generic activities that support those steps throughout the lifecycle. In the same process model, these include process planning, staff competence and training, tracing between artifacts, fault management, change management, configuration management, team organization, and metrics collection. These are not extras. They are the disciplines that keep the process from falling apart once change, defects, parallel work, and schedule pressure begin to act on it.

That point is easy to miss because these activities are less visible in presentations than the lifecycle boxes. But in practice, they are often what makes the difference between a process that merely produces documents and one that actually supports engineering control. Traceability matters because it allows a team to understand how requirements are satisfied and what else is affected when something changes. Fault management matters because a serious process does not merely fix a defect where it is found; it looks for the point of introduction, repairs affected deliverables, and tries to learn why that class of defect appeared at all. Change management matters because impact analysis is only credible when the project has enough rigor in its requirements, specifications, and design information to support it. Configuration management matters because all deliverables, not just code, need to remain consistent across baselines. Metrics matter because effort, size, and defect data can show where quality problems are emerging and where the process is performing well or badly.

Correctness-by-Construction is not the only place to look for examples of well-developed software process guidance. Def Stan 00-55 Part 2, IEEE/EIA 12207, and MIL-STD-882E are all useful reference points, even though they differ in scope and emphasis. It is also worth remembering that this is not only a theme in defense and safety material. DSDM, though very different in purpose, is a reminder that even within Agile, there have long been frameworks that preserve roles, lifecycle structure, governance, and the principle that quality is not something to be traded away for speed or convenience.

The same logic appears even at the level of an individual engineering task, which is one reason I still find the Personal Software Process useful. PSP assumes that planning, design, review, defect logging, and postmortem learning are not ornamental steps wrapped around implementation, but part of what makes implementation go well in the first place. A little more thought before coding, a serious review before compile and test, and a habit of tracking where defects were introduced and where they were found all help move discovery earlier, when corrections are cheaper and the work is still easy to understand. That is part of why the broader process argument matters. What helps at the task level often helps at the project level as well. If planning and review reduce confusion for one developer working on one task, then clear requirements, architecture, and early verification usually do the same thing for a team building a system.

Some things can be lightened. Correctness-by-Construction explicitly states that projects may vary in level of rigor, techniques and notations, subsets of activities, amount of design detail, and formality of evaluation. Some straightforward areas may move directly from higher-level artifacts to code. Some projects may justify only informal notation. Some may combine deliverables. Some may use less independent verification or collect less formal evidence. Tailoring is not only useful, but also important.

But tailoring is not the same thing as omission without analysis. If a team drops a specification artifact, it still needs some reliable way to establish a complete and shared understanding of required behavior. If it reduces traceability, it still needs some credible means of impact analysis. If it relaxes review and analysis, it still needs some other way to expose defects before they become expensive. A process step may be shortened, merged, or simplified, but its purpose does not vanish simply because the artifact does.

That is why there are some things I would rarely trim very far. Explicit requirements are one. Architecture is another. Verification planning is another. So are configuration discipline, change control, defect tracking, and enough cross-artifact visibility to support real impact analysis. These things may take lighter forms on small or low-consequence projects, but they remain the structural members of any process that hopes to deserve confidence.

This is also where the balance between rigor and practicality becomes clearer. Practicality is not achieved by removing everything that looks formal. Quite often, rigor is what makes practicality possible. Early validation prevents late confusion. Better structure reduces integration pain. Static analysis and review reduce the burden placed on testing. Metrics and fault analysis make improvement less dependent on intuition. None of that is impractical. On the contrary, it is often the most practical part of the whole process.

A process seems wasteful when it produces evidence no one will use, requires formality that serves no meaningful purpose, or creates duplication that clarifies nothing. But a process becomes dangerous when it removes the steps that define behavior, preserve structural coherence, expose defects early, and keep change under control. The hard problem is not choosing between rigor and practicality as though they were natural opposites. The hard problem is knowing where rigor is carrying real load and where it has become ceremony without substance.

So when I hear the phrase minimum viable process, I don’t take that as a call for weaker process. Instead, it’s a call for deliberate examination. Start with a complete view of the work. Understand what each step is for. Use a stronger reference process than you think you need. Then tailor it deliberately. Shorten what can safely be shortened. Combine what can safely be combined. Reduce rigor where consequence is low and experience justifies it. But do not confuse a thin process with a disciplined one.

A minimum viable process is not the one with the fewest visible activities. It is the leanest one that remains strong enough to preserve clarity, support verification, absorb change, and justify confidence in the result. Finding that balance is the challenge.