If the business needs IT every time they change a business rule then the business will become the opposite of agile. This is why it is important for a Business Analyst (BA) to capture business rules independent of the business and functional requirements.
Because business rules are a goldmine for Business stakeholders when looking for the best ways to ensure that IT create an agile software system.
If each business rule is designed to be configurable without changing the core system, business leaders can quickly adapt software systems to changing environmental factors within days instead of months.
I have been on many projects where business rules were document by BAs in order to develop a supporting IT system, but then they were not leveraged by the business teams who created them to dictate to the software engineers the minimum requirements that must be part of the front-end administration of the system.
My recommendation is for business teams to keep a catalog of business rules independent from IT. This catalog can then be evaluated against multiple variables including how often they need to be changed.
Once the business implements this type of rigor with their business rules, then they will be in a much better position to enforce agility as a non-functional requirement in the software engineering life cycle.