I think what's impactful about this approach is how it allows a team to share progress and get early feedback from key stakeholders. If you demo to the team that built the software you might get marginal value, but when your leaders are involved, or when key customers are involved, this can be powerful. Demoing a project early is a great way for those with skin in the game to help change course early, or ensure that the deliverables will meet the quality bar they expect before it's too late. It also helps set expectations for how long the average development cycle is, and with tangible progress highly visible, can help ease concerns on timelines and delivery.
This might not make sense at a small company that has few internal stakeholders or that can deliver a feature soup to nuts in a "sprint". In large companies, like Amazon where I work, this is great because the smallest unit of time to deliver any marginally complex new feature or application appears to be somewhere around 3-6 months of effort.
This is a great mechanism for routine check-ins during that time.
It also introduces more entropy as more people may ask for more features or changes on a consistent basis which can impact timelines. Stakeholders seem to ignore the latter.
This might not make sense at a small company that has few internal stakeholders or that can deliver a feature soup to nuts in a "sprint". In large companies, like Amazon where I work, this is great because the smallest unit of time to deliver any marginally complex new feature or application appears to be somewhere around 3-6 months of effort.
This is a great mechanism for routine check-ins during that time.