Agile SAP: waar is hier de nooduitgang?

Agile SAP- dat lijkt een contradictio in terminis, zo bleek tijdens de ronde tafel discussie over dit onderwerp in oktober 2014. Het bleek echter ook mogelijkheden te bieden voor kwaliteitsverbeteringen, kostenbesparingen en versnelde realisatie van SAP-functionaliteit. Als je dat toch eens wil toetsen, waar begin je dan? En hoe past Agile SAP in het grotere plaatje? Waar is de voordeur en, eventueel, de nooduitgang?

Beginnen met Agile SAP begint, heel verrassend, bij het begin. Het volgende voorbeeld uit de praktijk laat dat zien. Een grote SAP-gebruiker had besloten om een pilot te gaan doen met de Agile SAP aanpak. En niet zo maar een project, dit project stond op de radar bij het bestuur en had een budget van een paar miljoen euro. Als we het dan doen, dan ook meteen goed, zo was de gedachte. Het geformeerde Agile-team was voor een klein deel al bekend met Agile SAP en de rest werd getraind in de aanpak. Op de achtergrond stond een Agile SAP Coach klaar met raad en daad. So far, so good.

Boven water

De requirements kwamen boven water tijdens gefaciliteerde workshops. Die requirements werden uiteraard omgevormd tot nette ‘user stories’, verzameld in een ‘product backlog’. Prioritering van de user stories werd echter gedaan op basis van bij elkaar horende functionaliteit en niet op basis van meest toegevoegde waarde voor de business. Dat was niet nodig want de ‘product owner’ wilde toch alle functionaliteit in een grote big bang opgeleverd hebben… En daarmee was dat wat Agile Agile maakt, overboord. De enige variabele in het rijtje scope, tijd, budget en kwaliteit is namelijk, jawel, scope. Richt je eerst op die werkende software, waar de business echt om staat, of zit, te springen.

Ook over de niet-functionele requirements zoals het integratieplatform, de toegangsbeveiliging en de technische infrastructuur was nagedacht, zo bleek uit de SAP Solution Architecture documentatie. Prima – ook dat die niet-functionele kant is uitgewerkt in de Solution Architecture – maar de niet-functionele requirements ontbraken in de product backlog. Wat niet alleen handig is voor de Sprint-planning vanwege de afhankelijkheden. De rol van de product owner moest in dit geval behoorlijk aangescherpt worden. Prijzenswaardig was wel dat er een SAP Solution Architecture-document opgesteld was. Dat is niet per se gebruikelijk in de Agile-wereld, maar wel bittere noodzaak in de Agile SAP-wereld. Tot slot was er nog even niet nagedacht over hoe SAP-testers en -documentalisten een rol gingen krijgen in het traject.

Heeft een projectmanager eigenlijk nog wel wat te doen vraag je je af, als het Agile SAP-team werkt op aangeven van de product owner en gestuurd wordt door de Scrum-master? Jazeker heeft een project manager nog wat te doen. Die is verre van overbodig en al helemaal niet als er ook nog sprake is van procesherontwerp. Denk maar aan het voorbereiden van de overgang naar nieuwe manieren van werken en het bijwerken van procesmodellen en rolbeschrijvingen.

Maar uiteraard zijn daar ook nog het organiseren van training en communicatie, stakeholder management, SAP-rollen, profielen en autorisaties, infrastructurele en platformvoorzieningen, de technische overgang naar een nieuwe omgeving, migreren van geschoonde en ontdubbelde data, nadenken over master databeheer, integratie en regressietesten, het voorbereiden van de helpdesk op de nieuwe oplossing en de overdracht van kennis naar de beheerorganisatie – ook in het geval van DevOps – om maar wat te noemen.

Deur wagenwijd open

Goed. De deur naar Agile SAP-projecten staat nu wagenwijd open. Maar hoe past een Agile SAP-project in het grotere plaatje? Projecten kunnen immers deel uitmaken van programma’s. En beheerd worden binnen het programma- en projecten-portfolio. En dit portfolio moet weer gevuld worden met relevante projecten zodat niet, zoals Frans de Roy dat verwoordt in het VNSG Magazine van september 2014, ‘kritiekloos alle mooie nieuwe spullen van SAP’ naar binnen geschoven worden. Voor die projecten in het portfolio moeten sponsors zijn, die de projecten financieren zodat de Agile Release Trains in beweging kunnen komen en blijven.

Naast projecten die it-functionaliteiten opleveren zijn er bijvoorbeeld ook nog projecten als een SAP release upgrade, een transitie naar een andere it-beheerpartner, of naar andere hardware. Hoe je Agile SAP kunt opschalen naar het niveau van portfolio management is heel goed neergezet in het Scaled Agile Framework (SAFe) – SAP S/4Hana met SAFe4SAP dus. Maar daarover meer op een later tijdstip.

Oh, de nooduitgang? Die is altijd aanwezig tijdens de ‘retrospectie bijeenkomst’. Als Agile SAP echt niet werkt na een aantal Sprints, dan kun je als team besluiten om de stekker er uit te trekken.

Meer weten? Neem dan deel aan de tweede Ronde Tafel Agile SAP op 4 maart 2015 en discussieer mee.