There is so much to say for using an agile approach in IT projects. The focus on delivering value, quick adjustments to changes, continuous improvements and the positive effects Agile has on business change, it all makes perfect sense. Throw in the fact that ambiguous business needs and lack of user involvement rank in the top 3 of critical failure factors of ERP implementations* and we should all be asking ourselves: “Why not just go for it?” Speaking with experts on Agile and ERP I found that Agile in combination with ERP still raises a lot of discussion.
There is an incredibly compelling case to be made for utilizing an agile approach in modern IT projects. The unwavering focus on delivering rapid business value, the capacity to make quick pivots in response to market shifts, the culture of continuous improvement, and the positive, stabilizing effects Agile has on organizational change—it all makes perfect sense.
When you layer in the data, the argument becomes undeniable. Year after year, ambiguous business requirements and a distinct lack of active user involvement consistently rank in the top three critical failure factors of enterprise resource planning (ERP) implementations. Agile, by design, solves exactly these two problems through continuous stakeholder feedback and iterative scoping.
So, why isn't every enterprise automatically jumping on board? Why shouldn't we all just ask ourselves: “Why not just go for it?”
The reality is that when you bring Agile and ERP experts into the same room, the conversation quickly shifts from idealistic alignment to heavy, highly debated operational realities. The typical friction sound something like this: ERP traditionalists worry about architecture fragmentation, while Agile advocates push back against rigid, multi-year blueprints.
We really have to look closely, as both arguments possess valid logic:
The Case for Agile: ERP projects are notorious for "watermelon status reporting" (green on the outside, bright red on the inside). Traditional waterfall methods lock requirements in early, leading to systems delivered years later that the business has already outgrown. Agile breaks this cycle by forcing early user interaction, ensuring the software actually matches operational reality, and allowing the organization to digest the massive wave of business change incrementally rather than all at once.
The Case for Waterfall: An ERP is not a standalone mobile app; it is the central nervous system of an enterprise. You cannot easily build a massive, integrated supply chain ledger "one sprint at a time" without an upfront, holistic architectural design. If individual agile teams configure their specific modules in silos without a rigid overarching blueprint, the downstream integration testing usually results in catastrophic failure, leading to massive, expensive technical debt and rework.
Which raises the question how ERP can best be delivered in an agile way. I think that there are different possible scenarios. Agile implementation frameworks are entirely compatible with ERP programmes, provided you reject a one-size-fits-all approach. Instead, organizations must analyze their specific ecosystem and deploy a tailored delivery scenario driven by two critical variables: the urgency of the business case and the complexity of the stakeholder landscape.
Whether a full-fledged Agile approach for development and release of your ERP solution will be the right choice, really depends on a number of factors. If, for example, the business case for the proposed changes is extremely urgent, one may happily trade cost of rework for speedy delivery of functionality. Organisations with the luxury of time but also the challenge of complexity, may choose to take more time to mull over the different design options from a wider perspective first.
Are agile implementation approaches compatible with ERP? Absolutely. But success hinges on architectural governance and context. Do not force a generic textbook agile framework onto a complex enterprise system. Choose your release scenario wisely, align it to your organization's tolerance for rework versus its need for speed, and make sure your delivery methodology fits your unique operational reality.
Sources:
*R. Catersels, R.W. Helms, R. Batenburg, Exploring the gap between the practical and theoretical world of ERP implementations: results of a global survey (2010)