There is a lot truth in saying “rules are meant to be broken”. Also, the trustworthiness begins with trusting someone despite the fact if they already have deserved your trust or not.
Maybe the worst of all is when someone imposes the rules, which are btw meant to be broken, and says: “See, this is exactly what I mean. They have hard time following these rules. How can they be trusted? We should impose more rules!”.
Having rules and other restrictions in software development is a very good thing. Essential difference of having restrictions in Agile environment, compared to a traditional, is the purpose. In Agile, these are meant as part of many feedback loops, and defined by people who want to be reminded of something they want themselves. They are never meant as a tool of enforcing compliance.
Rules are also not defined and agreed upon beforehand, but continuously, after finding out which ones are exactly needed. An experienced Agile team will eventually end-up having huge amount of these implicit, but also explicit rules. An obvious example is usage of code quality tools, which inform developer that a line of code is “invalid” is as soon as it is written. A good practice is to completely fail a build even if only one rule is broken.
Implicit rules are known to most team members, and experienced team members are comfortable in reminding each other that they should be followed for the benefit of everyone.
At the same time, there should always be room to discuss any rule. The moment is usually a retrospective meeting.
An interesting observation is that self-organising teams have more of these rules than traditional teams and love them. At the same time, traditional teams tend to complain even about the basic stuff like choice of code versioning system. Sometimes their complaints are justified. But just as often, they complain because they were simply not involved in decision process.