Skip to Content

ASAP goes Agile

ASAP goes Agile

Earlier this year SAP published the new Agile Business Add-On to ASAP (Service Marketplace account required) that incorporates agile and lean implementation concept based on SCRUM methodology into the new AcceleratedSAP (ASAP) Methodology and Business Add-Ons. This Business Add-On maps agile implementation approach elements such as a product backlog, a baseline build, and iterative sprints to the traditional phases of ASAP.

This close alignment allows SAP implementation projects to following Agile approach and deliver benefits to the business early through incremental releases of functionality during the course of the project. In addition to the incremental nature of the project the Agile methodology requires much closer cooperation between IT organization and business users. This is done in a structured manner dictated by the SCRUM framework that consists of clear ownership of product backlog by the business, regular communication between business users and IT and structured approach to reflect evolving nature of requirements as solution is built.

At the same time the methodology benefits from the proven structure of ASAP 7, lean project WBS and strong set of quality measures like project Q-Gates that are built into ASAP 7.

With Agile Business Add-on to ASAP project teams can tailor the level of acceleration in the project leverages to fit customer specific needs by leveraging full spectrum of ASAP7 acceleration techniques including the SCRUM based implementation approach. See next picture for overview of acceleration techniques build into ASAP 7.


For example, the implementation team might choose a to follow a hybrid implementation approach that pairs the SAP Best Practices (e.g. standard functionality) for significant part of the project scope with Value Prototyping and Custom Development Services from SAP to address Customer Own Practices that require enhancements of SAP standard. Such project can be managed with Agile implementation techniques to achieve earlier return on investment through iterative delivery of functionality to the business. Instead of aiming for delivery of one big release in 9 months the project team may delivery 2 or 3 incremental releases of functionality to help business realize value sooner. 

This approach provides the flexibility to respond to our customers’ implementation needs within a proven ASAP framework. We recognize that this is a new concept for many SAP practitioners and will offer help through practice sharing, discussions and knowledge exchange in the ASAP community forums on BPX as well as in the BPM webinars. We are also working on formal extension of standard ASAP training for Agile Business Add-on.


As a starting point on your journey to understanding the Agile Business Add-on implementation approach you can review the recorded BPM Webinar introducing the Agile Implementation approach. The recorded session discusses the project acceleration techniques built into ASAP 7 in more detail and focuses on the iterative approach of the Agile Business Add-on. You may also use the accompanying slide deck (Service Marketplace account required).

As a next step we invite you to browse through the ASAP 7 methodology on BPX with the Agile Business Add-on enabled. Note that you will need to navigate to Add-on View menu item and select Agile Add-on to be displayed after the roadmap loads in your browser.

If you are attending the ASUG/SAPPHIRE NOW event in Orlando come and join the session # 1608 ‘Using Agile Approach for SAP Implementation’ on Tuesday afternoon at 3pm (room S310C – S&S 3) where we will discuss the Agile implementation methodology, its fit in projects including use cases from early adopters of this implementation approach in SAP projects.

You can follow this easy roadmap to explore Agile Business Add-on and agile implementation approach.

Step 1 – Get informed

Step 2 – Get familiar

