Month: maart 2017

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

Andreas Prins
Acceptance Feest
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.

Dag manager, welkom parttime leider

Andreas Prins
managers_leiders_small
Zijn managers nog nodig als je bouwt aan autonome teams die veel keuzes zelf nemen? Moet er nog veel worden gemanaged als de teams het zelf kunnen?

In een organisatie transformatie waarbij je echt wilt verbeteren neemt het aantal managers af en het aantal leiders toe. Als ik zeg leiders heb ik het niet over een semantische vervanging van het woord managers. De rol verandert en de vraag is of jij een leider wordt.

parttime leiders

Eerst twee concrete voorbeelden om te ontdekken waarom managers afnemen en de leiders toenemen.

Managen van out of control naar leiden in control

Als ik terug denk aan hoe de status van ons “control framework” een jaar of 3 geleden was dan scoorden we in excel netjes groen. Onder de motorkap moest je niet altijd willen kijken. Het hing van geaccepteerde risico’s aan elkaar. Een geaccepteerd risico lost natuurlijk niets op.

Twee jaar geleden vonden we dit niet langer acceptabel en zijn we de dingen echt gaan oplossen. We deden dit met regelmaat nog wel te laat maar de geaccepteerde risico’s werden opgelost.

Hoe meer we de teams verantwoordelijk maakten hoe dieper in de systemen de problemen echt werden opgelost. Vorig jaar scoorden we bijna alles groen en werden risico’s items op tijd gesloten en ook nog eens echt opgelost. We zijn daadwerkelijk veiliger geworden in plaats van dat we de risico’s managen.

Van de positie in control zijn is de volgende stap in control blijven en nog verder verbeteren. Als leider dit vooruitzicht schetsen en doelen duidelijk maken helpt de teams het beter te begrijpen en daar actief aan bij te dragen. Een dagelijkse coördinatie en aansturing is niet langer nodig.

Het managen van het verleden is daarmee niet meer nodig en slechts het schetsen van de toekomst is voldoende om vooruit te gaan.

Managen van voortgangsrapportages voor vandaag naar leiden van de feature planning voor morgen

Hoeveel tijd besteed jij nog aan het opstellen of lezen van voortgangsrapportages om eens wat te noemen? Geloof me dit is echt een verspilling van ieders waardevolle tijd. Je kunt beter werken aan de voorspelbaarheid van je teams op korte en langere termijn. Als je daarnaast ook nog eens vaker het gesprek aan gaat met alle mensen om je heen wat nu werkelijk waarde heeft kun je starten met de feature planning. Continue reading →