Many a nights before , I was going through this site . http://agilemanifesto.org/ (name sounds familiar , isn’t ?). I was trying to understand the basic concepts behind this “AGILE” thing. The explanation written in this site is pretty concise and to the point.
We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on
the right, we value the items on the left more.
Interestingly , I completely endorse to what have been said above. However , last two lines stand out “That is, while there is value in the items on the right, we value the items on the left more.” Hence Agile never recommends that we should have no documentation in place , no processes in place. I have been faced with lot of criticism regarding Waterfall methodologies. Repeating same words like “we are Agile” does not solve our purpose and it just make us oblivious to the fact that every methodology has its pros and cons and nothing is perfect. One need to understand Waterfall or other methodologies before criticizing them and hence favoring Agile is good but getting obsessed with Agile doesn’t help us stand in good stead. My 2 cents here is if we don’t have a grip on what you are criticizing ,then we will dig ourselves into the same hole we thought we are getting out of. One need to be careful using "People over Process" to prematurely reject a practice.
It is imperative that we understand a basic underlying principle behind Agile rather than making Agile just an excuse of what we don’t want to do. To give an example , Agile manifesto does states that right amount of documentation is required. Being Agile does not mean that the documents like functional specification(user stories alone doesn’t solve the purpose) is necessarily dead – only that it might be short, focus on key architectural decisions which are the cornerstone of a deliverable, and focus on the critical success factors of a piece of functionality. However , Developer tend to use Agile just an excuse to code with no documentation or following no documentation. We need to do what makes sense and what adds business value but no documentation at all DOES NOT make any sense at all.
It is a proven fact that great people with a good flexible process ad tools are always hyper productive.
In my short career spanning 8yrs with companies of varied domains , I have come across the following line many a times :
"No we can't do that, because it's not Agile. This definitely is not Agile".
Following an Agile process religiously (that too being proud of it) even though the current situation or business need doesn’t warrant it, is definitely doesn’t justify us being Agile. If process is the most important thing , above all else , then I guess we need to go back to the agile basics and definitely that’s not AGILE. We need to debunk this myth once for all.
I am not a critic of Agile , however I think that if used in the right context catering to a relevant business need , then it’s great methodology to develop software’s .
Agile is a wonderful thing that has happened to the software industry but let’s not undermine its value by using it as a poor excuse for lack of processes , methods , direction and strategy.