In modern software development circles,
much to-do is given to the concept of Agility.
Being agile: responding to the needs of the
organization/business/customer without hesitation,
reservation and much push-back.
The theory is it will result in a better product,
if you are constantly willing to change for the customers
current whim, fancy or ultimate need.
Wow.
Or should I say, "Bow-wow".
If it seems like the development team,
is being made to jump through hoops, in an unseemly dog-show,
or having to snap to the master's whip ... it is for good reason: they are.
There are obviously reasons that being too agile,
can be bad, not just in software, but in life in general:
1) Noone really wants to be running endless sprints,
in an ever-changing circuit of agility, in a dog show, all the time.
There needs to be slack time, there needs to be defined limits to number of sprints in a release.
2) If everything can change, all the time, you approach friggin' agile (or fr'agile)
and your project will become fragile for lack of stability and focus on the design and structure
(too focused on the features)
3) "Saying, no, leave it alone" is sometimes good for everyone involved.
Without boundaries, projects will invariably "drift".
4) You never get to learn from mistakes, if you are forever tinkering with the outcome.
That's what "release 2.0 is for"
5) You'll end up with a Rube Goldberg machine
6) Good luck maintaining the Rub Goldberg you created, it all sounded good in the requirements stage ....
So, I have mixed feelings about Agile and agility in general, on the one
hand I've seen it work wonders for software productivity and on the
other I've seen software that is "bereft of design" (my own coined phrase)
and no matter who is pontificating about how that
isn't the case, and its solved by pairing programmers together and / or
doing code reviews ... that rarely pans out and most,
if not all agile software should be considered non-production code.
Instrument it correctly, test it intensely with well written test and maybe
it will pass the muster for production, but it still may be very costly to maintain.
You'll need to stop and design, and let your customers know in constant communication
what the impact of the changes coming in are, through a valid Change Management
process (one of the best things of the Capability Maturity Model - CMMI is the Change Management Process)
Only then can you control the agile flexibility
and turn out software that is well thought out, meets the majority of the business need,
and is maintainable over time.
Don't control the change ... and you'll continually take the developers minds off
the software being built and keep them focused on features, that they'll throw together
and patch together just to meet the need.
m.