“Agile” is over-used and abused these days. It’s practically assumed that every person, team, and company, ought to strive to be “more Agile”.
But why? What if “Agile” isn’t a good goal for every situation?
Some aspects of the Manifesto for Agile Software Development probably make sense in all situations. I’d be hard pressed to think of a time when we should prioritize processes and tools over individuals and interactions, for example.
But the last of the values, and some of the principles make certain assumptions about the type of business we’re in, and these assumptions won’t be universally true. The two most poignant examples are:
[W]e have come to value … Responding to change over following a plan
Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
I think this is where the core idea of “agility” comes from: The ability to quickly and effectively respond to changes in requirements.
But what if you’re in a business where you honestly know all the requirements up front? Or where you honestly do not need to respond quickly to change?
What kind of organization would possibly create software under these circumstances?
- Perhaps your business has no competition, so you can safely rest on your laurels.
- Perhaps you work for a project with specs mandated by government regulations.
- Perhaps you’re working on a short-term project that will never be used a second time.
What other examples can you think of where agility, the ability to respond to change in requirements, is unnecessary or even unwanted?
