I read an article about a year ago in ACM Magazine that I’d like to share with you. It explains how the General Accounting Office (GAO) of the U.S. federal government has asked government IT departments to go Agile.

First of all, who is more conservative than the federal government? And, within the government, who is more conservative than the accountants? When these guys are promoting something, it seems pretty obvious that there must be an economic payback, and, of course, there is.

This article lays out that there are four fundamental assumptions that have driven IT to date:

1. Dependable large IT systems can only be created using a rigorous engineering design process.
2. The key objective of constructing the application is to meet the knowable and collectable requirements.
3. Individuals of sufficient talent and experience can fully grasp the system.
4. The implementation can be completed before its environment changes.

But, the article states, these assumptions have failed us. A rigorous engineering design process takes too long, which causes our development cycles to be longer than the time it takes the environment to change radically. And this means that the knowable, collectable requirements at the beginning of the project do not represent the application that is needed at the end of the lifecycle. The constant change and uncertainty means that individuals cannot know and grasp the entire application at any point in time, because it will change under their feet as they take the time to understand it.

The article authors (including Peter Denning, long-time past President of the ACM), argue that government (and industry, of course) must have application development lifecycles that adapt to their environments.

I found this fascinating when I read it a year ago, and continue to find it so. The article authors do not accept that pre-planned/waterfall lifecycles are better in some cases, they argue that every application, even the largest, should be constructed in an Agile way. While you may not agree with their assessment, it is interesting to see how far the Agile bug has gone once it is being espoused by conservative institutions like ACM Magazine and the GAO.

Photo credit cliff1066 on Flickr

I am widely known as the prince of oversimplifications, but here goes anyway…

I strongly believe there are two major reasons why we should do projects iteratively and incrementally, i.e. in an Agile fashion.

The first reason is that “businesspeople don’t know what they want until they see it.” It is all well and good to show a businessperson a stack of requirements and ask them to sign off on it. But does that allow them to visualize the application? No. They are signing off blindly. Businesspeople (or any people) cannot truly understand a software application until they have seen it working on the screen and have played around with it a bit.

Can you imagine getting a person to understand Twitter without them using it? Reading the use cases for Twitter? It would sound ridiculous! And yet, it’s a good application.

Here is where I often hear people talk about user interface prototypes. If you show a user interface prototype to a businessperson, even though it’s a throwaway and there’s no guts to it, that should work, right? But it seldom does. Prototypes are NOT the real thing. And users get confused. “Are you already done?” they ask. “I’ll take it now,” they say. But it’s just a prototype, it’s not real. You can’t have it now.

If we slice our application development the right way, we don’t have to do user interface prototypes. We can show real, working, tested functionality every iteration. The businesspeople can look at it, play with it, give us feedback, tell us how to improve it. And if the business likes what they see, they can have it now. It’s the real thing.

The second reason we have to create software iteratively and incrementally is that “developers don’t know how to do it until they’ve done it.” I say developers, but we can lump all roles into this one.

My friend Bruce used to tell a story about when he worked at AT&T. This was back when they were truly the phone company monopoly and they had piles of money. He was on a project with them that went pretty well, and after about 10 months they finished the software. When they got to the end, the users and the software team got together and said “You know what? We really could have done this a lot better if we knew then what we know now.” So they did!! They got another big pile of money and started from scratch! They redid the requirements, coded everything again, retested, and gave it to the users. “It was fantastic!” my friend said. Everybody knew the problem to be solved. Everybody understood how to work together.

How nice if all our projects were like the “second time around” project. But they’re not. We don’t have the luxury that the erstwhile monopoly had in those days.

But what we can do is we can iterate. We can shrink our development lifecycle into a very short time, let’s say one week, and we can run through it again and again, learning every time. That way, we are getting the benefits of learning how to work together, how to use the tools, how to reduce the risks, but we don’t have to pay for the project twice.

For me, these are the reasons we build software iteratively and incrementally.

What do you think??

Photo credit SashaW on Flickr

Click here to see the photos from my presentation “The Basics of Agile” at Progressive Medical in Westerville, Ohio last Thursday.