Why Agile transition for SAP projects is a high resistance path.

Why Agile transition for SAP projects is a high resistance path?
The hype around agile scrum is at peak. We have new roles like scrum master, product owner replacing the conventional project manager. Development teams are empowered like never before. Companies are hiring Agile coaches with a promise to transform existing waterfall projects to agile and with hope that project setbacks, delays, quality concerns etc. will be things of past. In this entire hype SAP projects (both new Greenfield and in-house enhancements) are in sate of fix. I am talking about SAP client companies running on SAP. On one hand there is immense pressure on them to move to agile from existing ASAP and on their other hand the Project manager who was recently trained in Agile scrum is finding increasingly difficult to apply his agile training learning to current SAP projects. So let’s decode the issue and try to identify where the problem lies.
Agile scrum methodology despite not explicitly mentioning it, is heavily tailored to product development projects. It fails to recognize that there is something called software implementation as well (e.g. SAP implementation) where focus is on implementing the pre developed product in your company. While most agile trainers consider that scrum methodology is equally applicable here as well, some even argue what difference does it makes for implementation? Well you should better ask the project manager turned scrum master trying agile transformation of his waterfall. Before we dig deep into it lets all understand that the software product to be implemented is not yours. All you have is its user license with right to use the product. While you can still do some enhancement to it, any significant change in the product is not acceptable by manufacturing company. Having set the context let’s now jump into the issues which make Agile scrum in it’s current form difficult for SAP projects.
1. Role of product owner –Most of the KRAs of PO may not be relevant or will have reduced significance. This happens because customer is captive, Product development is limited to some key customizations and backlog mostly comprises of  either legal requirements or highly integrated items. At times you may think do we really need PO or scrum master can double up as PO. Well Agile scrum disapproves such arrangement!
2. Customer interface – Here the customer is internal. He drives the demand in most cases. He knows exactly what he wants. All you need is to confirm if it can be met or not. In many cases his asks are legal requirement driven leaving you with hardly any scope of modification.
3. Product/features development – Since product is owned by third party, there is hardly any scope of significant product development. Limited customization can be done without changing the basic core. For example GUI of SAP for enhanced customer experience can be better taken up by SAP.
4. Backlog prioritization – Google “Product backlog prioritization methods in scrum” and you will get tons of articles and innovative methods of doing it. The sad part is none of them is applicable for SAP projects. Reason – Most of the backlog items are either highly interlinked or not independent (leaving sequencing them as the only option) or they are Government compliance based (like configuring system as per new tax rules etc.) which has to be done ASAP.
5. Independent shippable product –Objective of each sprint is to deliver an independent shippable product at the end so that customer gets an idea of things to come and risk of complete rejection in last leg is eliminated. This again is not easy to achieve in SAP projects. Due to high degree of integration it requires above average solution architect skills for product owner to design such sprints.
6. Continuous delivery – Not possible with SAP project following strict release management cadence for deployment. So sprints need to wait till next deployment cycle even if they are complete thereby reducing its effectiveness.
7. Most Agile practices like pair programming, Test driven development, Dev ops do not make much sense in SAP projects due to 80% of Dev is configuration where you do not change the codes.
8. Regression testing can be blocker as sap is extremely large highly integrated software making it difficult to assess the impact of code changes. This means we need to perform regression testing involving large set of standard scenarios for each sprint involving code changes. This is not easy unless you have really good automated regression suite ready.
You might be wondering do we really need agile scrum for SAP projects. Well many project managers have raised concerns and prefer to stick with waterfall. However we do need agile scrum for SAP projects as well, of course with some fine tuning. The value proposition is too much to ignore (self-managed team, reduced risk of quality, timelines and higher customer association to speak a few). So who should fine tune this? Ideally scrum should come out with guidelines for such projects. As of now it is left to the expertise of agile coaches. While expert ones are able formulate a workaround for this without compromising with core principles of scrum, others end up transforming scrum into multiple small waterfalls making the project as agile as Niagara Falls!!