Think Agile Can’t Work With ERP? 7 Common Myths Debunked

James Roberts

Part of the “Agile ERP” series

Agile development is a proven methodology that has been adopted by leading software firms all around the world that have been convinced of the benefits it can deliver. So why is it that I come across so many people who, despite the evidence to the contrary, seem to believe modern application delivery processes like agile and DevOps simply don’t, or can’t, apply to arguably the most critical applications in their business – their enterprise resource planning (ERP) suite?

It’s a topic that’s on my mind a lot at the moment, as I’ve been working with several companies that have seen tremendous benefits following a transition to agile development in their ERP applications.

The fact is that many modern IT organizations are under enormous pressure to deliver business benefits more quickly, and old ways of working simply no longer cut it. I’ve already talked about the benefits and value an agile model can bring to ERP software, so I’m going to take the opposite view here and explain why some of the most common myths and misconceptions regarding agile ERP don’t hold water.

Myth #1: Stability and resilience are key. Agile just adds risk.

ERP systems have been built on stability and resilience, and as such, there’s a common perception that they shouldn’t be changed quickly. This perception is fundamentally driven by the fear (and consequences) of breaking things.

Of course, it’s true that ERP is traditionally regarded as a “system of record,” but in many cases, it’s also the engine that directly enables more visible “systems of engagement,” such as websites and mobile apps. Businesses and their customers are demanding more and more from such systems of engagement, which are constantly changing in response. ERP systems need to move at a corresponding pace if they can continue providing the valuable differentiation that sets a business apart from its peers.

Agile processes and tools enable ERP developers to meet the apparently contradictory requirements for system resilience and rapid change. The smaller, incremental changes seen in agile are actually far less risky to manage and deploy.

Myth #2: Agile can’t provide the compliance, documentation, and approvals we need.

OK, there’s no doubt that certain industry sectors like healthcare or government, require a lot more compliance, governance, and documentation. At first glance, this may seem to be at odds with an agile approach, given that the Agile Manifesto explicitly gives more weight to software than documentation. In reality, that’s not the case.

Agile makes engineering and development processes much more efficient, which means that the right solutions can be delivered more quickly – a beneficial outcome even in regulated industries where specific documentation and compliance are required.

Regardless of mandated processes, you’re more likely to be testing, approving, and documenting things sooner with an agile approach, especially if you embed the right amount of regulation and industry knowledge in the development team. With appropriate processes and automated tooling, compliance might even become simpler and less time-consuming.

This accelerated pace of change also allows organizations to respond more quickly when legislation changes. That’s potentially a commercial advantage and certainly a way to reduce risk.

Myth #3: Waterfall works. There’s no need to reinvent the wheel.

The waterfall methodology – where requirements are fully defined upfront and implemented in one big large chunk – has been the bedrock of many an ERP implementation project, and in many cases, has worked perfectly well. So why change something that everybody is familiar with and is proven to be effective (at least in some cases)?

Well, not to put too fine a point on it, waterfall often doesn’t work. Or at least not as well as it should. Projects are frequently slow and over budget. The long delivery timeline encourages scope creep and at the same time reduces the chance that the final product will meet customer needs. Even the pressure of a single hard cutover deadline can be counterproductive, encouraging deployment of unfinished code to stay on schedule.

Agile can address all of these issues by delivering frequent iterations, clear prioritization, and constant feedback. I’ve seen agile approaches work very well in some huge organizations that run ERP, although it can admittedly take time to get it right.

Myth #4: A hybrid waterfall + agile approach is better.

There is often a reluctance to take steps towards agile without definitive proof that it works: a chicken-and-egg situation. Comfort and familiarity with the kind of fixed-price, pre-budgeted ERP projects I’ve just mentioned can also be a barrier.

One solution in this situation may be to “sample” agile in specific parts of the development process via a “water-agile-fall” approach. Here, the build phase of the project is carried out in iterations while the design phase and full integration testing proceed in the traditional manner. This hybrid approach can be used to retain the familiar upfront planning and budgeting and the downstream testing and release afterward.

It’s a seductive idea: all of the best bits of the two approaches without the downside.

While there will always be outlying examples where this kind of hybrid approach remains most appropriate, in reality it means your business will never appreciate the full value of agile. It should be a temporary solution that provides the evidence to support a full roll-out.

Myth #5: ERP can’t be broken down into smaller chunks.

A key feature of ERP is a large amount of integration between business processes, which may be distributed across different teams and functional areas with limited collaboration. This complex situation often reinforces the idea that agile can’t work.

However, a major success factor in such a situation is a clear understanding of the dependencies across the solution, so that they can be managed effectively, and the focus remains on the required business outcomes.

Part of this understanding comes from a clear view of how teams are structured, so it’s vital to have business and architectural knowledge as part of the solution delivery.

Agile really helps in this situation. Effective backlog management and sprint planning ensure that dependencies between processes and teams can be well-managed. This results in requirements that are implemented in the right order and ensures that solution integrity is maintained.

Myth #6: Agile doesn’t work for greenfield implementations.

It is often said that agile can work in ERP, but not if yours is a greenfield implementation or you’re rolling out a major program of work where there’s just too much to manage.

It’s true that in this case, the project could last many months or even years before a solution is delivered for use in production. But that doesn’t mean that the business should have to wait months before they get their eyes in front of and hands onto what’s being built. That’s a recipe for failure.

In this scenario, agile business managers are integrated into the process from the start so they can act as product owners and constantly steer development and configuration. They also get to see and test what’s been built at an early stage. This avoids the lengthy development of sub-optimal solutions that might be seen in waterfall approaches where the business has no visibility of outcomes until final project delivery.

Myth #7: Agile doesn’t work with outsourced and offshore teams.

In many ERP organizations, teams are distributed and often comprise a mix of outsourced vendors. This can prove a challenge to the adoption of agile due to the perception that communication will be hampered if team members are not in the same room.

The first step in jumping over this hurdle is simply for teams and partners to be open to agile methods. This might already be the case, or it might need some work, but this attitude is becoming commonplace for most vendors since support for agile and similar methods is necessary to remain competitive.

In fact, agile can actually be a benefit in this distributed model. Daily scrums, along with planning and retrospective meetings, ensure that all team members are aligned with the product owner. They understand priorities and dependencies and have constant communication and checkpoints, enabling risks to be managed more effectively. This actually alleviates a key risk of the offshore model: communication breakdown.


Resistance to change is hardly an uncommon phenomenon. It’s understandable that the move to agile will be uncomfortable for some, especially in ERP where it still hasn’t been seen very often.

To make agile work, you need to have the right people with a mix of functional and technical skills, who are open to working in a different way, and can be trusted to do just that. It will take time to adapt, but it can be done!

Although ERP projects are often long and complex, in many cases, the more there is to deliver, the better an agile approach can be. Agile excels in complex systems like ERP, where there are many things that can’t be anticipated, as a method for dealing with the stuff you simply can’t plan.

If you’re interested in agile for ERP ­– or maybe this post has convinced you that it’s worth looking into – take a look at this e-book for some tips to help you get started.

This article originally appeared on the Basis Technologies blog. This adapted version is republished by permission. Basis Technologies is an SAP silver partner.

James Roberts

About James Roberts

James Roberts is chief technology officer at Basis Technologies, responsible for driving product vision, strategy, and direction across the company’s innovative automation portfolio, and for ensuring that the engineering teams deliver world-class solutions. He has 30 years of experience in the software industry and nearly 25 years of SAP expertise working in a multitude of roles at major multinational companies.