Explaining agile development

We've now moved into the tenth sprint of our agile project. We have an internal release every month with working software but our problem is that we are building the product as a replacement of a product in use. So, our real users cannot switch until the built functionality meets the needs met in the current product.
So our "users" are our internal personnel until we've got enough depth and width to enable users to migrate to the new generation. So, what is "working software" with this kind of project?
Well, our problem is that it means one thing for me, another thing for developers and yet another thing for our staff. For the developers working software is software that meets their individual concept of "working code". For the sales personnel means software they can use during their demos. In case of the former, we have that. In the case of the latter, we don't have that. So, the sales people are waiting for what they see as the first "real" release.
I've more and more come to understand that agile methodology works best with software that is already in actual use: it will be much concrete when we have live software that our users use. Then we can every month decide if the new release has so good quality that it can replace the software the users are using.
Next week, I hope that will be a dream come true. And then I'll probably find the next problem with agile development. Not to say that I ever want to go back. It would be like turning your back on electricity.