Can you run an ERP implementation the Agile way?

Flexibility where it accelerates. Rigidity where a mistake costs too much.

This is not the first time in my career that the applicability of agile methods to ERP has come up for debate. The question looks simple and predictable. It has no single answer.

Let me define the subject. By ERP-led transformation I mean a core-ERP implementation that simultaneously redesigns end-to-end business processes, the operating model, organizational roles and data models, while the new system replaces a significant part of the legacy estate. The typical scale is a group of 10,000 employees or more, although headcount is not the point.

A transformation program differs from a conventional IT project - building or rolling out a business application - in three fundamental ways.

First. The share of organizational and process change that has to accompany go-live and adoption. In a transformation there is not merely a lot of it: it is a critical, often blocking, success factor.

Second. The shift to integrated end-to-end processes and a step change in how functions work across boundaries. Sooner or later the operational efficiency of a single function hits its internal ceiling, and further value for the enterprise can only be released by improving cross-functional collaboration and unblocking the bottlenecks that sit between functions.

Third. Transformation means implementing ERP from zero. This is not about extending or rolling out an ERP that is already live: there, the applicability of agile approaches works differently, and that is a separate conversation.

There is surprisingly little published on the subject, and what exists is written with an interest. The consultancy sells a methodology, the vendor sells licenses, the practitioner sees no flexibility beyond the technical streams. An honest account from someone who was accountable for a go-live on 1 January is not something I was able to find. So I will write one.

What the public record actually says

The consultancy. In "Agile in enterprise resource planning: A myth no more" (2019), McKinsey states that the incompatibility of Agile and ERP is a myth. The methodology only needs adapting, and the results are measurably better: in the experience they describe, roughly 10 percent off program cost, 20 percent added to its value, three times more work per unit of time.

The vendor. SAP positions Activate as a combination of best practices, guided configuration and agile methods. The methodology itself is sequential: Discover, Prepare, Explore, Realize, Deploy, Run, governed through quality gates. Early on, SAP requires the strategic scope, roles, accountabilities and governance to be defined, and in the Business Innovation Framework material agile methods are given the role of a fast test bed for innovation scenarios rather than a way of running the program.

Practitioner one. In a well-known case study, the team at Severstal describes an Agile mix (SAFe, Nexus, Scrum) on an S/4HANA program: 13 teams, more than 1,900 people, three-month increments made of four three-week sprints. The first phase, conceptual design, was run explicitly as classic waterfall.

Practitioner two. Juan Pablo Franco, who has led three implementations (S/4HANA, Oracle Fusion, Dynamics 365), reports that when clients asked to run the project Agile, certified SAP, Oracle and Microsoft partners "consistently said no", because their methodologies - Activate, OUM, Sure Step - are closer to waterfall. He allows Agile in specific streams: integrations, data cleansing and migration, warehousing, custom development.

The research. Gren, Wong and Kristoffersson (2019) studied 21 ERP implementations across 20 companies. The sample matters: this is not a study of Agile versus waterfall effectiveness. The authors deliberately looked at successful projects sitting near the boundary between the two approaches, searching for factors that would let you predict the choice of method in advance. They found almost none: on complexity, requirements uncertainty and other characteristics, agile and plan-driven projects did not differ significantly. Two differences stood out: the agile group had stronger executive buy-in for process change, and a stronger priority on low cost. The authors conclude that choosing a method early, without knowing the context, is difficult.

Point 1. Agile accelerates delivery in individual streams. It does not make hard organizational decisions

Look at what exactly McKinsey proposes to adapt: team composition, sprint length, ceremonies, the program office, test automation. All of it is product delivery mechanics. Not one item addresses what actually blocks a transformation: organizational decisions and cross-functional conflict. Who gives way in the argument between procurement and finance over the analytics structure? Which function sacrifices its own KPIs for an end-to-end process? Questions like these are not settled in a sprint retrospective. They are settled by the position of the executive team.

