SAP Activate is alweer enkele jaren geleden geïntroduceerd als de opvolger van SAP ASAP. Waar SAP ASAP sterk gericht was op waterval implementaties zou bij SAP Activate het agile gedachtengoed geïntroduceerd worden en daarmee ook de scrum manier van werken. Echter, als je wat meer de materie induikt lijkt het er toch wel op dat er nog heel veel waterval componenten in SAP Activate zitten en dat Agile en Scrum er enigszins geforceerd aan toegevoegd zijn.
In dit blog gaan we in op waar de deze “botsingen” van beide werelden zien, waar we denken dat deze vandaan komen en wat de juiste balans in de aanpak zou moeten zijn.
Werkwijze volgens SAP Activate
Binnen SAP Activate wordt er op vele manieren verwezen naar het agile gedachtengoed en wordt de manier van implementeren/upgraden in sprints verdeeld. Meerdere teams werken in parallel aan verschillende (backlog) items om zo uiteindelijk tot een shippable product te komen.
Hier zitten meteen een paar zaken in die voor ons opvallend zijn. Immers, wat is het shippable product van een upgrade of een implementatie op SAP gebied? Zeker bij een upgrade lijkt het toch zo te moeten zijn dat het shippable product het eindproduct is. Het lijkt me dat je als organisatie niet heel lang in parallel op zowel het oude als het nieuwe systeem wil draaien? De aanpak zal dan ook (veelal) zijn dat het oude systeem in een “big bang” vervangen wordt door het ge-upgrade systeem. Bij een implementatie zal dit niet heel anders zijn, ook hier wil je als organisatie een compleet werkend systeem als vervanging van je bestaande systemen.
Is de waterval manier niet gewoon praktischer?
Als het nieuwe systeem nu het shippable product is waar zit dan de meerwaarde in werken met agile en scrum? Het is immers vooraf al bekend wanneer en met welke functionaliteiten het systeem live moet gaan. Kan je dus niet net zo goed alles op de waterval manier doen? Ons antwoord is dat het Agile gedachtengoed zeker goed is in te passen binnen SAP Activate en ook daar zijn meerwaarde zal hebben voor elke SAP upgrade en implementatie. De reden hiervoor is dat je kan afdwingen dat er vaker en eerder feedback komt vanuit de business community aan de hand van demo’s. Aan de hand van de feedback kan er bijgestuurd worden op zowel het product als proces wat de kwaliteit ten goede komt.
3 Sprint types in SAP Activate
Wat wij minder goed vinden passen binnen SAP Activate zijn de sprints. Het lijkt binnen SAP Activate meer dat een sprint een (ver) vooraf gedefinieerd work package is om tot een vastgesteld einddoel te komen. Dit zie je ook terug in de manier waarop de scrum teams binnen SAP Activate gestructureerd zijn. Eigenlijk alle rollen welke bij een SAP implementatie voorkomen zitten nu in een scrum team “geperst”. Voorbeelden van deze rollen volgens SAP Activate zijn:
- Business process expert
- Application consultant
- Developer ABAP
- Internal application consultant
- Application security expert
- Training materials developer
- Test case developer (grappig trouwens dat er wel test cases ontwikkeld worden maar niet uitgevoerd😊)
Deze rollen lijken wel heel erg op de rollen die je in de standaard watervalprojecten gebaseerd op ASAP zag. De waterval aanpak komt ook heel duidelijk naar voren in de drie sprint types welke door SAP Activate gedefinieerd zijn:
- Foundation sprint
In deze sprint wordt de basis configuratie ingeregeld. - Building sprint
In deze sprint wordt een product increment gebouwd - Firm-up sprint
In deze sprint worden tests uitgevoerd en bugs gefixed.
Dit gaat wel heel erg terug naar de standaard watervalaanpak.
Aan de hand van deze zaken lijkt het erop alsof SAP een soort van kunstmatige manier gezocht heeft om met een agile sausje de standaard waterval aanpak te vernieuwen. Wij kunnen ons niet aan de indruk onttrekken dat dit is gedaan om de bestaande aanpak meer van deze tijd te laten lijken.
Hoe kijken we als OrangeCrest tegen deze aanpak aan?
Uiteraard zijn wij voorstander van het agile gedachtengoed en dit betrekken op wat voor project dan ook is wat ons betreft een goede zaak. Wij zien die winst vooral in de snellere terugkoppeling en betere bijsturing. Dit gedachtengoed is ook prima binnen SAP Activate in te zetten via demo’s en korte feedbackloops om zo te waarborgen dat gedurende het project de systeemfunctionaliteit de kant op blijft gaan die de business wil. Het mag dus geen blueprint zijn welke gedurende het hele project vast staat. Je business en omgeving (bijvoorbeeld regelgeving etc.) verandert gedurende de looptijd van je projecten daar moet je op inspelen. Meer agile dan dat kan het niet worden.
Wij zijn geen voorstander van de sprints binnen SAP Activate. Deze geven een verkeerde weergave van de werkelijkheid omdat het eigenlijk gewoon work packages zijn. In plaats van Scrum gebruiken wij liever Kanban binnen SAP upgrades en implementaties. Via Kanban kan hetzelfde, zo niet beter, inzicht in de voortgang van het project gecreëerd worden. Kanban zal ook beter aansluiten bij de manier van projectmanagement die je bij een SAP implementatie/upgrade met een harde deadline zal hebben.
Call to action
Herken jij dergelijke zaken in jouw dagelijkse werkzaamheden binnen SAP trajecten of vind je dat Scrum juist wél aansluit bij SAP upgrades en implementaties? We horen graag jouw mening!
