What requirement changes are bad?

There is a blogpost on quora.com dealing with the topic of why some developers in prominent companies think of agile methodology as nonsense. The post concludes that the agile model is only usable for time-critical, short term projects lasting a maximum of six weeks. It is no doubt cohesive and its conclusions are a logical deduction of the occurrences stated therein. However, the problem with the essay is that it reiterates a handful of misconceptions regarding agility. We aim to address these misconceptions one by one in a series of blogposts regarding this topic.

The introduction contains the phrase “changing requirements and other potential bad behavior from the client”. By stating “potential”, the sentence is less stout, fortunately the author is not suggesting explicitly that every requirement change is “bad behavior”. But which changes are bad?

No two changes are alike. The deciding factor is never the change itself, but its origin.

If the change is due to misunderstanding, precipitation, rashness or inadvertence, the change is by all means “bad”. Its main symptoms are the expressions “that was not what I meant/thought” from the business side, and “it wasn’t specified” from the development side.  However the appearance of previously unavailable business information, technical or commercial advancement, discovery of hot new solutions for better customer service constitute reasons for “good” changes.

Agile methodologies strive for eliminating the former changes and advocating and creating the environment and prerequisites for the latter. By leaving behind comprehensive requirement analysis before development start we also dismiss the illusion of the customer being fully capable of specifying in advance what he or she wants and needs. Just as we need to try on a suit before shopping and if it does not fit, we can ask for adjustments in the “finalized product”, software products also have to be “tried on” and adjusted from time to time. This is made possible by early, regular, frequent, value based delivery and feedback collection.