Introductie
Als je naar het begin van een transitie kijkt, is de cultuuromslag het meest lastige! We zijn ermee vertrouwd om met procedures en processen te werken, maar we zijn niet gewend om zelf de richting en aanpak te bepalen.
Vaak zie je eerst een enorm enthousiasme en toewijding. Vervolgens komen er wat obstakels en dan blijkt dat wat we afgesproken hebben niet het meest belangrijke is en het team nog niet helemaal op één lijn zit. In deze soort situatie zijn we geneigd om terug te vallen op de vertrouwde patronen.
Waarom slaagt de ene organisatie wel in de overgang en de andere niet? Ik heb mogen bijdragen aan een geslaagde transitie naar Agile/SCRUM en deel graag wat volgens mij de succesfactoren waren.
Die succesfactoren zijn divers en klinken wellicht onaangenaam. Het vraagt om een grote investering in tijd en geld, het vraagt om draagvlak binnen de hele organisatie, het vraagt om heel, heel veel energie en het vraagt om vastberadenheid.
Haalbare ambitieuze doelen en kleine stappen
Vanaf de introductie van “het nieuwe werken” wil een organisatie het liefst in maximaal één jaar een agile organisatie hebben staan: een hoge snelheid van opleveren, een goede kwaliteit, met één druk op de knop naar productie, geautomatiseerde builds, goede performance, alles goed onderhoudbaar en veilig, etc, etc.
Mijn stelling “Laten we nu eens 5% van die stip op de horizon realiseren” lokt de reactie uit: “Nou, bij ons moet het toch wel lukken om veel meer te bereiken, we hebben allemaal specialisten”.
Het is belangrijk om realistisch te zijn en de piketpalen zo te slaan dat tegenslagen niet leiden tot negatieve energie. Het hebben van de haalbare ambitieuze doelen en het maken van kleine stapjes in het realiseren ervan zijn vele malen belangrijker dan een vastomlijnd en doorgecommuniceerd plan.
Ruimte om te leren
De eerste sprints zal het team niet op tijd zijn in de sprints, zullen de schattingen veel discussies geven, is er onduidelijkheid wie wat oppakt. Kortom, veel lijkt 
uit de hand te lopen. Management denkt wellicht “Zie je wel: het team is niet in staat….”, “Mensen zullen te allen tijde… en dus zal ik altijd weer moeten ingrijpen en acties uitzetten”.
Nadat het een paar keer fout gegaan is, kunnen ook stakeholders de moed verliezen en is er snel de neiging om terug te keren naar het oude proces. “Daarvan wisten we wat er niet goed was”.
Het is heel belangrijk hierop te anticiperen. Breng in herinnering dat de oude manier van systeemontwikkeling niet bracht wat we wilden;“terug” is geen goede optie. De SCRUM teams hebben tijd nodig, moeten kunnen bijsturen door te leren van fouten. Door de focus te leggen op zaken die wel goed gaan en zelfs beter dan voorheen, en door samen met de teams verbeterideeën te vinden voor de aandachtspunten, groeit de motivatie van het team.
Door de teams continue de gelegenheid te blijven geven om zelf te bepalen hoe ze werken en alleen de mijlpalen aan te blijven geven, zal het team zich meer en meer gemotiveerd worden om het heft in handen te nemen en te blijven veranderen totdat doelen bereikt zijn. Ideeën geven aan het team is prima, maar behoed je dat je geen ontevredenheid uitstraalt als ze een ander pad willen volgen. Wel is het belangrijk om de teams duidelijk te maken transparant te zijn naar de stakeholders, zodat ze begrijpen waarom iets niet gelukt is.
Door dit te blijven herhalen, gaan de teams het ook zo ervaren en zullen ze steeds meer gemotiveerd en “self-empowered” raken.
Je geeft het team veel meer inspiratie met het op gezette tijden voorhouden van een spiegel, het blijven herhalen van de doelen en het stimuleren om iets nieuws te proberen en te falen.
Simpelheid is de kunst
Er zijn allerlei voorbeelden waarin het belangrijk is om simpel te beginnen.
Neem het vaststellen van de Definition of Done.
Maak er niet meteen een uitputtende lijst van, maar begin met 1 a 2 punten die haalbaar zijn! Dan bouw je op uit positiviteit en dat geeft het team een enorme boost om er in de loop der tijd steeds een puntje bij te pakken.
Zou je meteen beginnen met een uitputtende lijst met punten waar we voorheen ook niet toe in staat waren, dan zul je die het eerste halfjaar nog steeds niet kunnen realiseren…
Of het opzetten van testautomatisering.
Ga niet meteen de hele regressietest automatiseren. Hoe vaak verzandt zo’n grote exercitie niet in een niet werkende, slecht onderhoudbaar, of niet gebruikte testset.
Begin liever met het bouwen van een sanity test, waarbij je na iedere deployment kunt zien of alle benodigde processen en services weer up-and-running zijn. Deze testen kunnen heel robuust gebouwd worden, vergen weinig onderhoud nodig en kunnen na iedere deployment gebruikt kunnen worden en dus heel effectief zijn. En bouw vanuit die werkende basisset de regressietestset uit.
Durf te falen en individuen, interactie over processen en tools
Wanneer bepaalde stappen in een team door niemand gezet worden, dan kan angst om te falen in het spel zijn. Het is belangrijk om mensen met initiatief te steunen en te stimuleren. In een organisatie lagen eens alle bouwstenen voor een ketentest klaar. Niemand durfde het aan om dit door te trekken tot een ketentest. Een van de testautomatiseerders nam toch de uitdaging aan. In een sprint heeft hij een werkende ketentest opgeleverd. Tijdens de review begon het…
• “er missen wat functionaliteiten”
• “het is niet volgens de coding standards”
• “de foutafhandeling is niet voldoende informatief”
Meteen ben ik hierop ingehaakt, omdat dit juist een belangrijke mijlpaal voor het team bereikt was: deze testautomatiseerder had het toch maar gedaan. Natuurlijk bevatte deze geautomatiseerde ketentest, net als andere software, fouten. Ik heb de jongen echter complimenten gegeven met deze mijlpaal, aan het team aangegeven wat de overwinning van het team met deze geautomatiseerde ketentest was en hoe we gezamelijk de puntjes op de “i” konden gaan zetten. Binnen enkele sprints hadden we een aantal ketentesten geautomatiseerd, waren alle kanttekeningen weggewerkt, bespaarden we per sprint een dag regressietestwerk en draaiden we iedere nacht een gedeeltelijke regressietest.
Intiatief belonen zorgt er in een team voor dat men goed samenwerkt, elkaar stimuleert en is er een enorme motivatie!
Verandering is niet eenmalig
Eén van de kenmerken van een SCRUM-team is dat het zelfstandig een werkend product kan opleveren. Daarvoor heeft het idealiter alle disciplines in huis om dit te realiseren.
Bij een van mijn klanten waar een fors aantal SCRUM-teams samenwerkten aan één oplossing met wel 100 producten was het streven ook om dit zo te implementeren en te faciliteren..
Maar kun je verwachten in ketens van 100 applicaties dat SCRUM teams naast het ontwikkelen, testen en onderhouden van een of meerdere applicaties, ook de business processen van de hele keten goed genoeg kunnen doorgronden om goede ketentesten op te zetten en uit te voeren? Stel dat het antwoord “nee” is, moet je dan persé vasthouden aan het principe dat een apart ketentestteam niet mag bestaan? – “Want dat hoort niet in Agile/SCRUM?” We hebben het toch gedaan en dit team heeft veel ketenkennis opgedaan, heeft heel transparant met de stakeholders goede ketentesten opgezet, betrouwbaar uitgevoerd en door het afvangen van vele bevindingen voor productie het vertrouwen van de business in de development enorm verhoogd. De verschillende SCRUM teams kregen ook steeds meer inzicht vanwege de bevindingen van dit E2E team en de wederom versterkte samenwerking. Een andere belangrijke voorwaarde om in een lange keten succesvol te zijn, is dat ieder persoon, ieder team overtuigd moet zijn dat we of met zijn allen succesvol zijn of dat we met zijn allen falen, maar dat er geen tussenweg is. Ondanks dat de backlog van jou team ‘schoon’ is, is geen enkel team succes heeft wanneer willekeurig op welke plek in de keten de functionaliteit niet werkt.
Nu is het inmiddels realistisch om vervolgens de spelers uit dit E2E team de individuele teams weer in te laten vloeien. Voorwaarde is dat de kennis van deze personen goed geabsorbeerd wordt door het team en gewaarborgd blijft. Zo zijn er naast enige documentatie ook workshops opgenomen zodat anderen door middel van de gemaakte video’s de belangrijke ketenaspecten kunnen leren.
Kortom, verandering is de constante factor. Ook voor een organisatie als geheel moet je blijven zoeken naar verbetering. Het antwoord van morgen kan anders zijn dan het antwoord van vandaag….