The study of 21 implementations does not prove that method is irrelevant. It shows something else: one of the few factors that separated agile projects from plan-driven ones was executive involvement in changing processes. That matches the practice of large transformations closely.

Point 2. "Adapted Agile" is a hybrid that no one wants to call one

First, the term. Agile in the strict sense means variable scope with fixed time and team, a minimum viable product instead of full coverage, the right to change requirements at any moment, and teams self-organizing around the customer's priorities. That is the sense people have in mind when they say "implement it flexibly".

McKinsey does describe genuine agile delivery: two to three week sprints, cross-functional teams with business product owners, incremental delivery, regular end-to-end and acceptance testing, several deployment waves. But at the same time: the entire scope is defined up front, at a high level, with success criteria, "unlike the usual agile approach to an MVP"; there is more architecture and process work than agile normally carries; the end-to-end testing and cutover phase is longer than a sprint; and a strong program office sits above it all. The direct quote: "deployment largely follows the classic approach, but deployments happen more often". Severstal ran conceptual design as waterfall and only then switched on increments, with a hard cadence in which every fourth sprint went not to development but to integrating the combined result. SAP runs the program through phases and quality gates. Franco lets sprints into technical sub-streams only, tying their milestones to the overall waterfall plan.

The precise name for this construct is a hybrid model: agile delivery inside the classic control envelope of an ERP program. None of these authors moves Agile up to the level of program management. Scope, funding, architectural authority and the go-live date stay classic everywhere. So the question is not whether this is Agile or waterfall. The question is at which level of the program the Agile sits.

The construct is sound - I advocate exactly this one. The damage comes from the label. A CEO reads the headline "the myth is dead" and demands that the program be run flexibly. Halfway through, that turns into a business sponsor saying "we are agile, let's change it". The difference between "we implement Agile" and "agile delivery inside a rigid envelope" is something the company learns at the most expensive possible moment: in the run-up to go-live.

Point 3. Data migration is not a service to testing. It is a transformation stream

In the McKinsey text, data migration is classed as "non-functional work", which the agile approach touches less than functional delivery: the migration team is asked to deliver data early to populate test environments. Formally their claim and mine can both hold - Agile does change migration less than it changes functional development. In my view, however, McKinsey badly underestimates the role of iteration here, and the root of that is the view of migration as a supporting function.

In an ERP-led transformation, migration is a critical stream in its own right. The data is part of the product, not test material. It is not simply moved out of legacy systems: as the accounting methodology and the processes themselves change, data is enriched with new analytics and deeply transformed. Reference data structures change, so do charts of accounts, analytical dimensions, quality requirements. In effect the program creates a new enterprise data model, and migration is the process of manufacturing it. Which makes data migration as much a transformation stream as process design.

Hence its iterative nature. A transformation replaces dozens of fragmented systems holding an enormous volume of poor or missing data, while the target data model is still being refined as the program runs. One extract-transform-load cycle cannot produce acceptable quality, in principle. The cycle has to be automated and run many times, from the first prototype onwards, raising the analytical depth and the quality of enrichment with every iteration.

From experience. In the industrial transformation programs I have run, seven full migration iterations were completed for individual data objects before the final load into production. With "one cycle at the end", the program would not have started at all.

The sources confirm migration's status indirectly. At Severstal it is one of the program's three platform teams. Franco puts data cleansing and migration first in line for an iterative approach. In the SAP toolchain, migration has a dedicated partner tool. It is not hard to see where the consultant's view of migration as a service comes from: that is how it looks in classic software development, where data exists so that code can be tested. In a transformation it does not work that way, and planning a program on that picture of the world builds in serious go-live risk.

Point 4. A product owner is no substitute for executive decisions

In their own list of reasons ERP programs fail, McKinsey names this: decisions about the operating model, data ownership and authority require executive committee level, surface in the middle of the program, and rest on information that does not exist yet. And in the list of remedies they propose giving product owners the authority to make key decisions from the start.

