Skip to main content

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.

Popular posts from this blog

A Corporate Agile 10-point Checklist

I'm pretty sure my few remaining friends in the "small, collocated team agile" community are going to desert me after this, but I actually have a checklist of 10 things to think about if you're a product owner at a big company thinking of trying out some agile today.  Some of these might even apply to you if you're in a smaller place.  So at the risk of inciting an anti-checklist riot (I'm sorry, Pez!), I am putting this out there in case it is helpful to someone else.

Here's what you should think about:

1.Your staffing pattern.  A full agile project requires that you have the full team engaged for the whole duration of the project at the right ratios.  So as you provision the project, check to see whether you can arrange this staffing pattern.  If not, you will encounter risks because of missing people.  Concretely it means that:
a.You need your user experience people (if applicable) and your analysts at the beginning of the project, as always, b…

The Agile Business Case

Many agile teams have never seen a business case, ever, and they may even be proud of it.

Our mantra is that we deliver "business value," not just "software," quicker, better, and faster, but if so, we certainly don't spend a lot of time reporting on value delivery, and in fact we may be scornful about "analysis paralysis."  As software developers, we consider ourselves to be doing quite well if we can deliver the software every two weeks (or continuously).  And this is particularly if we've enabled this frequent high-quality delivery through automated testing and automated build-and-release techniques.  We've reduced business risk by making results visible more often, and allowing the business to change direction more frequently.  We assert that along the way of course we're also delivering value.  But how would we prove it?

I've recently posited that we shouldn't even think of doing agile projects without capturing and recording s…

Requirements Traceability in Agile Software Development

One of the grim proving grounds for the would-be agile business analyst (henceforth "WBABA")  is the "traceability conversation."  Eventually, you will have to have one.  You may have seen one already.  If you haven't, you may want to half-avert your eyes as you read further.  It gets a little brutal.  But if you close them all the way, you can't read.
Dialogue:
WBABA:   ...so in summary, we complete analysis on each story card, and then we support the developers as they build it that same iteration!Corporate Standards Guy:  but how do you do traceability in agile?  You have to have traceability.  It's broadly recognized as an important factor in building rigorous software systems. These software systems permeate our society and we must entrust them with lives of everyday people on a daily basis. [The last two sentences are an actual quotation from the Center of Excellence for Software Traceability website!] WBABA: [cowed silence]Corporate Standards …