Agile Manifesto’s second principle: “Welcome changing requirements, even late in development.”
Putting aside impact to budget and timeline with the introduction of change and increasing scope, I’ve found that this approach does not have the same rigour that a traditional PRINCEII/Waterfall methodology has.
Of course there is an overhead attached to the conventional way of managing change, but it forces us to make rigorous risk assessment and perform due dilligence on its impact to the project.
Any change that has not been designed from the beginning tend to incur technical debt, which over time – will extract its costs through performance degradation and other system inefficiencies.
Even changing the type of a field may not be as trivial as you think, especially if integration is involved.
Regardless of which methodology you are using, it pays to be thoughtful about whether the request, and what the impact might be.
Err… ok, but have you done your risk assessment and change impact yet? 😆