The Twelve Commandments of Agile – Commandment II

Here is the Second Commandment:

Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.

- Twelve Principles of Agile Software, The Agile Manifesto 

This is the USP of Agile methodologies. This is the single biggest reason Agile methodologies generate the amount of interest they do today. This is the ultimate open cheque to business and boy do they love it!

Ask, and it shall be given you;
seek, and ye shall find;
knock, and it shall be opened unto you;
- Mathew, 7:7

There are many things wrong with this commandment.

Why do requirements change, even late in development? Here are some possible reasons:

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
3. The business need itself changes frequently (i.e. competitive landscape changes frequently in an unpredictable fashion)

I have seen the first two happen often over the years. I have not seen #3 happen, ever!

Consider the Insurance business. For my benefit, list out all the dramatic changes that have taken place in 2008 in the way auto insurance policies are issues and serviced. How many items have you listed down? None? That is the point! Business-driven change is not as frequent as Agile Methodists imagine.

Consider the way the Insurance business works. The way underwriting and rating are done, the way claims are adjudicated does not change by the week or by the month or even by the year. Sure, regulatory changes keep happening round the year but that does not necessitate the creation of a whole new methodology.

Yes, the advent of the Internet did transform all industries to varying degrees but that transformation played out over the last ten years (you can now buy auto insurance over the Internet). Not in weeks or months.

My team implemented a paperless system to help underwrite health insurance applications for a BCBS Association franchisee. The complete underwriting work flow was modeled and implemented in WebSphere Process Server. With four weeks to go for a production release, I was requested to make a series of changes to these work flows. Not because their business changed all of a sudden but because business took a real close look at the system during UAT and found that the business modellers got it all wrong. A clear case of reason #2 above.

Let us now turn the spotlight on the competitive advantage part.

An auto insurance company derives competitive advantage from two factors:

• keeping premiums low
• fast and fair adjudication of claims

Achieving either of these objectives requires broad and deep operational strategies and tactics. These are not advantages that you can derive by changing software requirements at the last minute! Yet, Commandment II claims to harness change for the customer’s competitive advantage! This is really trivializing the term “competitive advantage”.

In the absence of clear requirements and continuous change, what happens to predictability of schedule and cost? As a vendor, I am often bound to fixed price contracts. I like these contract because they foster strong discipline (not only on me but also on the buyer) and strong result-orientation. If I abide by Commandment II, all my fixed price contracts go out the window and I am now licensed to drift!

Agile Analysts?

The most insidious aspect of this commandment is the free license this gives to incompetence and indiscipline. If I can change my mind whenever I want, where is the need to think ahead and articulate my needs clearly and coherently? Putting it differently, this is really the dumbing down of the requirements elicitation process.

Let me revist my earlier example of the construction of an insurance policy admin system: 

Assume, for example, that my customer never told me that a cancelled policy can be reinstated (and I never asked him either). A week before production release (during the final stages of user acceptance tests) he tells me “you guys have missed reinstatement. I need that also”. An Agile Methodist will say “No problem. I will give it to you” but even he will be forced to change the roll out date. Moreover is there really a competitive advantage at stake here? Should such behaviour be encouraged in the name of agility?

Once again, this commandment is rooted in the dot com mindset. Most people did not know what the Internet could do and were experimenting – “Just get something out on the web site and keep changing it until your customers like it.” Most times, it was not even clear who the customers were. So, the reasoning was “Just get something out on the web site and keep changing it until someone likes it!”

Are we still in the dot com era?

Check out this example of an Agile project manager who too this commandment too seriously and got into trouble: Agile: Anatomy of a failed project