Hoe je van een “acceptance phase” een “acceptance feest” kunt maken

Of ik het wilde horen of dat ik verkeerd stond afgesteld weet ik niet, een engineer had het onlangs over een acceptance feest. Nadat ik het verifieerde, bleek dat hij het over een “acceptance phase” had. Een periode na de sprint van de DevOps teams waar de acceptant aan de slag gaat. In die phase gebeurt er veel maar het wordt nooit een feestje. Waar gaat het mis?

Waarom die fase alle feestvreugde weghaalt

Hier een aantal redenen waarom het volledig mis gaat bij een acceptatie (test) fase van de software nadat je al klaar bent.
  • De acceptanten beginnen pas na te denken over wat ze willen nadat ze iets krijgen. Het gevolg is dat eindeloze aanpassingen nodig zijn in de volgende sprint.
  • Mensen die bij de demo de acceptatie hebben uitgevoerd, worden overschreeuwt door de mensen die werkelijk accepteren. Het mandaat en pikorde blijken totaal anders te lopen.
  • In de magere jaren waarin software van mindere kwaliteit werd opgeleverd, was een acceptatie test van dagen, zo niet weken, broodnodig om goede software naar productie te krijgen. Dit patroon is nog niet doorbroken.
  • Er is geen verbinding tussen wat in de sprint is gebeurd en wat daarna gebeurt tijdens de acceptatie testen. Dit heeft enorm veel dubbel werk tot gevolg.
  • Er ontbreken duidelijke acceptatie criteria waar naar toe gewerkt kan worden. Het programmeren wordt daarmee bijna een “wild guess”.

Een dubbele domper

Je snapt wel hoeveel frustratie dit bij de engineers oplevert. Deze frustratie is echter geheel wederzijds.
Opmerkingen van de acceptant zoals de volgende zullen met grote regelmaat zijn uitgesproken.
  • Ze snappen me toch niet,
  • krijg ik weer niet wat ik echt nodig heb,
  • waarom heeft dit zolang moeten duren,
  • hoe kan het toch dat ik elke keer weer moet aangeven wat ik echt wil hebben,
  • waarschijnlijk zullen er toch wel weer fouten inzitten.

Suggesties ter verbetering om er een feestje van te maken

Het is eigenlijk vrij eenvoudig om er een acceptatie feest van te maken. Daarbij moet je de fase achteraf wel durven los te laten. Hier een paar kleine suggesties om er een feestje van te maken.
  • Werk aan een wederzijdse overtuiging en drive om het daadwerkelijk anders en beter te gaan doen. Dit is van groot belang om een mini transformatie als deze door te maken.
  • Plaats de acceptant in het team zodat hij kan werken aan de acceptatie criteria voor de user stories in de volgende sprint.
  • Gebruik een testing tool als Concordion of een framework als Cucumber om de Acceptance Test Driven Development mogelijk te maken.
  • Doe de acceptatie tijdens de demo aan het einde van de sprint en daarmee en daarna gewoon door productie. De kwaliteit is goed en afwijkingen detecteer je met monitoring.
  • Creëer een continue groter wordende set aan automatische regressietesten op alle niveaus, van unit testen tot en met GUI testen.

Haal die slingers maar in huis

Waar moet ik starten hoor ik je denken. Gewoon bij het begin! Spreek je behoefte maar uit en stel een experiment voor. Je hebt niets te verliezen dus wat houd je nog tegen.

Je zult merken dat als je met 1 of 2 user stories start met deze manier van werken en denken dat je al heel snel verbetering ziet. Dit komt niet perse doordat de code nu per direct zoveel beter is. Het komt vooral dat je elkaar veel beter gaat begrijpen en samenwerkt. En dat alleen is al een feestje.

whatsapp meWil je een WhatsApp bericht ontvangen bij een nieuwe blog?
Stuur dan even een berichtje naar +31645112490