Every process you add should pass two tests. They're simple, but most processes fail them.
Test One: The One-Sentence Test
Can you explain the benefit of this process in one sentence?
Not "it's best practice." Not "everyone does it." Not "it's part of the methodology." An actual benefit tied to an actual outcome.
"Code review catches bugs and spreads knowledge across the team." That works. The benefit is clear and real.
"We estimate story points because..." Why? To predict timelines? Do the predictions actually work? To measure velocity? What do you do with that measurement? If you can't connect the process to a clear benefit, the process might not be pulling its weight.
Test Two: The Simplicity Test
Are the instructions simple enough that people will actually follow them?
Complex rules create workarounds. If complying with a process is harder than ignoring it, people will ignore it. They're not being lazy. They're being rational. They're optimizing for getting work done, which is what you hired them to do.
The processes that actually work are the ones that feel obvious. They're lightweight enough that following them is easier than not following them. They're clear enough that people don't have to ask what to do.
When People Don't Follow the Rules
If your team isn't following a process, the first instinct is usually to enforce it harder. Send reminders. Add check-ins. Make it mandatory.
But enforcement is a symptom of bad design. If people don't follow a process, it usually means one of two things: the benefit isn't clear, or the instructions are too complicated.
Don't blame the team. Fix the process. Make the benefit obvious. Make the instructions simpler. If you can't do either, maybe that process doesn't deserve to exist.