Agile Software Development

The term “agile” referring to software development processes is sort of a buzzword, but the intentions of those using the above word may in fact remain quite unclear. By this I mean that agile is sometimes used in its most general sense as “quick; nimble or acute”, whereas in other cases it points to a particular method within the agile development framework (which causes a good deal of confusion, as a matter of fact). Here I would like to look at agile development from what I would call its underlying perspective – agile methodology as a software development philosophy, a set of fundamental features determining the prospects cutting through each and every its elements, all the way from the targeted product to team members and their interaction patterns.
Looking at agile software development as a set of philosophical guidelines seem in fact the only possible way to go since it is prompted by its “umbrella term” nature (which, again, is the culprit of the above confusion). Extreme Programming, Scrum, DSDM, Feature Driven Development , and a number of other things all belong to the agile framework. This is a one-way equation: you switch the parts, and you get a completely warped idea of the whole agile concept. If you have previously dealt with, say, XP and the thing did not seem to work out that well for you, it would be unwise to shift your XP pair work frustration randomly at other things. It is a general-to-specific kind of relation.
While outlining the essence of agile software development, the easiest way to go is defining what is not agile, that is by contrasting it with waterfall development on the one hand and sets of chaotic code-and-fix procedures (or cowboy development, if you will) on the other. (Note: I do in fact realize that negative definitions are logically flawed. What I also realize, however, is that these give you an idea and provide certain valuable directions.) In this line, agile methods turn out to be a middle-of-the-road approach. Agile discounts both the rigidity of the former and the patchiness and anarchy of the latter.
So, what is the agile philosophy about anyway? First of all, agile approaches welcome flexibility and allow for changes at any stage of the development process. With agile development, work is done in shorter iterations (weeks rather than months). The focus is thus shifted off long-term planning, hence greater overall adaptability. Secondly, agile methodologies are highly collaborative, which implies that priority is given to face-to-face communication rather than to formalized written interactions. An agile environment is based on trust, motivation and a considerable degree of self-governance. Thirdly, agile development processes are undertaken in close cooperation with the customer and ensure considerable coherence between both the sides. To wrap it all up in a concise way, it is safe to say that the clue to agile software development processes is working software and its continuous delivery.
My final remark is going to touch upon one more crucial aspect, namely the applicability of agile philosophical maxims to a specific software development environment. Agile approaches need agile team members, which, in its own turn, implies having a mindset of a particular sort.