If you work on an agile project and you happily churn out functionality iteration after iteration, you should read Alistair Cockburn’s “Are iterations hazardous to your project?” if you haven’t already. His point is, unless you deploy the code after each iteration to real people who will actually use the new features, you are just fooling yourself. Your project may be indistinguishable from a waterfall project, except for the iterative planning window. As a side note, see “Waterscrum vs. Scrummerfall.”
But what do you do if your users don’t want a new version every month? What if you are replacing a legacy system? Then the value of the new system will be zero until the day it is superior to the old one. Or what if your customers are so paranoid about change that they need 6 months just to verify your new version? Kevin Brennan goes into some more detail about such problems here.
Following Cockburn’s reasoning, perhaps you need to run multiple-month iterations in those cases. Although I would say that the monthly planning window has other benefits, so I don’t think I would go much longer than that. But I think the point is that it is hard to be agile under such circumstances.
It seems that the key to breaking this dilemma is to convince at least one of your customers to be a pilot user, agreeing to actually try the new system with some real life tasks, even if he relies on the legacy system for most of his work. Many users are willing to do this after attending a successful demo where some really nifty features are shown.
The worst thing we can do is denying enthusiastic users an iteration release, for whatever reason. Those users are the key that enables our agile development operation.