Is Agile really Agile?

Staying updated with technology and industry jargons is like surviving in a dog eat dog world. One such industry jargon is ‘Agile Development Methodology’. It’s been around for a while now but how safe is it to say that you confirm to the methodology and follow all the Agile principles?

From a software developer’s perspective, we’ve come a long way from the dinosaur days of cutting endless pages of code with a ‘heavy-weight’ or no development methodology at all. What’s hard to believe is that those days were just around a decade ago.
Agile principles evolved from this need to make software lighter, faster and more people centric.

I’ll save you the trouble of Googling “Agile” and looking for Wikipedia’s definition by quoting them here:
“Agile software development is a conceptual framework for software engineering that promotes development iterations throughout the life-cycle of the project”

This blog discusses why Agile Methodology is good for your software’s health but how improper use can make it toxic. If any of my opinions seem too biased, they are probably true. :)
But anyone who has read so far probably knows what my rant is all about and for those who don’t, this could be extremely enlightening or more likely, a total waste of time.

“Agile is a beast with a Multiple Personality Disorder.”

What the hell is he talking about?? Well, I call it a beast because of its enormous potential to be effective; however some of its principles are adaptive and should not be implemented too literally.

For example consider Scrum, an agile process to manage and control development work that is widely adopted by the gaming industry. Scrum suggests 15 minutes daily meetings to discuss the progress from the previous day. This could be an excellent way to manage work and timelines of an average size team. However a project running across 2 or more countries with developers working on different modules may not reap the benefits.
Consider Pair Programming, a practice of Extreme Programming (XP) which is also an Agile process. Whoever thought of this concept had a wicked sense of humour. Having two cranky programmers (no offence intended, I can be one at times) breathing over each others necks (and correcting the others code) is no less entertaining than watching Tyson and Holyfield head-butting with no referee.
Fine, that’s a bit over the top especially while there are serious developers who swear by the concept and at this point are seriously swearing at me. There are endless benefits of pair programming when used in the right environment but the question you need to ask is; how do I make it work for Me? And the answer is quite simple.

“Don’t adopt Agile, but let Agile adopt you”

Agile principles work well when the requirements are constantly changing; when frequently delivering an evolving product is essential to satisfy the customer; when business stakeholders are easily accessible for face-face communication; when the measure of success is having a working product that the user has accepted; when teams and developers are self organised.
But in the real world things can be quite different. In some cases large teams of developers may exist; Stakeholders may be located all over the world and won’t be available for frequent communication; Products that are mission critical may not need much user involvement but need to be reliable; and so on. So what happens when this sounds like your environment and you still want to be Agile?

“When the only tool you own is a hammer, every problem begins to resemble a nail.” – Abraham Maslow.

Now he’s quoting famous people but what does he mean? Think about Agile as a toolbox and not as one single tool. Pick only the tools that you need for the job and leave the others alone. In other words, look for the Agile features that are relevant to your systems, adopt the ones that you can mould into your activities and ditch the ones that just don’t fit. The secret is in knowing how agile one needs to be. This link pretty much summarises when to not use agile.

In conclusion, I say go ahead, indulge and be agile. Your systems and activities will only get better and well organised but make sure you know when to stop.