Process has a place. When you're building software for airplanes or medical devices, rigorous process saves lives. When you're coordinating dozens of people across time zones, some structure is necessary. When compliance requires documentation, you document.
But process is medicine, not vitamins. You take medicine to treat a specific problem. You don't take it because it's generally good for you. And you definitely don't keep taking it after the problem is solved.
The Overdose
Most teams are overdosing on process. They adopted stand-ups because that's what you do. They use story points because that's what the methodology says. They have retrospectives every two weeks because someone read it in a book.
Not because these things solve problems they actually have. But because they seem professional. Because everyone else does them. Because more process feels safer than less.
The Right Prescription
The right question isn't "what process should we add?" It's "what's the minimum process we need to solve our actual problems?"
Start with almost nothing. A shared list of what needs to be done and a way to talk to each other. That's it. Then pay attention. When something goes wrong — a deadline is missed, work is duplicated, someone is blocked — ask whether a process would prevent it. If yes, add the smallest possible process that addresses the specific problem.
And here's the crucial part: treat every process as an experiment. Check in after a month. Is it helping? If not, remove it. No guilt. No "but we already set it up." If it's not solving a problem, it's creating one.
The One-Sentence Test
Here's a simple test: can you explain why a process exists in one sentence? Not "it's best practice." Not "everyone does it." An actual reason tied to an actual problem.
"We do code review because it catches bugs and spreads knowledge." That passes.
"We have a daily stand-up because... that's what agile teams do." That doesn't.
If you can't explain it, it probably shouldn't exist.