Iedere klant binnen vier maanden over op de laatste release

Deze drie hele belangrijke punten zorgen niet alleen voor een succesvolle overstap, maar zijn ook nodig zodat jullie de waarde van de nieuwste release zo snel mogelijk in kunnen zetten. Op basis van deze drie belangrijke feedbackpunten zijn wij aan de slag gegaan binnen ANVA en hebben we een aantal knopen doorgehakt.

Ondersteuning oude releases

Wat overeind blijft is dat we een half jaar na het uitgeven van de volgende hoofdrelease stoppen met het leveren van support op de vorige hoofdrelease. Een voorbeeld: leveren wij in januari de 53.P01.10 uit en in april de 53.P02.10, dan stoppen we in oktober (april + 6 maanden) met het ondersteunen van de 53.P01.10.

De reden voor deze keuze is heel simpel. Er verandert veel in de releases. Opgeloste fouten terug blijven brengen naar ‘oude’ versies brengt bovendien risico’s met zich mee. Door streng te zijn in de lengte van de support beperken we dit risico. Tegelijkertijd gaan wij werken aan de kwaliteit en betrouwbaarheid van de releasekalender om het jullie makkelijker te maken om te updaten. Wat we daaraan gaan doen, lees je hieronder.

Verbeteren kwaliteit

We zijn het helemaal eens met de feedback dat de kwaliteit van onze releases omhoog moet. Daarin maken we progressie, wat we terugzien in een dalend aantal incidenten op de laatste release. Dit komt doordat we strengere keuzes maken in de aanpassingen die we doorvoeren in ANVA 4/5. Als het dan alsnog fout gaat, doordat we een ernstig risico bij onze klanten voorzien, nemen we de pijnlijke beslissing een release terug te trekken. In dat geval gaan alle registers open op het gebied van actieve communicatie en het herstellen van het issue.

Sommige aanpassingen hebben een grote impact en een lastig in te schatten risico, daar zeggen we niet meer zo maar ja tegen. Daarnaast hebben we de afgelopen periode veel geïnvesteerd in ons team van testers en het schrijven van testscripts. Door vanuit het Klantdomein meer betrokken te zijn bij het schrijven van de scripts en de inrichting en data in de testomgevingen, halen we meer fouten vooraf al uit de releases.

Betrouwbare releasekalender

Ook als het gaat om het maken van de releasekalender voor 2024 zoeken we vanuit het Klantdomein meer en meer de samenwerking op met het Deliverydomein. We hebben afgelopen jaar veel gehoord dat we ons niet altijd aan de kalender houden; de betrouwbaarheid staat onder druk. We leveren releases en patches later op dan beloofd, doordat we meer tijd besteden dan verwacht aan het testen ervan. Het gevolg is dat jullie als klant een planning hebben gemaakt, medewerkers hebben ingepland voor testen en installeren en dat dit niet door kan gaan, doordat wij niet tijdig leveren. Dat levert heel begrijpelijke planningsproblemen en irritaties op.

Om dit te verbeteren denkt het Klantdomein vanaf nu mee in de releasekalender en geven onze productowners ook hun commitment op het halen van de releasekalender. In hun sprintplanning van volgend jaar hebben zij expliciet ruimte gemaakt voor het testen en opleveren van de releases en patches.

Nieuw is ook dat we de releasekalender met een aantal relaties hebben gedeeld en afgestemd om te toetsen of dit past binnen hun roadmaps voor volgend jaar. Hieruit is bijvoorbeeld naar voren gekomen dat we geen release meer in het vierde kwartaal van een jaar plannen. Zo werken we op alle fronten samen om een goede kalender neer te zetten, die aansluit op jullie planning en waarmee we tegelijkertijd een snelle upgrade cycle hebben.

Iedere klant binnen vier maanden over op de laatste release, dat is ons streven. Kwaliteitseisen en planning staan bovenaan, de scope van nieuwe functionaliteiten kan dan nog aan verandering onderhevig zijn.

Bekijk de kalender hieronder of contact me als je suggesties hebt? Ik hoor het graag.