The ten commandments of agile

Blogger Kishore Kumar, who apparently has no direct experience of agile, recently looked at the agile manifesto and its related principles of agile and concluded that agile is ‘the new religion‘ and that the agile principles constitute its twelve commandments.
Over at the Borland Agile Transformation blog, I wrote three blog posts in response to Mr. Kumar’s thoughts on the first ‘commandment’ (see here, here and here).
I thought I would move back to my blog for my thoughts on the second ‘commandment’: Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
Mr. Kishore lists three possible reasons why requirements change late in the process:

  1. The system analysts did a bad job of requirements elicitation,
  2. The business guys do not know their business or do not bother to explain things to the IT guys, or
  3. The business need itself changes frequently (i.e. competitive landscape changes frequently in an unpredictable fashion)

Mr. Kishore comments that while he has seen the first two happen, he has never encountered an example of the third, and spends the rest of his post explaining why.
But let’s look at the first two sources of changing requirements. Based on his wording, I have to assume that Mr. Kishore considers these to be problems with the process. Why should one adopt a methodology to deal with the results of these problems?
It is indeed a problem if, for instance, the business-oriented people don’t adequately communicate customer needs up front. But a conventional waterfall-type project doesn’t have any good mechanism to deal with such screw-ups. If such a SNAFU happens, then your project is delayed while you re-plan and re-work, or you take some other sort of shortcut in order to meet the schedule. As long as each step of the process goes according to plan, you’re good, but as soon as any of them encounters unexpected problems, you’re screwed.
But agile assumes that imperfection, not perfection, is the normal state of affairs. That’s the beauty of agile.