What is MVP
In Eric Ries' Silicon Valley Bible, The Lean Start-Up, the idea of Minimum Viable Product first came out. Since then, the MVP has become standard practice for product teams across a variety of sectors, including SaaS, eCommerce, consumer electronics, wearables, and a variety of others.
Image from https://www.dynamicyield.com/glossary/minimum-viable-product/
If you want to make a car, don't make the wheels first, then make the axles, and then make the car shell...In thi way, you can have a car only after all the parts are finally assembled. Instead, you should first build a skateboard, then you can use it for, for example, to carry boxes or other things, then turn the skateboard into a scooter with armrests, and then turn it into bicycle. Then a motorcycle, and finally a car. In this process, you can have "wheels" to run in each step.
Follow the traditional waterfall method, do all the requirements analysis, then all the design modeling, then all the coding implementations, and finally all the tests. You did not dot it that way. Instead, you release the newly developed functions in every iteration, even every day within the iteration. Each small function will go through the whole process of analysis, design, coding, and testing in a 2/3-day cycle. The functions released in each iteration are available in themselves, and the entire system will be available when all functions are completed. So you will officially release the system at the end of the three iterations. After all, how can an incomplete system be used?
The development process is already very agile, isn't it?
Many people can't understand this picture, because they think it is a metaphor, not really from scooters to bicycles to motorcycles to cars. However, the fundamental watershed of agile software development is demonstrated in this image above. Software is soft. A bicycle can really be converted into a motorcycle with an engine, and it will not affect the features of the bicycle even a motorcycle is installed. It can even be more absolute: If your software development is not doing like the way as shown in the screenshot, you are not practicing Agile at all.
During this whole process, the entire business system (not only the IT system) is available at any time, the modification of the business system is controllable and reversible at any time, and the improvement opinions on the business system can be put forward at any time and be included in the following features.
This is iterative delivery: the software system is gradually deployed to the business system in an iterative manner, gradually changing the business system (more digital, more convenient, better experience...), and ensuring that every step of the change to the business system is safe and reliable.
Whether to deploy software systems and change business systems in an iterative manner, or to deploy software systems and change business systems in an all-in-one way, this is the watershed between agile, non-agile, or the fake agile. You can close the door and engage in iterative development. It's fun, but in the end, the software is released in a large bulk, and that is waterfall.
To walk through this watershed, user stories must be more granular. The scope of delivery selected for each iteration must be end-to-end.