Tip

A CIO goes beyond Agile and straight to the drawing board

Gather 'round, kids, Old Man Nickolaisen wants to share with you a story from the old days.

    Requires Free Membership to View

Niel Nickolaisen

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):

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.

  • 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

The nightmare continues in HealthCare.gov rollout

Casting off the shackles of legacy systems

Consumer-friendly or enterprise security: What's a CIO to do?

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 nnick@wgu.edu.

This was first published in November 2013

There are Comments. Add yours.

 
TIP: Want to include a code block in your comment? Use <pre> or <code> tags around the desired text. Ex: <code>insert code</code>

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
Sort by: OldestNewest

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

Expert Discussion

TIP: Want to include a code block in your comment? Use <pre> or <code> tags around the desired text. Ex: <code>insert code</code>

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
Sort by: OldestNewest

Disclaimer: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.