--------------------------------------------------------------------
I often wonder what kind of software product/project is a best-fit for Agile development model. While the answer lies somewhere in the product architecture, customer feedback loop, team structure, geographical distribution of teams and various other aspects, I am starting to realize that the "Delivery Channel and Mechanism" will actually provide a good decision box to start the algorithm. "Ends justify the Means" seems very appropriate here.
If your product version (or project) needs to be delivered very frequently, or your product is only hosted (not premised/licensed), you will obviously have some sort of iterative model in place already. Agile would be a no-brainer in such a circumstance.
On the other hand, if you had a 9-12 month long release cycle, would you move to Agile Development? An engineering-only decision will involve some deliberations along the points I mentioned in the first paragraph resulting in a downplay of implications across the rest of the enterprise ecosystem.
There are usually a lot of changes required in the other departments of the enterprise (outside the Engineering teams, let alone the extended enterprise) associated with a move to a frequent delivery model than one can imagine. The problem of having to release, sell/host, service, support, train, invoice etc is the much tougher nut to crack than the act of building the product itself. In other words, Agile development directly and heavily impacts the way rest of the enterprise thinks and acts.
A big bang approach to switch seems to be in-vogue when quick turn-arounds are expected. However, for an enterprise with diverse cultural/technical makeup and multiple geographical boundaries, a gradual adaptive model is probably the only wise choice. I strongly believe that the net goal of "efficient high frequency releases" will be achieved in just about the same timeframe as a big-bang approach, and the gradual transition will cause much less angst amongst the team members. In this hot market an unsatisfied team is a huge cost to pay for. A stepwise change from 9 to 6 to 4 to 3 monthly release (A total of two years) will provide enough time to exercise all the nuts and bolts of the new process.
In conclusion, the choice of agile development model is not that of the engineering organization, but is one that must be driven by the business goals, in response to the needs of the market with full cognizance of the ripple effects across the entire extended enterprise.
