To be honest, I never though much of Agile to begin with. By the time that silver bullet was shot, I was already a cynical veteran of the many buzzwords prior. Agile, like many of the other buzz phrases: Service Oriented Architecture, Extreme Programming, Internet Time, Web 2.0, etc; they are all just the endless renaming and up-branding of old and common sense ideas.

No Such Thing

So Agile was never “new” in my mind. What I think is a step forward is that people in the Agile community are starting to agree. I went to a conference this week where one of the speakers bravely proclaimed:

“Responsive devlopment is the new Agile.”

It was actually a really great session and well worth my time, but you have to imagine my inner smirk. Agile likes to pit itself against the “Water Fall” straw man, but the truth of it is that no one really does true water fall and no one really ends up doing “true” agile either. In all software development, you do a mix of trying to predict the problems you will be solving and reacting to the one you find along the way. The magic or secret sauce that software engineers have been trying to solve is a public agreement of method for deciding what is the proper blend and how do you know when you should be reacting and when you should be predicting?

Software isn’t Engineering

The phrase “responsive development” cracked me up. Isn’t all development a response to something? Rarely do people start developing software without a reason. The problem is as an industry, we have a terrible track record of really understanding our reasons, creating solutions that match these reasons, and knowing when our reasoning is wrong.

Software engineering keeps finding itself more as a black art than an engineering practice, but the simple fact is, most of software engineering isn’t really engineering. Engineering is solving problems using existing techniques. Build a bridge, you have thousands of models to learn from. If you wanted software that similar, you could just copy it. The reason we keep building NEW bridges is because the real world doesn’t have Ctrl+C Ctrl+V.

Science is Iteration

Somewhere in the middle of “Agile” and “Water Fall” is “Iterative.” It is an older term, surely not as buzz worthy as “responsive.” The idea of an iteration is borrowed from the Scientific Method. Sometimes in science, you have a good idea of the solution to a problem and you just need a simple test to confirm it.

Other times, the problem space is large and/or complex. You might have several false starts in even defining the problem. The scientific method is a formal process for investigating and acquiring knowledge. Built into the core of the scientific method is the idea that you work in iterations. You start with a well defined goal; test a hypothesis. You plan out the correct amount of work to gather the data. Afterwords, you examine your results. What went right? What went wrong? What did you learn? Now, you start your next iteration.

If this sounds familiar to Software Engineers, it’s because that is how software is really made.

We end up iterating, being “responsive” to the real needs of software development.

Development is Iteration

When you finally put “Agile” vs. “Water Fall” behind you, you find a clearer picture that the “Agile” world is now “inventing”.

Iterations create a natural rhythm that lets a team accomplish work and then take a pause to ask:

• did the work accomplished what we wanted
• is the original goal still appropriate

Anyone who has watched a fun “Science” TV hero like “House” or “MacGyver” already recognizes how this works, but I am glad that all the trendy programmers are finally catching on.