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

Trackback URI | Comments RSS