There are some the situations where you might 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 real-time 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.
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. Hopefully it’s a shared component with multiple customers from different systems or applications, but no matter.
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 end users? How will you make your demo dramatic and compelling for your invited guests (you *are* inviting outsiders to your Sprint demo, aren’t you)? How will you keep your audience from falling asleep without doing extensive, wasted work to produce a spiffy demo?
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. At least when they saw the very unexciting demo of hidden software doing invisible things correctly, they could begin to appreciate everything that they just didn’t 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 real-time test results provide the show. Many teams have web pages or other reporting mechanisms that show the success or failure of individual tests and test suites. 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 system monitors that tell you not only the basic health of the system, but I bet you also have things that show real-time system behavioral 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 later for monitoring your apps in production. You might even get a Christmas card from the folks in ops.
The ides is that there is always a way to show someone what your software is doing. Be creative.