There is no contradiction here, once you see that these are decisions at different levels. The problem is that the sources do not separate the levels, and companies in practice confuse them.

The product owner decides: priorities and sequencing of functionality, trade-offs between requirements, process detail inside an already approved model.

The program office governs: architectural conflicts, dependencies between streams, changes to overall scope, cross-functional and cross-system integration, resources.

The CEO, the executive team and process owners decide: the operating model, data ownership, KPIs, organizational change, conflicts of interest between functions.

The product owner is irreplaceable at that level, but cannot stand in for executive decisions. The failure happens when a company tries to delegate to the product owner decisions that are, by their nature, decisions about the operating model: which function redistributes authority and responsibilities, and how; which management analytics have to change or become shared. In traditional companies such questions also run into HiPPO - the habit of deciding by the opinion of the highest paid person in the room rather than by data.

Which leads to a conclusion worth stating on its own. Agile does not solve the problem of governing a transformation. It makes the problem visible sooner: a conflict that waterfall would surface at acceptance a year later surfaces in the third sprint. That is useful. Answering it is still the executive team's job.

Point 5. Go-live preparation: the one phase where Agile is genuinely dangerous

McKinsey's line that "deployment largely follows the classic approach" is almost everything the optimistic version has to say about the most dangerous phase. Yet go-live is where everything converges: increments from every team, end-to-end processes, integrations, the final migration. This phase is run on a hard checklist, full regression testing and a waterfall cutover plan.

Flexibility has its own economics. Agile grants the right to change a decision for as long as the cost of change is lower than the cost of premature commitment. A certain distance before go-live, those economics invert: the cost of a change becomes higher than the cost of declining it, because every edit drags a chain behind it - rework, testing, integration, migration, training, and a slipped date. On that stretch, flexible requirements stop being adaptability and become a direct risk of halting operations.

From experience. Six weeks before a go-live set for 1 January, a business sponsor initiated a "small enhancement" to procurement processes, citing the project's agile methodology. The change was stopped and rolled back; otherwise the January start would have been at risk. After that the program adopted a formal rule: a freeze on organizational and technical change a fixed period before go-live, with exceptions only by decision of the program sponsor.

The same applies to the target operating model, though the mechanism is different. ERP is not implemented into an empty organization. If you change the system, the processes, the roles, the KPIs and the structure all at once and iteratively, you get a dangerous recursion: the system is designed for the process, the process changes to fit the new system, the operating model is rebuilt around the process, the KPIs change with the operating model, and the requirements on the system change again. That loop has no natural stopping point, only a mandated one. Which is why the target operating model is designed and approved before design phases close, not along the way.

Point 6. The closer ERP stays to standard, the less Agile you need

You cannot discuss Agile in ERP today while ignoring fit-to-standard. SAP builds its modern methodology around a standardized frame and minimal customization; Franco puts the same thing as advice to clients: do not force ERP to match your old processes, use the industry best practices already built into the system.

Hence a paradox that is rarely said out loud. The more standard the ERP, the less uncertainty there is in the functional design, and the fewer reasons to use Agile as a way of endlessly reinventing processes. Flexibility in a transformation is not there to keep changing the system. It is there to test conformance to standard quickly: to see, on a prototype, the gap between the standard process and the reality of the company, and to decide deliberately which is cheaper - customization or organizational change.

What follows from all this

The study of 21 implementations ends with a conclusion worth memorizing by everyone in this argument: the general characteristics of a project cannot tell you in advance whether it should be agile or waterfall. Context decides - the specific organization, its culture, the leadership's readiness to change processes, the goals of the program.

Which means the question "can ERP be implemented Agile", put in binary form, is meaningless. ERP cannot be implemented "the Agile way". What you can do is design different envelopes within the transformation, each with its own degree of iteration. Where uncertainty is high, iterate. Where dependencies are critical, govern and synchronize. Where the cost of a mistake peaks, plan hard. Where you need fast feedback, prototype and work in sprints. Where change after a certain date becomes too expensive, freeze.

