I'm a fan of agile approaches when they fit your project. But that doesn't mean I never use other approaches to projects.
I often use iterative approaches, when I want to try something and experiment a while. I can start with a small part of the system and iterate on that part until I understand it. If I'm the project manager, I can ask a team of people to do that show me the results.
I like incremental approaches too, where we build a piece of the system and then another piece and then another until we are done. I like seeing the system come together whether I'm using timeboxes or not.
Demos serve two purposes in any project: to see visible progress and to acquire feedback. If you're using a serial lifecycle, build in demos at least every three months. That way, you can't go too long without any feedback about the product, or feedback about the general architecture of the product.
If you use an iterative approach, consider a demo every two-to-four weeks. If you are iterating in longer cycles, your iterations are too long--you are trying to do too many experiments for the time. Break your experiments into smaller chunks, and then demo. (BTW, a strictly iterative lifecycle does not have timeboxes necessarily; you answer questions each iteration and then decide what to do. You want to make sure you don't have too many questions to answer for each iteration.)
With an incremental approach, you're working feature-by-feature, or feature set-by-feature set. I almost had a disastrous program when I used an incremental approach, and let the increments get too big. We waited almost two months for a demo. The project team was so pleased--and the product manager was not. We made our increments smaller and gave more frequent demos.
So, no matter what kind of project you have, consider a demo as part of your project management. You'll see the team's progress, the team will see its progress, and the product manager, sponsor, customer, whomever you've got will see what the team has done. Wins all the way around!
