Clinton provided some feedback to the prior post so I'll reply here and will continue to explore the question aloud.
Clinton Jones said:
Out of the gates I would say that Agile and scrum are NOT a good approach for over-arching ERP and CRM implementation HOWEVER it is a good approach for Business Warehouse/Data Warehousing (in fact almost unavoidable) and is also probably not a bad fit for UI development for ERP systems however if you need to set up the standard modules and fundamental ERP functionality it is almost impossible to do this without going through a standard waterfall approach.
I suppose what I'd point out, and perhaps what Clinton refers to, is that ERP implementations require significant analysis on business processes as they relate to the package's implementation of a particular requirement/module. This isn't necessarily the output normally associated with agile/scrum sprints (thinking while writing: is this really something that scrum/agile discourages though?). I submit that you need to do significant analysis when building custom applications too: even if you're using agile. Perhaps not to decide how to use (or not to use) existing functionality but so that you don't end up with a mess that doesn't fit together, doesn't perform well, doesn't provide production/management support, doesn't scale, ya-da-ya-da. I'd also say that BI and UI development are not the only places where scrum/agile have proven their worth. Bennie and I both come from a commercial software architecture (tier 1 supply chain) space where scrum has by many accounts made a positive difference.
I say it often, and true – I believe: the business of doing (core) business is generally the same. But, the package you decide on certainly has its own realities, lest there'd be only one. Ok, don't point out that Oracle SCM; for instance, is the "one" as this would certainly turn into a religious debate (Dynamics AX ;-)) and that's not the intent of the conversation. If you invest in a canned package you should have made that decision based on the fact that some percent of your business processes can be facilitated by that package out-of-the-box so-to-speak. Does this make implementations more difficult? Not inherently. Does this affect the decision to use agile/scrum for these type of projects categorically? I've not come to that conclusion yet.
I'm not willing to assert that a waterfall approach is always necessary. Ok – let me get out in front of the next obvious rebuttal: there are significant costs associated with specialized skills such as ERP consultants (or FTEs) and implementations – so defining what is to be solved when and estimating the cost of doing so is of critical importance to the folks signing the checks. Right!? Scrum, however, does not impose that you don't provide a plan including cost estimates. Nor does it edict that baselining and tracking actuals against the plan isn't done. The value or accuracy of the estimate, however, certainly comes down to the experience the consulting or internal organization doing the planning/implementation. Not to mention the ability (or investment) by the client to provide enough detail, in some cases, to derive a solid estimate. But these reality don't change with the adoption of either project management approach.
In addition, many (no the vast majority) of these projects, though primarily implementation, also derive some custom requirements: be they out-of-the-box customizations (supported), bolt-on or invasive, UI, BI or integration (for instance). So to this point: those custom requirements could and should be done, in many cases, using scrum/agile project management techniques. Follow-up: experienced ERP/CRM consultants should warn (no scream) against invasive changes as rev-locking the organization, as a result, is a significant problem.
But to bring it back: does the fact that the output of each iteration, say if it were early and often, is in some cases analysis and in others some partial implementation through the life of the project a bad approach toward driving through your requirements? I don't think so. Is embracing change and other agile principles as important in an implementation project? It feels like – yes: why not?
So there's risk associated with painting yourself into a corner, not exclusively, for expensive canned package. However providing a Dev Sandbox environment should reduce the need to hit a home run at each iteration and provides a way of iteratively tracking towards an end deliverable as in the case of custom app dev. So, why can't agile's inspect and adapt techniques be applied given this?
I believe I'm leaning here. But I continue to pose the question: is agile/scrum a good fit for ERP or CRM implementation projects?