Step 3 – Engage in the community

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

    This add-on is a really good step forward and I'm glad that SAP is officially incorporating some of the learnings from more iterative projects into the core ASAP methodology.

    One thing I'd be careful about is the claims of "agile" and iterative value delivery:

    This add-on to the ASAP methodology doesn't seem to address most of the points of the Agile Manifesto at all. While it may be a big step for SAP projects, if we don't acknowledge how far we still have to go in the SAP world, we may start to look a little foolish to those in the software development world who are years ahead of us in the SAP world. I'd like to see more discussion of "where we were" vs. "where we are" vs. "where we want to go". Agile development in the SAP/ABAP world is very difficult because of the tooling and legacy architectures, but I think making it possible is a worthy goal.

    Regarding the claim of iterative value delivery, I think this is a dangerous claim to make. I guess the question is, when is value delivered? I believe that an implementation begins to deliver value when it generates a positive impact on company performance. All the way up to go-live, the impact on performance is purely negative. Only once the software is live can it begin to pay back its debt. Most projects (unfortunately) only begin to deliver positive value months after go-live, if at all. This is all to say that an iterative realization phase doesn't give us iterative value delivery. You've got to go live iteratively to have a chance at this.

    Just some thoughts. There are other far more experienced agilists hanging around SCN. Hopefully they will weigh in.

    Lastly, I'd like to request that the ASAP7 documentation be revamped so that it works in browsers other than IE. Currently it doesn't work in Chrome or Firefox, and I assume it doesn't work in Safari. This means that Mac and Linux users are left out in the cold. Hopefully this can be rectified ... ASAP 😉


  • Small changes - and yet the same way of doing things.

    Slow - change seems to be slow - software roll out, design, etc.  doesn't seem to ever change much.

    Feel free to disagree!  🙂


  • Some improvements in speed, but certainly not Agile. Blueprint is still in front of realization and there is no feedback loop to change the blueprint and replan the realization at the end of every sprint.  I even heard something to the effect that prototyping at the blueprint phase would ensure that the realization phase did the right thing! 

    Someone just does not "get it".  Business and people change and *everyone* must learn as they go.  You don't know enough in blueprinting to get a very good design if you are doing anything other than an out of the box implementation.

    I hope SAP eventually "gets it".  Agile methodologies make a much more predictable project with a better view of reality at the end of every Sprint.

  • Thanks everybody for sharing your thoughs and comments. I do appreciate honest and passionate feedback.

    I do hope you will have chance to join us at SAPPHIRE/ASUG next week. If not I do recommend to take a look at the recording and presentation that goes into more detail that this blog can.

    Let me address some of your comments here and I promise to post a follow-up blog after SAPPHIRE, or maybe even a series that goes into more detail and explain how the principles and values of Agile have been fitted into the ASAP framework for implementation.

    Vijay: I read through your blog and agree that use of Agile may not fit all organizations or project contexts. That is also reason why SAP continues to offer ASAP 7 which is proven implementation approach. For teams that are ready to make the leap to Agile or are already using SCRUM or other Agile methodology we do offer Agile Business Add-on to ASAP that extends ASAP with Agile process, roles, artifacts.

    Amy, Michelle, Ethan - the picture in the blog provides outline of the approach. I chose it as it shows the general idea of the iterations. Of course the full implementation of methodology is richer than what the picture shows. In short we made following changes to standard ASAP:
    1. SCRUM roles added in Project Prep
    2. Blueprint has been modified to Lean Blueprint approach that has two goals - build baseline solution on SAP standard functionality AND capture all known gaps in backlog
    3. At the end of Blueprint the backlog is prioritized by business owner and realization is planned. The realization is split into number of release. Each release consist of one or multiple sprints (each 2-4 weeks long).
    4. After each sprint the backlog is re-prioritized and next sprint is re-planned.
    5. For each release the team conducts shortened integration test and UAT before launching Final Prep and Go-Live.
    6. After go-live for the release team goes back to realization to continue with next sprint/release cycle.
    I tried to be short since this is a comment. More will come in next blog post.

    Ethan: Thanks for the note about the browsers. Yes we are working on this and will have version ready in next few weeks. I have been testing the lab version and it works very nicely in Firefox, Safari, Chrome and IE. That should cover majority of users and platforms. We are also looking into mobile access as next step after this release. Oh and we use SCRUM in developing the functionality - I happen to be the business owner in that process.

    Thanks again for the comments and please keep them coming.

    • Hi Jan,

      Thanks for expanding on your comments in the blog. This is very helpful. I guess I didn't pick up from the slide that each sprint includes a testing and release phase. In that case it starts to look a little better.

      I'll admit, I tried watching the presentation, but it's really difficult for me to extract information from webinars. Some people love them, but I don't 🙂 I'm really looking forward to more written information as you continue to blog and as the documentation becomes more accessible.


    • Thanks for the additional details.  The biggest step that I see missing is the modification of the ---Blueprint--- at the start/end of each sprint.  Is that included somewhere?
      • Yes. This is integral part of the sprint planning activities during which you will need to re-prioritize the remaining backlog items. Once the scope of the sprint is agreed it is fixed. For all items in the sprint backlog the design activities are performed, functionality is configured, enhancements are developed and tested. Then the project team performs sprint review. 

        You can find more details in the Agile Add-on accelerators in the Project Management work stream.

    • Hi Jan,

      Great post!!!

      you have said in above remark,- “The realization is split into number of release“.

      Would you kindly guide how to split/slice the Realisation phase into N number of releases?(ie how to find this number (N) of release).





    • Good question. I need to state that I'm not contracting specialist, but I'll hapily share what I have learned in this space.

      The contracting in Agile space is as evolving as the Agile approaches themselves. You can find good overview of the contracting approaches here:

      For the most part your standard time and materials contract with appropriate refelction of the project lifecycle in sprints and releases should be sufficient. You may need to also account for the potential adjustment of scope by the product owner in the contract and build in clauses for governing such changes.

      I have seen some examples of collaborative contracts, fixed price contracts with early termination fee and early delivery bonus that relate to the overall overall project value to balance the benefit/loss of both parties. All these contracts sound interesting, but I have not seen them used in the SAP space yet. They were all used in pure development projects with no packaged software involved.

      I would say stay with the T&M where you can since it is very straightforward contract that is easy to ammend should you need to.

      When we talk about fixed price contracts it is always challenging to deliver those if the requirements are not fully flashed out prior to starting the project which is often the case. So for fixed price contracts it is fair to include clause of possibility to re-estimate after blueprint phase if there are significant scope changes. But that is not applicable only to Agile projects. I believe it is good and fair practice since after blueprint the delivery team can better estimate the remaining project cost as the requirements stabilize at that point.

      You may also want to google 'Agile contracting' -there is a lot of debate in the SCRUM community about the ways how to contract for different types of projects.

  • Hi Jan,

    We're one year later and I was wondering if any progress has been made in making ASAP more Agile?

    I very much like what I have seen including the provided feedback. On a phase level I think especially the dynamics should more clearer and I think DSDM is a good method that shows the continuous cycling between the phases (note: the DSDM phases almost map one to one to ASAP).

    I also discovered and an interesting (but old) book that describes DSDM with SAP implementation with this topic (although I didn't read it myself):

    Cheers, Chris

    • Hello Chris,

      indeed the Agile Business Add-on to ASAP has been out for over a year and we have experience from projects using the Agile approach. We have based the Add-on on SCRUM framework as we have the most experience with it and it is also the most popular Agile framework in the market today. The article above shows the key elements of the Agile approach and you can view the content if you access the ASAP Methodology for Implementation and enable the Agile Business Add-on through the Add-on view option. Let me know what you think.


  • Hi Jan,

    Can you please share some experiences after one year of use of the AGILE/ASAP? Is that provided for implementing of all SAP products? What are the expected benefits

    I must say I am very skeptical about the implementation of SAP ERP by use of AGILE. AGILE is for rather small close working development / testers teams with very good communication. SAP ERP implementations are opposite to this and that is the reason for my skeptical approach. That is also the reason that I am fully confident the waterfall is accurate and optimal method for SAP ERP. And it really works - what I can say after dozens of implementations.

    It can make sense for CRM, BI or some pieces of ABAP development use AGILE/ASAP but for SAP ERP? I rather expect that the use of ASAP/AGILE by SAP ERP implementations will create of high failure rate.

    I do not think it will make the projects faster. The SAP ERP implementations are fast if we take the business change they make. Realization stage takes normally about 3 months – if we take 2 to 4 cycles they have to be 1 month length of less to keep this result with ASAP/AGILE. I do not think this is realistic and reasonable by Sap ERP implementation.

    The use of AGILE for big wide projects may bring the results like the for NHS RIO project in Britain (patient records evidence) – after many years complete disaster. What was the methodology used?: AGILE and PRINCE2.

    I recommend to make clear specification (or probably it is and I missed it?) for what purposes and under which conditions the ASAP/AGILE have/can be used to not damage the high success rate of SAP implementations.

    Best regards


    • Dear Jan,

      I already found some results - I am sharing my doubts according the SAP ERP in post:

      Please be careful with the messages about AGILE - now it is trendy to adopt various methods on SAP ERP implementations and I can see alread many fresh/ambitious/certified (with black belts!) project managers around the globe convincing customers to use the AGILE adopted ASAP method NOW. In the past SAP has limited the availability of news in form of ramp-up - consider this pls.

      Best regards

    • Hello Waldemar, 

      Yes indeed we have been working with number of organizations that have used Agile approach in their SAP implementation. The solutions they implemented are pretty diverse from ERP solution through PLM to analytics products. The project size varied as well - from small through medium size to large implementation programs.

      While Agile techniques work for many projects they may not work for your particular case. I always stress with customers that are exploring alternative implementation techniques that the usage of Agile techniques may not fit every single situation. We recommend to assess Agile fit to the organization, project team, solution, project manager and stakeholder groups.

      It is not that all implementations will use Agile techniques, but there are many situations where Agile provides great fit and benefits. In the same vein the traditional approach may be prefectly good approach for other projects.

      As we see move of implementations from traditional design-based approach where the project team builds entire solution to exact specs ground up to more of a packaged approach where team leverages pre-build components and assembles them to fit the customer needs the Agile approach is used more often. In these projects teams build additional functionality on top of a solid baseline and this is where teams can really benefit from incremental build approach to release functionality to business incrementally to help drive earlier realization of benefits.

      While this may sounds like magic dust to some, it is undeniable that with use of Rapid Deployment Solutions, Agile approach and visualization techniques projects are shortened. We have many examples of projects that are delivered in 9-12 weeks at much lower cost than you see in design-based implementations.

      I respect your opinion that is shaped by your expertise from SAP deployments. But we also need to recognize that many clients are very successful with using alternatives to traditional deployments and Agile is definitely helping with delivery of benefits faster in many situations.

      • Hello Jan,

        Thank you very much for your explanation! Please note that I am not against AGILE – I am addressing the doubts about pros and cons only by ERP implementation.

        Have you also experienced “regular” (it means whole scope and no RDS) SAP ERP implemented with AGILE?

        I am now preparing more specific description of my thoughts about it.

        Best regards


      • Hi Jan,


        found this old discussion and clearly I was sceptic about agile in SAP Projects. Now after so many years I am fond of Scrum as a part of SAP Activate and even if I am forced to use any corporate proprietary method I am using SAP Activate and Scrum along!

        here my last blog post referring to my publication on SAP Press:




        • Hi Waldemar,

          I assume you and I are probably the only people looking at this blog post from 10 years ago. Thank you for a very nice comment - a lot of things changed in the past 10 years and while this blog post in 2011 might have sounded crazy, it is reality today for a many project teams. Hope you are staying safe and warm! Let me know if you need anything, we have a lot of new content and innovation in Activate. We never stop!

          Thank you again for a very nice words and I look forward to maybe meeting sometime some place when we can travel again...


          Best Regards, Jan