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.

Which software development methodology is right for you?

Over the past few months, I have interacted with many IT leaders in various agile forums. Irrespective of the process maturity in their respective organizations, I have always seen a pattern in all such discussions, which invariably leads to the question "What software development methodology is right for me?"

If we have interacted, you would know my response already...

To me, this is NOT the most important question you should be asking. Before you call any agile consultant, Kanban specialist or a RUP expert (?!$!), I would recommend you find answers to the following questions

1. What are my business objectives?
2. Does my current software development methodology encourage behavior aligned to my business objectives?
3. If not, can it (existing software development methodology) be optimized to align with my business objectives?
4. If yes, Which practices from other software development methodologies can integrated with my existing methodology?

If not, (Must you change to a new software development methodology)

• Which behavioral changes you would like to see in your work force?
• Which software development methodologies encourage such behavior?

Any software development methodology should be looked as a means to an end (achieving your business goals). In my experience, the the most common mistakes IT leaders do, it to incorrectly assume that adoption of a new software methodology is the end in itself. That is a recipe for disaster.

Thoughts? Experiences?

Where Cynics Dare

I read an interesting post on organizational change management by Biju Bhaskar.. adding my 2c..

Many a times, while implementing organizational changes, we overlook the role of cynics. To me, having a cynic (who is equally passionate against the change) in the team helps in the following ways:
1. you get advanced warning on possible failure points
2. You get real time results on the change management process (i.e if you can help the cynic understand the merits of the change during the process..then you are on right track)

But then, the key is to create a conducive environment where even the cyncis 'dare' to stand-up for whatever they believe in. I would rather have bunch of highly opinionated people against the change, over having a set of people who don't have an opinion at all.