Business Solutions with SAP
Agile or Waterfall on SAP ERP projects?

SAP Project Guidance


Looking at the “Agile Manifesto” and how Agile methods are applied generally involves small, discrete, “digestible” work and task components. 

Trying to juggle the number and complexity of dependencies on a full scale SAP ERP project involves management and coordination efforts which completely go against the idea of Agile methods.   


ERP projects tend to have too many moving parts for Agile–, there are too many dependencies and Agile provides too little control and coordination.  The level of coordination required for a large business package implementation flies in the face of “Agile” methods and techniques.  For example, you have to coordinate:

  • process configuration teams,
  • custom code development teams,
  • data conversion,
  • change management,
  • training,
  • testing,
  • governance,
  • infrastructure, etc. 

On complex projects like this all those “sprints” that are not carefully coordinated and planned (which goes against the “Agile Manifesto” listed below) become completely disjointed disasters.  There are too many work streams with dependencies that can not be going in “their own direction” regardless of the impact to other work streams.

Agile Manifesto Activities

The following chart, from the Agile Manifesto, illustrates serious trouble spots for ERP projects like SAP.



Individuals and interactions Processes and tools
Working software Comprehensive documentation
Customer collaboration Contract negotiation
Responding to change Following a plan

Notice, 3 out of 4 of those items on the RIGHT side are often precursors to ERP implementation failures according to the academic literature.  Numerous case studies prove Agile “De-Valued” areas are the places ERP projects fail.  For example:

  • Failure to follow good processes and have solid tools.
  • Failing to have adequate documentation (training materials, help, etc.)
  • NOT following a well laid out plan (i.e. SAP’s PROVEN ASAP implementation methodology, including sample project plans, templates, etc.).

The only Agile Manifesto item that might have strong need to be followed in the ERP space is the focus on the customer over the system integrator contract.

All of those Competing Stakeholders and Constituents

Not only are the project related dependencies and work streams significant, there are numerous competing constituencies which must also be coordinated:

  • business stakeholders or organization,
  • IT,
  • external business customers,
  • external vendors,
  • system integrators (when you use consulting companies),
  • internal business senior management,
  • business department heads who don’t always agree with each other, etc.

While Agile methods might work well for small, discrete, component areas of an SAP or other ERP project the academic literature proves it is a disaster for ERP implementations. 

Agile is not a waste of time, it must just be understood and used in the PROPER CONTEXT of an overall SAP project.  Even the ASAP Methodology includes an “Agile” overlay.  This is an overlay of the existing ASAP Methodology–, it does not replace more traditional waterfall methods and does NOT adopt the “de-vauled” Agile Manifesto areas.

Does Agile Have a Place in ERP Projects?

It might. 

Agile is not suitable for projects with multiple, overlapping / parallel activities with dependencies between them.  The parallel and overlapping dependencies create a requirement that is more suitable to traditional project management methods with:

  • full project plans,
  • discretely defined tasks and responsibilities (to avoid “border wars” at transition points),
  • clearly defined deliverables,
  • management of parallel work-streams and parallel critical paths, etc.

Applying Agile principles to an overall SAP project creates a high likelihood of blown timelines, blown budgets, and collapsed scope — delivery  suffers while  stress balloons.

Agile in SAP ERP Project Examples

I know about the struggles, stresses and messes of Agile SAP projects.  I’ve been on three of these types of projects and none of them went well.

On one SAP project they tried to manage it with “Agile” and it was a complete mess –, the coordination and responsibility struggles forced  a change to the more traditional waterfall approach.  Using Agile methods the project had an unsustainable burn rate for the budget,  dates were ALWAYS slipping, inter-team coordination and planning were a complete disaster, and before the mid-course correction this project was not  going to go live. 

Worse still because of the “Agile” methods of only planning small, discrete work components just before they are due, each dependent group tried to minimize their own work and risk by dumping many of their traditional responsibilities and tasks onto any other group.  With Agile they were allowed to “self define” much of their own effort and naturally tried to minimize their effort while maximizing their success (at the expense of other project participants and work streams).

I do NOT place this responsibility on the clients who hire outside help, they obviously recognized a capability gap or a need they are willing to pay for.   I hold the outside project managers responsible for this and if you ever encounter one of these snake oil salesmen then you should FIRE THEM!

My Conclusion on SAP and Agile Deployments?

Pure application of Agile is a disaster  on any major SAP, ERP, or business software implementation project.  I can absolutely guarantee you that any Agile SAP project delivery “success” claim violated the Agile Manifesto to get there.   There are too many moving parts and too many constituents to use pure Agile on a full blown SAP project.

However, Agile can work within certain task areas, and at different periods and phases in projects.  I have used “agile-light” approaches which have a waterfall overlay.  It is possible to successfully combine agile tasks, to provide a higher quality project result, as long as you continue with the waterfall coordination between work-streams and efforts.


Contact me today through our site contact form ( ), phone, or e-mail.

Bill Wood
+1 (704) 905 – 5175
Bill Wood contact


Print pagePDF pageEmail page

Popular Searches:

  • sap roi powerpoint
  • how to select a project for Agile for sap erp

Related Posts:

