Judging from my fifteen-year working experience in design and development, because the industry I have been engaged in in the past ten years is relatively special, the use of agile is also very different from the common agile.
Usually, the industry I work in has very, very high requirements for the completeness of product concepts. Using small version iterations, it is very likely that the second version will find that it will go smoothly, and many things of the first iteration will be overturned (the first iteration of A lot of things need to be overturned and rewritten), and this will happen more and more frequently as the development activity progresses.
In order to solve such a problem, a very large sprint0 will be derived. In this sprint0, it's not actually done in an agile way (but that doesn't really matter).
It may evolve into another scenario. The first version of the product is not done in an agile way, but in a traditional way. The most important thing is to clarify and repeatedly confirm the most essential part of the product (general product Essence and Essence, is a set of interrelated concepts) and architecture (equivalent to the skeleton of the human body), and then in the process of realization, the concept and architecture are continuously refined.
Because the change of concepts is actually relatively slow, the architecture changes a little more, and the implementation changes the most as the situation develops. Therefore, after the first version, basically the concept will not change much, and the structure will not change too much. Most of the time, it is some implementation adjustments, adding functions and function changes. Since then, agile development can be used to greatly improve product development efficiency and product quality.
In other words, the first version cannot be fast, it must be steady and steady, and a good foundation for expansion and improvement must be laid (it is not necessary to think too much, but it is very important to lay a clear foundation); follow-up improvements, etc. A quick-response, quick-release strategy can be developed. The first version map is fast, and subsequent improvements are bound to slow down, or turn the product into a simple stack of technologies, a hodgepodge of pots.