I’ve talked about some of the situations where you might have be working on software that has no direct end user- or customer-facing behavior. For instance, let’s say that you work at a company that sells a realtime operating system. The majority of the value that your product delivers to customers is via the API (Application Programming Interface). End user applications of various kinds are built on top of your operating system by software developers at other companies. You and your team have begun to use Scrum for development because…well…it’s always a good idea to use Scrum to do software development. Soon you will run into a very common problem for those in your situation.

You might also be at a company that is early in its Agile transformation, and your team might be working on a component of a large system because your organization hasn't yet implemented Feature Teams.

The problem is, what will you do when it comes time to demo your product increment at your sprint reviews? How will you show that your software is doing something that is by definition invisible to users? How will you make your demo dramatic and compelling? How will you keep your audience from falling asleep without doing extensive development?

Here are a few suggestions:

Your audience might not be able to picture the system context of what they are about to see. There’s a great post about this in the Agile Project Manager blog (http://agile-pm.blogspot.com/). The idea is to create some visuals (I think this is a euphemism for slides) that show the audience what is about to be demonstrated. I recently saw this being done at a client of mine and it worked really well. In fact, I had the impression that the business folks who attended this particular sprint review might not have been there at all without the introductory slides to explain to them what they were about to see.

The next place to look is to your automated acceptance tests (you have them, right?). How long do they take to run, and how do you monitor them? There’s nothing wrong with running your acceptance tests during the demo and let the realtime test results provide the show. Many teams have web pages or other reporting mechanisms that show the success or failure of individual tests. Coupled with some graphics, this can demonstrate your software in a reasonably effective and interesting way.

Does your software run in a production environment? If so, then you must have any number of realtime monitors that tell you not only the basic health of the system, but I bet you also have things that show realtime system parameters and usage data. These are another good way to demo your software feature, and if you don’t have these things, you will become addicted to them if you begin to create them. Use them for demos and for realtime monitoring of your apps in production.

There is always a way to show someone what your software is doing. Be creative.