Myth and Truth about Agile software development methodology

The term "Agile" has now become close to a fad than true appreciation. You will see people brag about how "agile" they are in their software development organization. Not only that, I have also seen people use the term "Agile" to activity such as, project planning where no software development is involved at all. But who would counter them? You would be lectured by seasoned consultants by deconstructing word by word and how their method of creating a plan is a true agile process. On the other hand, people who claims to love Agile and live on Agile, will tell you how Agile development is much more superior than "waterfall method". By the way, who will tell them that between the stone age and industrial age, there was iron age and don't compare the industrial age with stone age by skipping the iron age civilization.

With all those, I felt obligated to explain the "Truth" of Agile software development methodology. Let's begin with a simple fact

Agile is for Software Development

Believe it or not, Agile is, and came for the software development. People may tell you otherwise by showing the linguistic deconstruction of noun vs. adjective and prove you that Agile can be used for your apple picking job as well. For the record: I had once done a "Agile snow cleaning" in a winter - just to have fun as I was tired of snow cleaning due to repeated blizzard that threw couple of feet of snow. It was just for a pure fun, no academic purpose was involved in that. But if anyone claims that Agile can be implemented anywhere, then I would argue that you can develop software using "Taekwondo" principles as well. Spinning can be endless.

Agile is not the successor of Waterfall methodology

As I had touched upon at the beginning, prior to Agile, Iterative methods were very successful and effective. Actually, if you ask me what method I would prefer: Agile Scrum or Iterative Rational Unified Process? I would tell you, pick any but be consistent

Agile is not a silver bullet

Business sometimes think that Agile is a silver bullet and solve every problem the business is facing today. Agile is rather a software development methodology that comes into existence to reduce the risk of software development and maximize the business value of software but it is not a panacea. Agile is not free of cost though. The cost includes: risk of loosing big picture of the solution, quicksand for architectural soundness, overemphasizing on working software over long term stability, fading documentation, etc.. Also, Agile demands certain creed without that it is hard, if not impossible, to be successful. Though not all the risks are due to the Agile practice but sometime due to the fact that people use Agile as escape goat. 

Agile needs business people to be involved...fully involved

When business wants the IT to be Agile, they often don't realize that the Agile is not methodology that IT will practice on their own and business will continue their existing operational model. Agile needs business to change or adapt to the Agile development model. Business flocks into Agile to get the fruit of transparency on how it's being cooked in the kitchen but to reap that fruit of Agile, business needs to play their part. It takes two to tango!

SCRUM is not synonymous to Agile

SCRUM is widely popular in the industry over other Agile implementation such as Test Driven Development (TDD), Xtreme Programming (XP), etc. So people who jumped late on the Agile bandwagon sometime confused SCRUM as the Agile process. SCRUM is just one implementation of Agile that has given a framework to manage Agile software development project very effectively. As SCRUM has taken Agile close to the business people (and also other Agile implementation are too technical for non-technical business people to grasp), they have taken the familiarization with Agile through that framework. 

Agile is a philosophy and demands cultural change

The Agile Manifesto talks about the philosophy behind the Agile Software Development methodology. As this doesn't dictates one on how to achieve those principles but this can be with a level of certainty that without changing the culture in the software development, it is impossible to achieve the principles. I have seen instances where business sprinkles the principles of Agile software development on engineering team without emphasizing the underlying cultural change and blames Agile for their failure.