It's an anti-pattern to simply not demo any progress until done. If you're doing agile right (loaded statement), the solution is to make sure everyone understands what's being done. If the audience is expecting all demos to show complete products, find a different audience to demo done-but-incomplete work. The idea is to get feedback before you've sunk six months into something that may not meet expectations.
Yeah, I could've been more precise about what I meant by "demo day." In my comment, I was thinking about the broader, often companywide demo days that many companies hold.
I wasn't talking about intra-team demos to, say, product owners.
I totally agree. Having weekly demos where we showcase unfinished features has been, in my experience, one of the main avenues where we have learned of issues / conflicts / problems with those features at exactly the right time where we could still fix them.
Not having demos of incomplete features would just hide the issues until they are released to the final customers, creating a problem you didn't have before, and making it much more complex to solve.
Progress gets quantized. Some quanta are small, easily shown, etc... other quanta are a bit bigger, less easily shown.
There is a similar problem in manufacturing.
Atomic releases.
While making something, there are many subtle tweaks to the BOM. Changes, substitutions, removals, adds.
Upstream people can make a real mess out of all that, and one way to prevent it is to only deliver releases that are resolved and intended for manufacture.
"where is revision 4?"
Doesn't exist, won't get manufactured, etc... "Use Revision 5 plz."
For the case of insuring expectations get aligned, a mock up can be used. Deliberately used to generate a spec.
For all the things that can be atomic like that, it's good practice.
The bigger ones just take time, and aren't shown, until ready for use.