Alan Atlas on Jun 28, 2009 04:30AM

How to Demo Your Backend Software Increment

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.

Alan Atlas on Apr 20, 2009 08:24AM

I Go Back to College at Rochester Inst. of Technology

Friday, April 17, I spent the day at the Rochester Institute of Technology, and I had a blast. In the morning I held a two hour workshop on the Principles of Scrum. Over lunch I gave a talk titled "Secrets of Scrum Success", and I spent the afternoon talking to a student software engineering group and to various faculty members. It was a terrific day and I want to thank Professor Jim Vallino for making it all possible.

My visit was part of the ViSE - Voices in Software Engineering - program. RIT is interesting in that it has both Computer Science and Software Engineering programs. The SE program focuses a little more on teamwork and practical software engineering issues while the Computer Science program is more about traditional design and programming concerns. So the SE students and faculty are already interested in project management and teamwork. They even have a course in Agile Project Management!

I tried something different with the workshop. It was based around some of the exercises that we do in many Certified Scrum Master courses. Each exercise tries to emphasize and demonstrate one or two scrum concepts in a dramatic and obvious way, and the idea for the workshop was to emphasize a deep and visceral experience of a few basics rather than trying for the more common overview. So we spent a couple of hours exploring self-organization and command-and-control and velocity measurement. As usual, everything took longer than I expected and we didn't get to do everything I wanted, but I think the people that were there took away a good feel for some important underlying principles.

The talk continued that theme by analyzing scrum using the seven principles of Lean software development. At the end, I proposed that the root of why scrum works is contained in these things:

    ?    One-piece flow
    ?    Self-organizing teams
    ?    Tight feedback loops
    ?    Transparency

A video of the talk is available here: Secrets of Scrum Success.

After the talk and workshop, I spent an hour with the students of the RIT Society of Software Engineers, which is the group that sponsored my visit. They're a great bunch of students who are very proud of the differences between them and their Computer Science colleagues. They were very interested in Agile, and many of them had tried scrum when they worked on some large class projects. I really liked their passion and curiosity.

So, all in all, it was a great day. I got to talk about scrum to students, professors, and industry professionals. I had pizza and I was presented with an excellent RIT sweatshirt. I really can't think of any way the day could have been better.