Skip to Content

Agile vs. Waterfall – creativity vs. responsibility? Part III of MY evaluation of Agile as the method for SAP ERP implementations

My personal view is that both method waterfall and Agile are very good and matured. They are different and they have pros and cons in each particular situation. My point is that for SAP ERP implementation the waterfall approach is right. Agile is perfect and may be much better than waterfall for many other components of SAP landscape but not for SAP ERP.

I am sure it’s very good that we have now Agile ASAP. I think however that there is need of clear message about the positioning of Agile and conditions to use it. I found something at the end of the material but I think it is too soft formulated (page 14th – “Discussing Agile Fit”):

I like to make now the last part of my evaluation of Agile as the method for SAP ERP implementations – I like to discuss the accents (pros and cons) of both waterfall and Agile in  terms of creativity, responsibility, flexibility, sustainability and reliability. Once again to have it clear: writing in this article about SAP ERP implementations I mean only the area of core ERP and only big implementations (no RDS).

Please let me make more general reflections prior to the evaluation. Agile is not something new – is more than 50 years old due to:

from other perspective Agile is the successor of so called “Spiral Model” as described in Wiki:

Please note that in the linked description is following statement:

“The spiral model is mostly used in large projects. For smaller projects, the concept of Agile software development is becoming a viable alternative.”

Agile is the method of development in small groups (to 9 stakeholders). In fact Spiral Model repeats (putting this very rough) in cycles the waterfall sequences with all necessary formal regulations. Agile is focused on developing without a detailed specification. The term Agile was introduced in 2001 in “The Agile Manifesto” – that’s interesting because many known formulas of Agile like Scrum were defined sooner (1986 or 1995 depending on criterion). Note that SAP is adopting Agile for ASAP in Scrum formula – that is probably the most “conservative” with the duration of sprints to 4 weeks.

So why just now Agile is becoming so “trendy”? – its clear consequence of SOA architecture. Many components like BO, CRM and so on became independent and may be fully independently implemented as parts of big business landscape. Their nature makes as consequence that typical “waterfall” approach in ASAP may be not efficient. The Agile implementation approach is very effective for them and that is the reason that adoption of Agile into ASAP is the right move.

The main advantage of Agile is the flexibility that allows creativity. The documentation is left for after-the-realization phase. That all suits very well for components like BO, CRM and similar. The attitude of potential stakeholders is in these areas in the rule very open and creative. That makes Agile the right way of doing the implementation.

Lets look on the ERP in this context now. SAP ERP has become now more compact since many areas being in the past parts of it emancipated into separate components. However even the nature of very core area of ERP (FI, CO, MM, SD – counting only the main parts of core) are in this way integrated and specific that in my opinion makes the use of Agile for SAP ERP implementation (as well as every other big ERP system) very risky and hard to manage. In short words: ERP is still the same!

I like to draw your attention, that core ERP area is in fact still the wide accounting system – where every business event is valuated and the effect of the valuation is registered into books (ledgers). There are still valid requirements for: reliability, audit ability, traceability and that all connected with clear defined responsibility. All factors above make that the design of the system in this area has to be very well considered and diligent. That leads in consequence to the conclusion that ERP is area where the complete design before realization is necessary and suitable.

From other perspective: how to proceed incremental with ERP? – making the system with only part of accounts, tax schemes and only some groups of business partners or subset of material master? How to prepare reliable test under these circumstances? Its clear that it will not have much sense and will cost a lot in term of time, motivation and confidence. That is why I am sure for ERP area only the waterfall method is the right one. And as I wrote: after dozens of implementations I observed or participated in: it worked very well with waterfall so why to change?

The big implementations of SAP ERP mostly require dozens of stakeholders – but the right Agile team should not exceed 9 participants due to definition. So probably the Agile is suitable for the use inside implementation teams? Yes – I think that can be – if of course reasonable – but only during the blueprinting phase to test some possibilities. Then the blueprint has to be agreed among the whole projects – there are too many interconnections to allow the uncontrolled change after blueprint has been approved. Since there will be several implementation groups using Agile in the whole sequence design/realization/testing, it may lead to the situation that the cycles between them will be not sustainable and the control of synchronization will be lost.

