Agile, not whirlpool, maelstrom or swirl. And rain is comming.

I just wondered why everybody calls the fixed (old) process of developing, the waterfall method and the iterative method agile.
Of course the fixed process looks like a waterfall, but the agile process does suspiciously look a lot like something you could see in water.
Naming it whirlpool would make it sound like a bathtub with bubbles. Sounds like fun, but not exactly the iterative process.
Naming it maelstrom would make it sound like something that drags you down, or at least something you have no control of. That's quite negative.
Naming it swirl would make it sound like something frivolous, something akin to ice cream, maybe.

I think that opponent of agile could start to use on of the above. An agile process can be quite chaotic when done incorrectly so maelstrom seems to match that.

The agile process is in my mind named correctly because it makes the IT reacting to business and users, instead of the IT dictating how it should be. This of course also happened when the waterfall method was used, but was not specified. On the other hand with agile there are things you can not break up in iterations like an MP3 codex, so there are parts that look more like the waterfall process.

It also makes me wonder what the thing after agile may be. Agile really shines with user interface and database heavy applications. Since user interfaces can be customized by users (Webparts, Sharepoint) and databases are becoming more smarter (Linq, data services) what the IT will be doing is providing building blocks of functionality. At least if you agree that an application is made up of UI, data and transformations. This neatly explains the rise of service oriented architectures (SOA), because services are of course building blocks of functionality.

The question is, how will SOA impact the development process? Since services are highly decoupled you could see them as separate applications and thus can have there own process. This is something akin to rain where every droplet has it's own waterfall or whirlpool. On the one hand, to avoid services being chatty they may grow more complex witch could result in a more agile process. On the other hand, and my guess really, is that it will be more like waterfall, because services should have a single and clear purpose.

Most users don't want to customize their UI even if they can. This means that there will always be someone either an IT person with avidity with the business or an business person with avidity with IT that creates and updates the UI. As is happening now with Sharepoint. This person will follow an agile process because he or she will change the UI when the need arises. This person will communicate with the back end IT department about the services he needs. The back end IT department will follow a waterfall like method because each service should be specified, designed and tested, as well as checked for duplicates, documented and cataloged.

So there you have it. Two kinds of processes in the same company, department or even team. This shure sounds like trouble. Hopefully there will be rain.