In honour of the 20 year anniversary of the Agile Manifesto, each monthly blog this year will focus on one of the twelve principles.
"Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage."
There is often some confusion around this principle. Some people point to this and say that requirements can change at anytime and the team just has to adjust (in real-time) to accommodate those changes. That likely wasn't the intent of this principle. Instead, Agile realizes that we can't possibly know all the requirements up-front. If changes are needed then a conversation needs to happen (likely with the Product Owner). The Product Owner can then make decisions based on input from various stakeholders (including the team). For example, the Product Owner may decide to defer the change until the next Sprint. In some cases (and this should be rare), the Product Owner may decide to change the scope of the current Sprint to accommodate the change.
Furthermore, some teams get upset when the requirements change and automatically assume that somebody isn't doing their job very well. Most of the time this isn't the case. Requirements can change for a number of reasons. Sometimes the customer is reacting to external events that they had no control over (e.g. COVID). For some customers, if they don't have this flexibility, it could mean they're out of business.