Coding in Concrete
When agilists who guide transformations get pulled into a SAP effort, they ass.u.me that everything they know of will apply.
- 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.
- 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).
- 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.