What we do as technical teams needs to have some rules. It's necessary for any group of people who need to work together to have a common frame of reference that gives them an idea of how to interact with one another and what to expect from each other.
But let's not forget that, in many cases, that's all rules are - a framework to get started with. There are the odd few that are a little more material, for example things that deal with regulatory compliance or safety, but generally (in our industry) they're in the minority and they're obvious with a little experience.
It can be easy to get hung up on the wrong stuff with rules and the key is to always think about the why. Why did we make that rule in the first place? What was the reason - the principle - behind the rule? If you know why then you can weigh the rule against the benefit of the action you want to take. For example, we [used to - we're braver now] have a rule that we don't make changes on a Friday. The principles behind this one are risk management and practicality; the weekends are the busiest times for our trading exchange and we have skeleton coverage Saturday and Sunday. Now let's say we've got a really nifty feature finished that we're sure will give us a reasonable revenue uplift over the weekend, but, we just finished it on Friday. So do we just forego the benefits entirely because of change control? The right thing to do is consider the system impact of the release and, if it doesn't change any core components, why not do it? After all, the controlling the risks was what we were after doing in the first place.
My "rule on rules" is to be rigid about the principles behind rules but flexible on the rules themselves, and remember, you shouldn't be in charge of enforcing rules if you don't know when it's best not to!