Demand changes! How Should organizations respond?

Different agile teams respond to changes in different ways. Some teams adopt the XP process and accept changes in an iteration cycle. These teams allow their customers or product managers to directly introduce changes in an iteration cycle, efficiently replacing a feature in the original development with a new feature requirement.
Some teams adopt the scrum process, that is, changes are not allowed in an iteration cycle. For these teams, once a new feature set is confirmed in an iteration cycle, the new feature set cannot be changed.
In these methods, many teams (no matter which one is used) have succeeded. Therefore, we cannot simply say that agile teams have the same attitude towards changing requirements. However, I think each method has obvious advantages and disadvantages. What is stated in this article is some guiding principles that can be used by the team to determine how they treat changes: Is the change allowed in an iteration cycle?
As far as I know, a major obstacle to building an efficient software development team is that many organizations cannot set priorities and apply them to critical cycles. Although many organizations have established this set of priorities, they also remain unchanged in Agile teams that adopt relatively short iteration cycles. These organizations seem to think of themselves as hospital emergency rooms-new business opportunities often appear without giving them time to prioritize these opportunities. After the priority is determined, the condition has changed and the priority needs to be evaluated again. However, this is not the case most of the time.
Many organizations that are trying to change their priorities do this. Because it is difficult to consider beforehand. For customers or product owners, they often spare no effort to say, "This is a non-essential requirement," and insist that it should be completed in the current iteration. It is difficult to evaluate the new requirement and persuade the customer, so many organizations have adopted the wrong method to bring the demand change into the iteration process. This is an error. It makes me:
Principle 1: Develop the ability to establish and adhere to the priority, so that you can correctly determine whether to let it go into iteration when the demand changes.
Unless your organization does not consider priority in a complete iteration, it is inevitable to introduce changes within the iteration cycle. However, it is not easy to ignore the priority. For customers or product managers, one way to ignore priority is to "practice more ". The more iterations you do without changing the priority, the easier it will be to perform the iteration. However, those who do not care about the exercise will surely ask: how to do each iteration at the beginning? My suggestion is:
 Principle 2:If you cannot ignore the priority in a cycle, shorten the iteration cycle.
This mainly means that if a team does not know how to reject changes beyond an iteration cycle, it is better to shorten the iteration cycle than to let changes enter the current iteration. Some agile methodologies hold that the iteration cycle is suitable for one month. If the iteration cycle is one month, the organization occasionally receives new features two months later. This takes a long time for an active organization. If so, try to shorten the iteration cycle. Now some organizations have shortened the iteration cycle to one week. The purpose of shortening the iteration cycle is not to set a fixed length of time, but to have the opportunity to learn how to stick to the priority (even if it is just a very short time ).
Organizations that are used to sticking to priorities in one week's iteration cycle may be able to stick to priorities in two weeks. Similarly, if two weeks are acceptable, it is also possible to extend the period to one month.
Once an organization remains unchanged in its iteration process, its goal has been reached. What will we do next?
 Principle 3:Good at iterative processes with unchanged operation priorities before expected changes are required.
When organizations are good at rejecting changes beyond the current iteration, they can consider how to view changes. For this problem of changes in an iteration, the XP method is allowed, and the scrum method is not allowed. At this moment, the Organization has a choice ., That is, the project team can draw conclusions.