When agilists who guide transformations get pulled into a SAP effort, they ass.u.me that everything they know of will apply.

1. The first problem is that SAP isn’t a normal programming language… it’s a combination of configuration and small bits of code.  The toolset has no natural “undo” and the complexity of business requirements demands multiple specialists.
2. The second problem is that the SAP industry celebrates the specialists; rewarding the experts with the highest bill-rates.  Generalists are seen as unfocused and generally aren’t common.  This is in conflict with the agile approach of fungible team members (not even getting to developers helping out testers).
3. The third problem is that SAP works with “process sets” not features – this is a subtle shift but aligns better to SAFe 4.0’s “value streams” approach more than traditional agile product breakdown.

I remember walking a thought-leader from the Agile community through the challenges separating Agile for SAP from the traditional challenges of agile transformations.  He left the room looking green and didn’t say a word.  I later heard from his company’s COO that he left to place a call indicating extreme concern over the viability of the effort.  Luckily for the client, we knew these things in advance and didn’t need to learn them all over again.