Another thing is: there are some components of SAP ERP implementation like interfaces or some pieces of customer add-ons that may be treated separate. Agile may be very effective way of doing this as I wrote already in one of my previous posts.

Everybody who made big ERP implementations knows that it is very hard to take the right audience of key users and management and to compile the right (in terms of the level), complete blueprint synchronized between teams. I wrote already about in:

Please note that often the stakeholders (key users) of ERP implementation are not available in sufficient extent. They not always have the right attitude and understanding. Starting the ERP project with Agile may open the Pandora box with unexpected requests and situations or simply misunderstandings that all together may lead the project in very uncontrolled direction (or directions). Sometimes – especially in the public sector – even the stakeholders do not see the creative way of making implementation as the right. They may find the “make and try” approach as the symptom of weak product or weak consultants!

That means that there are many reasons to carefully consider use of Agile ASAP on SAP ERP projects.

PS. Dear Readers of this article –if you find it usable for you please award me wit “like” or even rank with stars! This article is effect of my evaluations with the target to create small focused on most important aspects implementation handbook: I will be grateful for every critical comment – for the essential ones I can make award in the discussion:

Best regards

Waldemar Faliński

You must be Logged on to comment or reply to a post.
  • Waldemar,

    i have awarded you both the like and the 5 stars, not because you asked for it, but for being persistent and consistent with your message. sometimes (or even mostly) it takes more than one take to explain something and having experience with both very large and quite small implementations i can fully appreciate the discipline required to overhaul the mission-critical application like ERP (and not necessarily SAP only).

    agile may seem great for getting the initial funding for proof of concept, but only the buy-in and legal obligations coming from the very top of the organization can devote the resources required for implementing large portions (but never the full suite) of the ERP system in the enterprise in a manageable fashion.

    best regards,


  • Waldemar,

    Great effort to preparing Process of Implementation, Because every success comes based on strategy and Planning.i have awarded you both the like and the 4 stars



  • Waldemar,

    I'm not sure how much time you spent reviewing the Agile Business Add-on to ASAP prior to writing this article. It seems to me that your criticism of the Agile approach is based on general understanding of SCRUM from Wikipedia and other sources. Please note that Agile Business Add-on to ASAP is based on our experience from implementing SAP software with Agile approach. Let me address few items that may be misleading in your description of Agile Business Add-on to ASAP (while they are fitting the general SCRUM descripton that we had to work around for specifics of SAP implementations):

    1. We have Blueprint in this methodology - we call it lean blueprint as it leaves out some more detailed design activities to individual iterations in Realization. Indeed you create requirements and functional specs on high level (scenario level which some call Epics) then decompose down to processes level.

    2. We do create documentation that is required by the team to design, develop, test, train users and provide end-user documentation. The level of detail may vary depending on whether team is co-located or distributed. Please do not read much into the 'Working software over Detailed documentation' from Agile manifesto - we know what needs to be documented in SAP implementations and ASAP properly reflects that.

    3. Agile approach scales even for bigger project organizations - just as in traditional projects there may be multiple teams working on different areas of the solution. As a side comment - did you know that SAP internally uses SCRUM to develop majority of our software? We have thousands of people working in sync following common takt. Just as in traditional projects you need integration meetings between the teams - in SCRUM they call them Scrum of Srums (but you can call them whatever you like or customer wants).

    4. While your article suggests not to consider RDS we can not simply ignore the fact that many companies find the RDS and Best Practices approach very compelling for their implementation. RDS are popular not only for CRM, HANA, Mobility, but also for ERP implementations and using RDS as a baseline build is very powerful way to do visual blueprinting that helps build better solutions.

    5. On the mechanics of the project - you start your Agile project traditionally Project Prep, Lean Blueprint, then you swith to iterative build in Realization (with option to split the project into multiple releases should the customer want to enable set of capabilities first before enabling the rest - think of Global ASAP approach with template versions - this is very similar) and then switch back to traditional approach for integration testing, UAT, Cutover and Operations.

    As I stated previously you as a consultant or customer have choice to make - traditional or agile approach. There are multiple factors to consider in terms of Agile fit - organizational, stakeholders, project manager, solution being built and also the team readiness to adapt to Agile. You need to consider which approach will give you the best chance to succeed.

    Think of it as having options...

    • Dear Jan,

      Thank you for your exhausting comment! It is very kind of you and I appreciate this. You are right - I have to consider this.

      However I must say that you are probably still under impression of my first articles where I was little provocative. I mean I am very positive about Agile as a option in ASAP and I see it as option. I am presenting only doubts and objections (I will not name this as “criticism”) about use of Agile by big ERP implementation – especially new ones.

      One think I have to clear as I see it was misunderstood: I really had no intention to express as you are writing While your article suggests not to consider RDS” - I only limited the area of my article to big ERP implementations that are made without the use of RDS.

      I personally think that by use of RDS especially in SMB there is a lot sense to use Agile add-on!


    • Dear Jan,

      experiencing is more reliable than reading - now I am starting the HR project (first scope PA and e-recruitment) in big restaurants network operator and I am "loobying" that Agile ASAP 8 is the right method. I hope soon to make next comments here according to the project realisation steps.

      • Hello Waldemar,

        that is great news. I hope it all works out and you will be able to use the Agile ASAP framework in your next project. We will have set of three sessions in the next 2 months with ASUG that will focus on explaining the ins and outs of the methodology in more detail. Not sure if you are ASUG member, but if you are keep your eyes peeled for the invite in the next few days.

        Let me know if you need anything as you are getting into planning for your project.

        Best Regards, Jan

        • Hello Jan,

          it's very kind of you - thank you. I am just digging in Marketplace to see what is there now. If you think there is something else (outside of SAP Marketplace) interesting (like success story) please give me path.

          Best regards


  • Hello!

    This is a fascinating subject, I am very glad you brought it up. The other day a friend from the uSA asked me what in the world "agile" meant and I explained and he said that was interesting but it could never wokr for a big SAP implementation.

    I have worked in the SAP space since 1997. Every large SAP implementation has been done via the Waterfall method. All but one was a success, but in no case could I describe the end users as dancing around the room with joy.

    I'll state my position here - I think waterfall methods as I have known them are not as good as the agile type projects I have seen in the last few years. rather than just stating that, I will try to justify that position.

    Here in Australia in my company I could not say we really use the agile methd, but we do show work in progress to end users on a regular basis, and try and get their input before new developments even make it to test, that is sort of like the agile method.

    I know I am teaching my grandmother to suck eggs here, but I have seen business owners sign off huge requirement documents the size of telephone directories, and then 18 months later see their new system for the first time and not be best impressed. To be fair to the project teams, even in waterfall world they wanted to show the work in progress to the business guys but they were "too busy" with their day to day jobs.

    People don't tend to do anything that would distract them from their real job unless it is mandated. Time and again I have seen senior managers realise the month before go-live that things are going to change, and then try to get involved and realise it is too late.

    I also notice that above you stress the accounting nature of ERP projects.

    Traditionally IT systems just did accounting and nothing else, which is why most companies have the CIO reporting to finance as opposed to the CEO. One day companies will wake up to the fact that systems like SAP can do things other than FI/CO but that realisation is not going as fast as one might think.

    Now, I was an accountant myself for seven years, so I naturally tend towards that view i.e. FI/CO is the be-all and end-all, but it does occur to me that accounting rules are mandated by the government of the target country, and are thus a clear target not needing any user input. So, that would be easy to build a system for a year on your own and only then give it back for user testing.

    However the much more important (from the CEO's perspective) sales and logistics and manufacturing processes are almost always company and country specific and far from being the same country wide they are all over the place. In fact they are so bizarre - in my experience - I would argue you need user input all along the way just to make sure you know what in the world it is they really want.

    What is more in the waterfall projects I have been on, when they take 18 months to several years, everything has changed in that period (apart from some accounting things) so what the business owneers signed off on at the start bears no relation to what the business needs at the end of the process.

    In the UK I well recall the Hayes Bypass which took 20 years to build, and when it was finished the thing it was trying to bypass no longer existed.

    Cheersy Cheers


    • Paul,

      you are making great points about the need to be agile in project implementations - and I do not necessarily mean follow SCRUM. What I mean is really highlighted in your last point about the project duration and dynamic nature of the business. Today this is reflected in changing nature of majority of projects that need to deliver benefits quicker than in the past and in my opinion Agile approaches or multi-wave deployments lend themselves better to this requirement than traditional plan-based projects with long timelines and no intermediate releases to the business.

      Paul Hardy wrote:

      What is more in the waterfall projects I have been on, when they take 18 months to several years, everything has changed in that period (apart from some accounting things) so what the business owneers signed off on at the start bears no relation to what the business needs at the end of the process.

      In the UK I well recall the Hayes Bypass which took 20 years to build, and when it was finished the thing it was trying to bypass no longer existed.

      Cheersy Cheers



    • Paul, thank you for the comments! But I must say that I never ever have participated in the waterfall project (starting my career by SAP in 1994) where the key users were
      isolated. Now agile is “trendy” and that is ok, but we do not have situation
      that waterfall is bad because the isolation of users from the implementation.


      The waterfall may by conducted the way you are describing, but in fact that is not
      the immanent part of waterfall – that is rather some kind of bad praxis forced
      in the past by big advisory companies (big six in those times). I am proud that
      working in SAP I always was “forced”  by the methodology (previously having another name as ASAP) to active cooperate with users in every single phase of the project. I like this way.


      Even big projects in those years were conducted  with deep participation of key users and even the used approach was time&material, where the key users have  had direct influence on the work and in consequence the acceptance of the solution was high – there was no place for “surprises” in this way.


      In fact there was always some kind of agility during SAP waterfall implementations especially in the concept phase (actually named blueprint).


      My point in this article was that the Agile as the main method do not fits with the ERP
      (also FI/CO with MM, SD and all the "transaction" functionality).


      But I love agile and now I will implement HR – PA with Agile ASAP8 – implementation of this area can (in my opinion!) perfectly profit from the incremental
      implementation as the main implementation “engine”. Best regards Waldek

  • I was reading this again on the train into work this morning, which you can take as a compliment because it means I am thinking about what you are saying a lot.

    Two things (that I just noticed) you said jumped out at me ths time.

    Firstly I am not sure you can have a rigid defintion that an Agile project is one with less than nine people, and anything more is Waterfall. It might say that it some sort of textbook or dictionary, but I imagine you could have a waterfall project with just three people if you wanted, and conversley if you were doing a SCRUM sort of thing with nine people, and hired someon else, and then kept doing the excat same methodology, surely it doesn't magically stop being an agile project whereas it was before? That may sound like nit-picking.

    The first time I heard about an agile implemnattaion was at SAP Inside Track in Bonn where someone from the Netherlands government was talking about thie first agile project where they put a smartcard system in. If it's the government they are bound to have had a large team. And if SAP are doing SCRUM internally now, they have lots of developers....

    I was also very worried about the comment "after dozen of implementations ... that worked very well with waterfall ... so why to change?"

    That sounds horibly similar to "we have always done it this way" which is what I have heard so many times in my career as a carte blanche justification for anything i.e. we have alway done it this so way so it is therefore correct.

    In the case of a large SAP ERP implementation a large chunk of the existing users tend to say "the legacy system has been there for ages ... it works very well. So why change it to an SAP system?"

    And they are right, I'm sure you'll say, to argue in this kind of way, and they are right, and I am right, and you are right, too loo wry-ay (c) Gilbert and Sullvan.

    But on a more serious note they are right - the legacy system did work well, and naturally waterfall methods work well, so why change?

    It could be said that human nature is such that we are never satisified with what we have and are always looking to improve things..

    Sometimes we as a species make a right mess whilst introducing such new ideas, but it's never going to stop.

    I am going to be very interested in your expereinces doing an agile HR project. We did a VERY waterfall one, and whilst it worked well, it took forever, and then after go-live we had to go back and change a fair bit. It doesn't help that SAP keep totally changing the UI technology, but then the argument I made just now means SAP must be correct to do this!

    Cheersy Cheers


    • Hello Paul,

      thank you - I am taking this as compliment!

      I was provocative in the article to start the discussion, but in fact I agree 100% with your last expression. In the times when "agility" is the buzzword I tried to defend the waterfall since the both approaches haves their "powers". The project manager have to justify what is right to particular purpose - no one of them is perfect tool for all situations. For ERP (and it means now "core" ERP) I am sure agile as the main approach is wrong. For HR-PY the same probably too but for HR-PA and another soft HR – the agile will be much more efficient.

      Best regards