Wie in de huidige tijd een willekeurige onderneming binnenstapt herkent het wel. Er wordt Agile gewerkt, bij voorkeur op de wijze die beschreven staat in het Scrum manifest. Hoe projecteer je die wereld van product owners, user stories, product roadmaps en stand-ups nou eigenlijk op een SAP implementatie?
De grootste uitdaging in dit verhaal is tijd, traditioneel zijn SAP projecten langlopend, implementatie slagen duren lang, moeten uitvoerig getest worden en dan heb je altijd nog de laatste hobbel, transporteren. Ik hoor regelmatig dat SAP projecten zich niet lenen voor sprints van twee tot drie weken.
Het tegendeel is echter waar, echter brengt zo’n korte iteratie wel een aantal problemen aan het licht die we in het verleden konden negeren; goed en efficiënt testen is een noodzaak geworden. Binnen de organisaties waar wij de afgelopen jaren werkzaam zijn geweest is dat helaas altijd een van de eerste dingen men gebruikt als sluitpost. Nieuwe (gewenste, niet noodzakelijk overeengekomen) functionaliteit gaat boven het vaststellen van stabiliteit en veiligheid.
Vanuit een scrum masters perspectief ligt hier dus een uitdaging, hoe begeleid ik mijn ontwikkelteam op dusdanige wijze dat we het testtraject handig onderdeel kunnen maken van de sprint. Een van de meest eenvoudige middelen die je daarvoor hebt is het opnemen van testen in de definition of done en het in kaart brengen van de gewenste functionaliteit in de definition of ready.