Manage Learn to apply best practices and optimize your operations.

A CIO goes beyond Agile and straight to the drawing board

CIO Niel Nickolaisen's three mottos of software development have served him well over the years. But now, he says, it's time to go beyond Agile.

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.

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.

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.

More from Niel Nickolaisen

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

Dig Deeper on Enterprise application development, DevOps and software agility

Join the conversation


Send me notifications when other members comment.

Please create a username to comment.

What is your organization's unique approach to applying Agile methods?
Mr. Nickolaisen, some comments from another old man who has been doing project management and programming for 30 years. Agile is better than Waterfall in general. Your "beyond Agile" is an improvement on Agile. I would call your hand drawn pictures "Storyboarding". I understand why you would want to prototype ASAP. A couple of hard learned suggestions for your next phase. Storyboarding is fine for the front end user experience but everything beyond that needs to be analyzed by the management/technical team at least at a top level to make sure it is deliverable to the front end. If, for example, you need to return to the user, a list of names with phone numbers, email addresses, physical location etc. and there is no easy way to do this, your front end users will wonder why its taking you so long to actually deliver this data since "it just simple data". Second, while your are working with the front end team, these potential bottlenecks will have to be worked on to unveil what hidden risks have to be dealt with. Third, I've found users have limited time and consider spending it with IT as a lower priority, so you have to use their time judiciously. I have many other suggestions but you get the idea.