Iteration Showcases for Backend Systems

Let's say you are in charge of the "services" operation within the IT department of a large enterprise.  You're a government entity, a telecommunications giant, or some other titan of industry.  Other IT organizations have grown up around you in the enterprise over time, and they're writing cute little front-ends that get information from customers to your services, and pass the results back.  They're doing iPods and tablets, and you're still dealing with Cobol.  Your colleagues are all concerned with "cascading style sheets" and "user experience" and color schemes and the like, but you're doing all the grungy, large-scale back-end work that actually causes the money to pour into your organization and keep you all paid.

Image courtesy of http://www.apolloamusements.com

Needless to say, your vast IT cube farm in the sub-basement is not equipped with a foosball table.

Suddenly, one day, you get an edict that your enterprise is going to "go agile!"  A perky trainer, most likely bringing with her stickers, pipe cleaners, and brightly colored balloons, explains that in the brave new world you are entering, you will now be demonstrating your software to your customers every two weeks.  It will be a "feel good" moment for you and for them.

This is where you break it to Ms. Perky that you have no user interface.  There is nothing to show.  If you do your work correctly, calculations no-one sees will now occur differently in some way, and sometime, some system, somewhere, probably running on the experimental browser of someone's 4-year old's Nintendo DS, is going to register that new calculation as an asterisk on the screen.  As ThoughtWorks project management guru Joe Zenovich says, "Backend Stories Make for Unexciting Demos," although of course he goes on to show you what to do about that, as does "Scrumwiz" in How To Demo Your Backend Software Increment.

So fear not, Backend System Vice President!  You too can experience the fun and excitement of agile software development.  There is, indeed, a way for you to structure development "stories" around your work which will be useful to customers, will keep your conversations interesting and can be demonstrated at a biweekly showcase!  Solutions fall into three categories:

1. Pair up.  If your system has one or two main customers, and your teams are dependent on each other, then build and demo the stories together.  Sometimes what happens is that your team is doing "the big Oracle database" and their team is doing the "slick web interface," because you have different skill sets on your teams.  But from a business perspective, you're both producing exactly one experience for your customer--they interact with the screen, the screen interacts with your systems.  The best thing you can do for your customer is show them steady progress on actual software they can use, and that means structuring your work together and doing a joint demo.
2. Create viewable mocks or stubs.  As my rockstar BA colleague @jenny_wong pointed out when I consulted her on this matter, your services do not work in isolation.  if your system serves as the back end to a lot of disparate customers, then you will still need to know what each client system is expecting your back end services to do, from a customer perspective.  This map of usage serves as the basis for the details of the interface between your system and all of its clients.  In this case, for functional automated testing purposes, you will likely need to create an all-purpose "mock" or "stub" which will mimic the front-end behaviors the real systems will give you (for the difference see Martin Fowler's "Mocks Aren't Stubs").  Seeing those tests run can be quite informative and inspiring for customers of the various front-end systems, particularly when accompanied by a powerpoint deck that explains what they are seeing.
3. Just show powerpoint plus log files flashing across the screen.  At worst, you may want to show them a running batch file spitting out status messages at rapid pace to a screen, with some accompanying powerpoint showing progress this week on the architecture compared to progress last week.  Seeing the fast-paced letters fill the screen can produce a small amount of adrenalin in the most weathered front-end system veteran, particularly if this week's messages are different than last week's.

As Mike Cohn, so often the last word on all things scrum, says on his web site, what ties these story-writing and story-demo techniques together is that at the end of the day, you and your team of grungy back end system coders may never see a customer or even daylight, but you are in business because someone calls your service to do something, and someone calls back later to see what happened.  The key to making your work interesting to your funding authorities on a biweekly basis is to bring in the people who are in touch with your front end system or systems, and showing them the return they're getting on their investment.