No two software teams are exactly the same. No two products are exactly the same either. The differences in domain, consequence, scale, regulation, architecture, and team experience are too expansive for anyone to seriously believe that one process should fit all of them equally well.

But in many organizations, that leaves process to preference rather than evidence. Teams are allowed to shape process through local adjustments, imported methods, renamed ceremonies, and half-measured experiments. That can feel adaptive. It can also leave the organization with a great deal of motion and very little accumulated knowledge.

One of the more unusual tendencies in software is to conflate method change with method improvement. If too many things change at once, and too little is remembered clearly, it becomes hard to say what actually improved and what merely changed shape.

The recurring concerns of software engineering do not disappear from one method to the next; they are addressed in different ways. That suggests process improvement should be managed less as conversion to a single doctrine and more as the evolution of a portfolio of practices, shaped by evidence, context, and retained experience.

This is not an argument for process relativism. Different methods may package the work differently, emphasize different artifacts, and impose different rhythms on the team, but the underlying engineering concerns remain familiar. Requirements still have to be understood. Architecture still has to preserve coherence. Verification still has to reduce uncertainty. Change still has to be controlled. Configuration still has to remain consistent. Faults still have to be understood and managed.

That is very much in line with fuller reference-process thinking such as the Correctness-by-Construction lifecycle, discussed in Minimum Viable Process: Balancing Rigor and Practicality. In that view, process planning, requirements, specification, design, test definition, integration, fault management, change management, configuration management, and metrics are not optional refinements. They are necessary parts of the work.

That continuity matters because the conversation about software practices so often focuses on the surface form of a practice rather than the engineering function it serves. One approach looks lighter, another more rigorous, another more collaborative, another more governed. Those differences are real, but they can obscure the fact that many named methods are addressing the same concerns in different ways.  This is also where some of the older software-engineering literature has more to offer than the anti-process thinking that has been prevalent in recent years.

In Improve Software Quality by Reusing Knowledge and Experience, Victor Basili and Gianluigi Caldiera describe the Quality Improvement Paradigm as a cycle in which organizations characterize their environment, set goals, choose and execute processes, analyze the results, and then package the experience for future reuse. That model remains strikingly current. It is much closer to a portfolio view of process than to the usual conversion story in which teams adopt a method, declare success, and move on.

A portfolio of practices is not meant to be a random collection of favorite methods or a shelf full of process fragments gathered from conference talks and consulting decks.  It is an organized body of working practices that an organization has adopted, tested, adapted, retained, retired, or identified for trial over time.  Some become durable because they repeatedly prove useful. Others remain contextual, helping certain teams, products, or phases of work more than others. Still others are experimental, introduced because there is reason to think they may improve some part of the work, but not yet trusted enough to be treated as settled. Basili's experience-based improvement model supports exactly this kind of cumulative learning rather than episodic reinvention.

That way of thinking shifts process away from identity and back toward inquiry. A practice is no longer defended primarily because it is current, fashionable, or associated with a tribe. It becomes something closer to a hypothesis. If we work this way, will estimation improve? Will verification become more informative? Will defects escape less often? Will rework move earlier, when it is still cheaper and easier to understand? Those are engineering questions, and they are close in spirit to the Goal-Question-Metric and Quality Improvement Paradigm work associated with Basili's empirical approach to software engineering.

This is where the model of scientific method is (ideally) applied. An organization identifies a problem or uncertainty. It introduces a practice for a reason. It observes what happens. It interprets the result cautiously. Then, if it has value (or if it doesn’t), it preserves what was learned so the next decision doesn’t begin in ignorance. That isn’t a perfect analogy, and software organizations rarely get anything like laboratory conditions. Even so, it is a better model than method tribalism or institutional amnesia. Basili's broader body of work on empirical software engineering and reusable experience points in exactly this direction, as do later descriptions of the Experience Factory model for turning project experience into organizational knowledge.

The difficulty, of course, is that this is easier to describe than to do well. Improvement is often felt before it is understood. Organizations are good at recognizing that a practice feels better aligned, more orderly, or less frustrating. They are much worse at determining whether it has improved the work in ways that will hold up over time.

The research literature gives good reason for caution here. In Evaluation and Measurement of Software Process Improvement, Michael Unterkalmsteiner and colleagues note that many SPI evaluations are weakened by poor treatment of confounding factors and inadequate description of evaluation context. They also found that pre-post comparison was the most common evaluation strategy, while longer-horizon measures such as customer satisfaction and return on investment were less common. That is a useful warning against declaring process success on the basis of thin or short-horizon evidence.

A similar caution appears in Controlled Experimentation in Continuous Experimentation: Knowledge and Challenges. Florian Auer and his coauthors identify not just technical issues, but cultural, organizational, statistical, ethical, and domain-specific challenges that complicate serious experimentation in software settings. Treating process change as something to be learned from does not mean clean learning is easy. This difficulty needs to be reckoned with, not buried.

If we fail to deal with the difficulty adequately, the portfolio idea can become an excuse for churn. A team may change several practices at once, keep only rough notes, watch a few numbers move ambiguously, and treat the result as learning. Another may keep a running list of tools and rituals it has tried, mistake that list for institutional memory, and call the result continuous improvement. In both cases, the appearance of discipline outruns the substance. Process language, metrics, and experimentation can all create that illusion when they are used carelessly.

