Monday, August 29, 2011

Myths of agility

In the context of Software development, the term “agility” is widely misunderstood. Even many seasoned software engineers associate agility with complex process changes to adopt ‘Agile’ methods such as XP, SCRUM, DSDM, FDD and Crystal etc. But in reality, this specious association can’t be any farther from the truth. Before you join the ‘Agile’ bandwagon and start reading a XP or SCRUM book, it is essential for you to understand the fine line between ‘Agile methods’ and being ‘agile’.

Being ‘agile’ is a state where your organization is completely adaptive to changing environment. You are driven by business value. Your entire infrastructure, not just IT department but also other business functions such as sales, marketing, finance, production, procurement etc look to maximize the business value generated for the organizations. All it requires certain level of maturity in the way you work, nothing else matters. In the context of Software development, you can adopt any methodology you like (yes, even waterfall, RUP) as long as you focus on a) maximizing “Business value” instead of “through-put” b) being “Adaptive” instead of being “Predictive” c) and Continuous sustainable improvement. All that ‘Agile’ methods do, is to enable some of the aforesaid attributes a bit more than any other traditional methods (such as Waterfall, RUP etc).

Looking from a holistic perspective, being agile is the end goal of all organization and adopting an ‘Agile’ method (for that matter any other software development method) is just a mean to achieve the end goal. However it’s unfortunate to see many organizations blindly adopt XP or Scrum process without giving sufficient thoughts to the values required to make an organization truly agile. It is, therefore obvious that such changes fail over long run.

If you care for being agile, have a look at the Principles behind agile methods. Have a open discussion within your team to determine what each principle means to you as a group. Look at your existing processes and see if they adhere to these principles (fully or partially). Start working on those processes which needs refinement. Change if you must, but only after fully grasping what change means to the overall organization. Rest assured you will ensure a successful and sustainable process change towards being truly agile.

No comments: