Gather 'round, kids, Old Man Nickolaisen wants to share with you a story from the old days. Back then, the state...
of the art for software design and development was to lock a cross-functional team in a room for a few days and have that team create a massive software requirements document. The various parties would then sign off on the requirements, and the software team would get to work -- only to surface months later and proudly present something that they claimed matched the requirements. Everyone else would look at the end product and say that is was nothing like what they required. After the finger-pointing ended, everyone would compromise, and we would eventually end up with something usable.
It was through several rounds of such projects that I defined my three mottos for software development (which I now extend to everything I do):
- No one knows what they want until they see it (so get them something to see, not read, as early as possible).
- As soon as they see it, they will want to change it (so don't build very much before getting it in front of the customers so that you can gather their feedback).
- All big projects fail (so do everything in small chunks).
Years ago, I adopted Agile principles in order to make sure that I was adhering to my three mottos. Please do not think that I am some type of Agile zealot. I am much more interested in the principles behind Agile methods than the methods themselves. We do short, time-boxed iterations. At the end of each iteration, we demonstrate to our customers what we have built. That way, they can see what we have built so that they can give us feedback. And short iterations naturally break large projects into smaller pieces.
For the past few months, I have been thinking about how I can improve the implementation of my mottos. In my quiet moments, I ask myself how I can do a better job of letting my customers see what we are building -- ideally as early as possible. As a result, we have been experimenting with something that I call beyond Agile. So far, it seems to work quite well. This is how it works:
As part of the initial design of an application, we map out and quickly iterate the user experience. By user experience, I mean the flow and navigation of the application. We draw out what customers will do in the application. And I do mean draw. Our starting point is hand-drawn pictures of the functionality. Because we involve our customers in this process, they get to refine the flow and functionality in real-time. A user interface designer attends this session so that he can quickly turn the hand-drawn pictures into a clickable prototype. This prototype represents how the application will function -- once it has some functionality behind it. The important thing is that we get nearly immediate feedback on something customers can see. Once we all agree that we are close, the software development work begins. We use our version of Agile methods for the rest of the project but feel that getting the user experience correct at the very beginning is the best way to start.
We are new to this beyond-Agile approach, but it is already paying off for us. One of our new applications was a bit of a political hot-potato. Various departments claimed ownership and wanted to make sure that we adhered to their standards. Because of the risks, we used this approach. We got the parties together in a room, drew our pictures, argued over the pictures, but pretty quickly homed in on something that everyone could see and like. We turned this into a rapid prototype that our software engineers used as their design document. They simply had to develop the functionality represented by the prototype.
I am sure that others are way ahead of us in using such methods. For us, this is our latest, best way to get things more right the first time.
About the author:
Niel Nickolaisen is CIO at Western Governors University in Salt Lake City. He is a frequent speaker, presenter and writer on IT's dual role: enabling strategy and delivering operational excellence. Write to him at email@example.com.