This is why the distinction between engineering purpose and form of practice matters so much. The purpose of a practice is not simply to create artifacts or satisfy a process model. It is to create a basis for justified confidence in the system: confidence that requirements are understood well enough to build and verify against, that the architecture remains coherent as the system evolves, that verification reduces uncertainty rather than merely producing activity, and that changes can be made without losing control of what the system is becoming. That assurance benefit is the real point. The practice forms may vary, but the need for some credible basis of confidence does not.

There are many valid ways to achieve the desired assurance. One organization may rely heavily on modeling. Another may use more textual specifications. Reviews may be formal inspections in one setting and structured peer review in another. Planning may be framed around iterations, flow, milestones, or staged deliveries. Verification may lean more heavily on requirements-based testing, model analysis, static analysis, simulation, or some mix of these. None of these is inherently wrong.  Some variations and combinations will fit better than others in particular environments.  Whatever forms are chosen, together they should preserve the required level of assurance.

 A healthy portfolio is neither rigid nor shapeless. It has a stable center and an adaptive edge. The stable center consists of the engineering concerns the organization knows it must continue to satisfy. The adaptive edge consists of the practices, techniques, and method variants through which it tries to satisfy them better. That distinction does not solve every problem, but it does answer one of the strongest objections to this whole line of thought. A portfolio is not a license to keep everything in play forever. It is a way of managing change in the organization’s body of practices without losing sight of what is actually non-negotiable.

The harder question is how a thoughtful organization should manage and evolve its portfolio in practice. That is not exactly the same as tailoring the active process for a particular team or product. The portfolio is broader than the current process. It includes practices in use, practices retained for some contexts and not others, practices identified for trial, and practices set aside with lessons attached to them. The question here is how changes to that body of practices should be introduced, evaluated, retained, or retired over time.

When a team does change its active process, I do not think the answer is one fixed scale of change. In some environments, especially those with historically weak discipline, broader corrective moves may be justified. In others, the better approach may be to replace one piece at a time and watch the result. The important question is not always how much changed. It is whether the organization held enough of the surrounding conditions still to learn something interpretable afterward. That emphasis on baselines and iterative checking is very much in line with current DORA guidance.

Measurement becomes necessary at that point, but it should be kept in proportion.  The point is not to force every detail of the change into a spreadsheet narrative, but to determine whether the claimed benefit has shown up anywhere one would reasonably expect to see it. DORA’s software delivery performance metrics are useful here precisely because they treat measurement as part of an improvement loop. The guide recommends that teams set a baseline, identify friction points, commit to an improvement, turn that into a plan with more specific measures where helpful, check progress, and repeat. It also warns against setting metrics as blunt goals, making disparate comparisons, or measuring at the expense of actual improvement.

DORA documentation is explicit that context matters. Its guidance warns these metrics are best suited to one application or service at a time and also that blending metrics across unlike teams or systems can be misleading.  If an organization wants cumulative learning, the details are critical: what practice was tried, under what conditions, during what phase of work, with what surrounding disciplines already in place, and against what baseline.  Without these details, any lesson will be incomplete at best, and potentially misleading.

A failed experiment is not wasted if the failure is understood. In some ways, that is one of the clearest signs that an organization is thinking well. It tried a practice for a reason, found that the expected benefit did not appear, recognized the conditions under which it failed, and kept the lesson. That is much more valuable than quietly dropping the practice, forgetting why it seemed promising in the first place, and rediscovering the same disappointment two years later under a different name. Basili's experience-reuse model and the broader literature on learning organizations point toward this more cumulative view of improvement.

A likely objection is that most organizations are not capable of this level of discipline.  In some cases the objection is validity, but that doesn’t mean the capability is unattainable. Many teams do not have stable baselines, meaningful metrics, or leadership that is patient enough to evaluate process changes with much confidence. But I don't think that means what skeptics often want it to mean. It doesn't mean they shouldn't do this.  Instead, it is evidence that process improvement should be treated with more gravitas than it usually receives in these environments. That is one of the deeper implications of both Basili's work and the SPI literature: learning from process is hard, but the answer is not to stop trying to learn.

In high-assurance or heavily regulated work, the room for variation is narrower. Some disciplines are not optional, and pretending otherwise usually means the same concerns return later as confusion, weak evidence, integration problems, or expensive rework. That does not refute the portfolio idea. It means the portfolio has to be organized around obligations that are non-negotiable.

An organization that learns this way begins to acquire something more valuable than a current process manual. It develops a body of local engineering knowledge: which practices tend to improve estimation under its conditions, which review habits surface misunderstandings early enough to matter, which verification approaches genuinely increase confidence, which management rituals add noise, which simplifications are safe, and which apparently minor omissions have a habit of creating trouble later. Over time, that accumulated knowledge becomes part of the organization’s capability. Basili and Caldiera were making essentially that point decades ago when they argued for experience factories and for packaging knowledge so that it could be reused rather than lost.

That is one reason the portfolio idea seems more useful to me than the search for a perfect method. The search for one right method tends to invite conversion language. The portfolio idea invites something more realistic: judgment, patience, comparison, and retained experience. It acknowledges the constant pressure to adapt, and also gives the organization a documented body of experience it can preserve, extend, and learn from.

References