How this works in practice

The working construct, from the practice of large transformations, looks like this.

Hybrid scope commitment is the core of the model. At the top level, scope is fixed hard: end-to-end processes, modules, key capabilities, success criteria. One level down, what gets fixed is not detailed requirements but limits: the volume of development for the program as a whole or by functional block, and the allowed number of reworks on previously approved requirements. Inside the limits, teams are free to prioritize and refine. The construct is written into the program's baseline assumptions and constraints - the foundation of scope management. It delivers what neither waterfall nor pure Agile can: a detailed scope estimate at planning stage, and controlled flexibility during delivery.

Limits are how you manage the cost of change. A rework limit does not forbid change; it makes the price of change visible, because every change drags a chain of rework, testing, integration, migration and training. Flexibility has to have a limit, otherwise it becomes a way of quietly inflating the cost of the program.

From experience. A limit of "no more than three reworks per originally approved requirement" per quarter disciplined both sides: the direct link between unlimited flexibility and an unlimited budget became visible.

Iteration where it pays. Target process design is run by mixed teams of business experts and ERP consultants, on prototypes, instead of months spent documenting as-is. That shortens the design phase and, more importantly, kills the flow of wish-list requirements: the business sees the standard live. Development and testing run in increments under the development and rework limits. Data migration is run through as many automated cycles as possible on the critical data objects. Documentation is detailed in waterfall fashion, as uncertainty is removed.

Delivery capacity against the mandated date. Iteration makes the speed of requirements refinement, the share of rework, and the pace of build and test measurable. That allows expectations to be set with the business sponsor early rather than in December: what part of the total scope, given criticality, belongs in the minimum sufficient go-live, and what moves into post-go-live releases, monthly if needed. Release-based development after the start is the legitimate home of real product flexibility.

Red lines. A scope freeze before go-live, with the right to grant exceptions held personally by the program sponsor. The target operating model before, not during. Cross-functional decisions taken at executive level, on data rather than opinions.

Each of these deserves its own piece: how the operating model and the architecture connect, how migration works as a transformation stream, how to calculate delivery capacity against a mandated date. Those are the next articles.

The conclusion

None of the serious authors actually proposes running a transformational ERP as a pure Scrum project. Even those who say "Agile ERP" add architecture, governance, integrations, migration, end-to-end testing, phase gates and a controlled cutover.

Agile works well inside an ERP transformation wherever there is uncertainty and value in fast feedback. But a transformation program has envelopes that Agile does not replace: the operating model, executive decisions, architecture, data, integrations, go-live and the limiting of change. Which is why "Agile or waterfall" is the wrong question. The right one is: where exactly in this program do we permit flexibility, and where are we obliged to restrict it?

Five questions with which a CEO or a board can test any ERP program, and any consultant arriving with a presentation about flexibility.

1. What is fixed at the top level: program scope and success criteria?

2. What limits are set on development volume, customization and rework of approved requirements?

3. Who has the right to change a decision already taken, and by what procedure?

4. When does the scope freeze start before go-live, and who personally may grant exceptions?

5. Who takes cross-functional decisions when the functions cannot agree?

If even one of these has no answer, what you are looking at is not flexibility. It is a critical risk to your go-live.

The cases come from transformation programs in industry, retail and construction.

Sources discussed: McKinsey, "Agile in enterprise resource planning: A myth no more" (2019); SAP, RISE with SAP Methodology / SAP Activate documentation; SAP, Business Innovation Framework for SAP S/4HANA (2020); A. Kuznetsov, K. Krasnova (Severstal), "How we mixed Agile for implementing a new ERP platform" (Habr, 2021); J. P. Franco, "Leveraging Agile Methodologies in ERP Implementations"; L. Gren, A. Wong, E. Kristoffersson, "Choosing agile or plan-driven ERP implementations: A study on 21 implementations from 20 companies" (2019).