Agile – a brief dissection

The software industry has been fascinated with the world of “Agile” in the last few years. Everyone wants to Scrum. Everyone wants potentially shippable software every few weeks. There are no project managers now, only scrum masters and members – the chicken and the pigs. However, come to think of it, Agile is not new. Only that we have started to accept it as a working development model so recently.

Agility by definition means “quickness of response”. This translates to the ability of software vendors to provide their products or services in determinant ways with faster hops to the market from their test beds. Going back to the question of how old is Agile? I think and believe – Agile always existed, only that software vendors tried to look at their problems on a larger scale earlier and always tried to solve the whole puzzle at once rather than one part at a time. Also, the emergence of internet economy and cloud services meant that what was developed by the software vendor would be seen by the end user very quickly. This also meant better quality control and visibility into the granular aspects of software development. Hence, product themes were broken into product backlogs which were further classified into sprints and accomplished through one or more stories. If we look at this “agility” closely, we would realize that smart groups have always been practicing this philosophy of agility – “do small things well, keeping the larger picture in mind”. That in my understanding is Agile. Breaking larger wooden logs into small pieces and then crafting the smallest pieces of the overall structure before assembling them to form a whole.

“Agile” has another characteristic. Agile is mature and needs maturity. Breaking broader themes into discernible and doable activities is the hardest part of Agile. It is like comparing the thought of moving your house to the act of actually packaging things and moving them physically. The customer requirement of “I want to see a faster login page” translating into specific details of how configuration, code and deployment will change is indeed a tough ask. Execution in the “Agile” philosophy requires maturity from “everyone” on the team. It also translates to the ability of each of the team members to self analyze – Understand how good you are and how well you can achieve a task and in how much time. Pleasing the stakeholders unreasonably is unfortunately unimaginable in Agile. If something can’t happen in 3 weeks, it can’t. The probability of hoping is very less in Agile and the chances of predictability better. Agility is a boon for those who know what exactly needs to be done, how and when….


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s