Why Every Software Project Needs a Minimum Viable Process

The opposite of no process is not heavy process. It's a minimum viable process: the smallest set of agreements, rituals, and documentation that lets a team operate without constant coordination overhead. Without it, teams spend more time negotiating how they work than actually working.

Teams tend to swing between two failures. The first is no process at all, where every decision is renegotiated from scratch and coordination happens by luck and interruption. The second is a reaction to the first: heavy process, layered on after something went wrong, where the ritual outlives the reason it was created and the overhead quietly becomes the work.

We've found that three things cover most teams: a clear definition of done, a shared place for decisions and their rationale, and a weekly rhythm for reviewing progress and adjusting priorities. Everything else is overhead until proven otherwise.

What makes these three enough is that each removes a specific, recurring cost. A definition of done ends the argument about whether something is finished. A written record of decisions ends the re-litigation of settled questions. A weekly rhythm ensures the team corrects course before it has drifted far. Anything past this should have to earn its place.

The rule we use: add process only in response to a problem you have actually felt, never in anticipation of one you imagine. Process added on speculation is pure overhead. Process added to stop a real, repeated pain is the cheapest investment a team can make.