10 Responses to “Agile Project Methods for SAP ERP Projects?”

  1. Tapio Järvenpää says:

    Hi Bill,

    I’ve been enjoying very much reading your insightful writings about SAP projects and the entire ecosystem of services. Most of the time I’ve found my thoughts resonating with you!
    This time I’d like to challenge you.

    In my recent SAP ECC 6.0 program (all core modules except APO, OT VIM, BW, HR minimaster, T&E, portal + serious number of interfaces to other systems) we’ve been applying Scrum methodology. And we’ve also been paying attention to Agile Manifesto and found it very, very useful.

    Key planning principles:
    1) Develop a global template by
    2) delivering “a potentially shippable” release every quarter for
    3) pilot go-live in a year from kick-off and
    4) prepare for quarterly roll-outs.

    There were a few constraints that we had to be conscious about:
    a) our company had no whatsoever experience about SAP
    b) we had very little of communication infrastructure needed by global transformation projects
    c) almost all the businesses were using different legacy ERP systems
    d) master data management practises were equally non-standard as ERPs

    By applying scrum we were able to gather once in a quarter vast number of stakeholders to test and try hands-on the latest integrated release. As they saw the system in action they were in good position to express their thoughts about it and articulate their requirements. Also the development team learned their primary job i.e. deliver a solution to users. As a matter of fact the deliveries of these potentially shippable releases were kind of go-live dry runs. The team performance became more predictable as every release included similar activities. In a waterfall method subsequent phases are different – performance in blueprinting is no prediction of performance in realisation phase.

    Still the best learning! The stakeholders and business users that we frequently used in testing (and sparring our thoughts) were easy to use as change agents and SAP evangelists among their home units. They had had a chance to have their educated say about the development and early hands-on experience.

    Best Regards
    Tapio Järvenpää

    • Congratuluations!!! on your success.

      Unfortunately this has not been my experience. And I would certainly like to know how you applied SCRUM to each of these mini “go-live” trials. It would also be interesting to find out how long the overall project took, whether you used a waterfall approach at all. And how do you do blueprinting in this type of integrated environment under an Agile approach?

      I have lots of questions because I’ve never seen this work on an **overall SAP project** before, except when the timeline went WAYYYYYYyyyy over, budget was blown, and project stress was way high. But for me I don’t know if I would call that “working”…

      • Tapio Järvenpää says:

        HI Bill,

        we started project planning springtime 2010 (we were not aware of this, but determined to make a paradigm shift in implementing SAP. I had been away from SAP projects almost 10 years and during that time seen other systems and methods.

        In a nut shell: from kick-off to go-live of pilot site 13 months, one week ahead schedule. Quarterly intermediate, integrated releases. Two week sprints. Biweekly scrum-of-scrums meeting where all teams reported their progress and if they were to need anything from other teams during the next sprint. Teams: FI/CO, MM, PP, Variant Config, SD, PS, IM/WM, QM, Basis, training, migration, support, master data and integrations.

        After the above global template development and pilot implementation we have started roll-out projects. They look more like ASAP projects, but even they have intermediate stages.

        Blueprints are evolving over the course of project execution.

  2. I have been an SAP PM for 14 Years and can confirm Agile and scrum is nonsense, two hugely failing UK projects are directly attributed to the adoption of using agile. British Gas & Cambridge Assessment, there are probably endless more.
    SAP must be implemented through ASAP, when you try and use the agile nonsense with ASAP (or without) it makes a mess of the programme. Interestingly both of the failing projects have the worst project managers and programme managers available in the UK market today. They are quite happy in the chaos of an agile implementation as they are rubbish and can hide when using agile and scrum. So it’s very good if you are a crap pm and want to get lost in a project.

    • Unfortunately Harry that has been my experience too. The WORST PMs I’ve ever worked with used “Agile” as an excuse to avoid doing real project management. Those projects too were a completely chaotic, stressful, painful mess.

      I have found that Agile does work will in a *very* limited fashion for some small work-packages in a project if the requirements are clearly defined and easy to understand. They also work well in a support function after going live for fixes and enhancements. However, using Agile after going live for support also means that about every 5 years you have to revisit the whole solution and re-work a bunch of stuff. Agile in those small work packages for support and enhancements tends to produce a LOT more custom code than necessary. So if you have the hindsight of seeing all of the related parts several years later you might see where a standard solution would have been better. But when it is a quick “Agile” fix, or a quick “Agile” enhancement there is a HUGE tendency to custom code the small pieces rather than using the standard solution.

      Good luck on your projects and I am sorry to hear about your difficult experiences.

  3. Satyan Prakash says:

    Guys one of the principles of agile is to customize it as per the requirements of the project. It is true that the nature of agile implementation for SAP projects won’t be same as you would apply for typical web based projects. It can’t definitely be pure scrum due to the vast number of dependencies. You have to customize it heavily to suit the SAP implementations. My project was all about integrating an existing SAP PM and CRM implementation to a partner system based on Salesforce. The demands placed on the project team was or delivery quick short deliveries although the requirements were vague. And we were successfully able to use agile style deliveries to meet the expectations of the customer. Guys to be honest if you are not able to able to customize agile properly and the project fails it’s fair to blame agile. End of the day any methodology can fail if not implemented properly. I’m happy to share details of my project in case any of are interested.

  4. […] offering insight based on my personal experiences around “Agile Project Methods for SAP ERP Projects?” I thought it would be helpful to highlight a couple of areas where Agile does […]

  5. Amber Schibetta says:

    I have used Agile methods quite successfully for small scale implementations on preexisting SAP modules/systems/environments. “Enhancements” or “Integration’s” to a preexisting system, has worked very well for me. For these types of projects, I feel Agile provides the best value, quality and user satisfaction.

    I have never used an Agile during any of the full scale SAP implementation projects I have worked on. However, although I have never seen it used, I would love to try! But, I have yet to meet a client/businesses willing to let me test it out in consideration of the costs involved in standing SAP up. Using anything less than the tried and true methods would be unacceptable, which I cant really fault them for!

  6. Irina Donciu says:

    There are still many people who believe that modern application delivery processes like Agile and DevOps simply don’t or can’t apply to SAP, despite the evidence to the contrary.

    The fact is that many modern IT organisations are under enormous pressure to deliver business benefits more quickly, and old ways of working simply no longer cut it.

Leave a Reply