After the year I started the discussion:

And after gained voices in discussion like above and practical project experiences as well it is the right time to make some kind of summary. I like to present it in a few short articles about practical aspects of the use of Agile on SAP projects.

First I like to say IMHO that I can understand today’s trend to name Agile approach as better than waterfall – Agile approach has become the buzzword and that is natural and “trendy” now. For professionals however it should be clear that Agile is complementary approach to waterfall and both of them have pros and cons. Like I wrote already in one of my previous posts:

Agile and waterfall can be presented like extremes on line between safety and creativity. According to the set of best practices described in PMP or in the PRINCE2 methodology this is the job for project manager to engage the most optimal method what means to decide where to put the balance between them both on the project to organize the work in most optimal way. That means that for various circumstances and depending on the subject of the project the balance can be set on different points on that line. And this is the logic behind the ASAP 8 Agile methodology from ASAP – the hybrid method that allows to mix waterfall and Agile approaches in the most optimal way on the SAP projects.

While the characteristic of Waterfall is very well known the help in looking for the most optimal position of Agile approach can be found of course in the Agile Manifesto:

where we can find 4 sentences known also as values, as well twelve principles.

Looking on the sentences – for example:

“Working software over comprehensive documentation”

doesn’t mean It shouldn’t be documentation at all on the project – as I observe sometimes! Please find the closing sentence of four values:

“That is, while there is value in the items on the right, we value the items on the left more.”

so you can see Agile Manifesto is positioning also as some kind of compromise on the balanced line with the point set more on the left side as in Waterfall what is clearly to seen in the sentences on the right.

And coming back to the SAP projects: it is hard to believe that on wide ERP project SCRUM or XP can be apply as the main methodology – from obvious reasons like I wrote in:

especially with expected “working software” at the end of each sprint.  But SCRUM may be successfully applied by ERP implementation by subprojects  or in some part of it (like interfaces development) where the conditions will be adequate. However there are very interesting results by using SCRUM-similar timeboxed (like weekly) defined Work Packages:

That means Waterfall as the main framework but the work during the whole project organized SCRUM-like (with the all stuff like artifacts and terminology).

But beside of ERP all other SAP components are very good or even perfect subjects of Agile approach. The Business Intelligence components can be perfect subject for SCRUM application. Another example is SAP E-Recruitment component:–working-prototype-can-be-built-very-fast

For both of them making more than the lean blueprint is simple waste of time and money and for both of them even SCRUM can be applied.

In my next point I will comment right the above named value form Agile Manifesto – blueprint as a form of contract between parties for the project delivery.

I will contnue.

To report this post you need to login first.


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

  1. Paul Hardy

    Every major SAP implementation I have been involved with used a waterfall approach, and in every case if you were to have a look at the very detailed requirement documnets drawn up in the “planning and prepration” stage at the start, and try to find some points of similarity with the working productive system a few months after go-live you would be struggling.

    Sometimes there are cataclymisc events midway through the project – a takeover perhaps, where the year end changes and all the base assumptions (this never happesn, that never happens) are now incorrect – but more often the problem is the difference between what people say they want and what they actually do want.

    Whatever approach you use, the ultimate test of a project – as indeed of a picece of software – is it’s ability to deal with radical change without cracking like an egg.

    If you have a project to install a smart card system for the bus newtork, and 75% of the way through you are told – oh and can you extend this to trains also, and by the way don’t bother with buses any more, this will just be for trains – do you have to start again at the beginning?

    I notice SAP itself has chosen the agile approach for the relaese of the SAP 740 version of the GUI  i.e. do no testing, release something that does not work, and then change it based on user feedback.

    1. Waldemar Falinski Post author

      Dear Paul,

      thank you for your comment, you are touching as I see two or maybe even three major things::

      1. the “old school” waterfall contract versus the ability to change caused by learning of the organization during the project;
      2. do the organizations like to learn (and that may be the reason to use agile approach) or simply like to have executed that was specified on the beginning even if that may become stupid as conclusion of the project execution?
      3. the pressure on the project scope caused by change of the business environment but also by learning (your example with busses and trains) – known also as scope creep.

      That all are about the contract and that will be my next post about (or posts since it is the main point of conflict in the battle waterfall vs. Agile).



Leave a Reply