Vele bedrijven hebben ook regelmatig een gefaald verbeterproces achter de rug. In de testwereld gaan bijvoorbeeld vele verhalen van gefaalde testautomatiseringsprojecten. Maar ook testers, die worstelen om van T-Map waterval naar een Agile manier van testen te gaan. Exploritory testing, dat in de praktijk betekend dat iedereen maar wat doet. Een achterstand in regressietesten, in wat voor vorm dan ook, omdat de kennis van het product niet voldoende is om ook maar te starten. Een belangrijk aspect voor het falen "Ik heb geen tijd" wil ik even buiten deze blog laten. Als je de tijd wel krijgt, wat dan?
Ondanks de waardering voor Agile, zijn verbeterprocessen meestal nog heel erg waterval. Een, twee, maximaal drie mensen gaan samen als team het hele verbeterproces op papier uitwerken. Of een geheel automatiseringsproject wordt gebouwd door een of twee experts. Deze personen zijn vaak ingehuurd en/of deel van het management. Soms, als je gelukt hebt, aangevuld met iemand uit de praktijk van het bedrijf. Het contact met de mensen, die werkelijk moeten gaan werken met de verbeteringen, is zeer beperkt. Zo niet volledig afwezig. Als het traject volledig is uitgedacht of de automatisering volledig is gebouwd, wordt het met een grote big bang gestart. Vaak wordt in één keer een grote groep wijzigingen doorgevoerd. En de automatisering wordt in één keer in productie gezet. Dan zijn de experts klaar. Soms is er nog een beetje tijd voor de eerste begeleiding. Maar al snel gaan de externe experts door naar een andere klus en de interne experts weer door naar een ander project of volledig terug naar hun dagelijkse werk.
Hoewel de testers en eventueel ontwikkelaars weinig keus hebben, zie ik ze in dit proces wel als de klanten. Zij zijn, hoe vrijwillig of onvrijwillig ook, de personen die de verbeteringen afnemen. Die ermee moeten werken. En met grote regelmaat zijn zij ontevreden. Het fantastisch bedachte automatiseringsproduct kunnen ze niet onderhouden. Er wordt van de gevraagd om hun oude gewoontes weg te gooien, voordat de nieuwe zich bewezen hebben. Evalueren is vaak geen optie, net zo min zijn aanpassingen bespreekbaar. Want het project is eigenlijk al afgerond. Wat laatste klusjes kan misschien nog, maar verder houdt het op.
Als we het niet meer vreemd vinden dat waterval automatiseringsprojecten falen? Waarom zijn we dan nog steeds verbaasd dat waterval verbeterprojecten falen? En waarom zoeken we in de eerst situatie de oorzaak vaak bij de leverancier en in de tweede situatie vaak bij de "klant"?
Hoe moet het dan?
Er zijn drie belangrijke principes, die ik aanhoud, ongeacht of ik test of verbeter:- Het belangrijkste moet het eerst
- Er moet zo snel mogelijk resultaat zijn
- Er moet draagvlak zijn
Het belangrijkste moet eerst
Waar dit eigenlijk op neer komt is dat je een backlog maakt. Een lijst met problemen en/of een lijst met zaken die geautomatiseerd moeten worden, geprioriteerd op belangrijkheid. Een goede backlog is van groot belang. Daarom is het verstandig om juist hier al uitgebreid met de "klant" te praten. Welke problemen zien zij? Wat willen zij bereiken met automatisering? Is er eerder een project geweest, dat faalde? En zo ja, waarom denken zij dat het faalde?Als in de backlog de belangrijkste problemen van de "klant" niet hoog staan, is de kans groot dat je project faalt. Ten eerste, omdat je "klant" niet zal geloven dat het gaat werken. Hun grootste problemen worden namelijk niet opgelost. Ten tweede, omdat je "klant" kennis en ervaring heeft, die jij mist. Deze zomaar negeren, leidt meestal niet tot een betere oplossing.
Hier is wel een groot verschil met verbeteringen op organisatie niveau en testverbeteringen. Bij grote verbetertrajecten geldt vaak het argument "Ik kan toch niet iedereen betrekken". Maar als je het hebt over testverbeteringen, gaat het vaak niet over groepen testers van 30 man of meer. Iedereen erbij betrekken, of anders minimaal iedereen erbij betrekken die wil, is daarom eigenlijk bijna altijd wel een optie.
Er moet zo snel mogelijk resultaat zijn
Zo snel mogelijk resultaat is een moeilijke stap en te uitgebreid om hier tot in detail te bespreken. Er zijn echter wel twee zaken, die je moet loslaten, voor dit een echte optie wordt. Ten eerste moet je er niet naar streven het project zo snel mogelijk af te ronden. Dit leidt vaak tot een situatie waarin je met zo weinig mogelijk mensen en overleggen probeert om zo veel mogelijk zo snel mogelijk te bedenken, schrijven en programmeren. En het snelst werk je nu eenmaal in je eentje, in een kamer, met de deur op slot, waar je alles achter elkaar kan doen. Als het klaar is, kom je dan de kamer weer uit. En is het zoveelste waterval project afgerond.Ten tweede moet je de gedachte loslaten dat invoering pas zinvol is, als alles is bedacht en afgerond. Als je de belangrijkste testen heb geautomatiseerd, kunnen deze al meteen hun waarde bereiken. Als je voor de belangrijkste problemen een oplossing hebt bedacht, dan kan dit je "klant" al flink helpen. Zelfs als de rest nog in de pijplijn zit. Je kan nog niet alles automatisch testen en niet al je problemen zijn opgelost. Maar alle kleine beetjes helpen.
Er moet draagvlak zijn
Als er draagvlak is voor de verbeteringen, dan is men bereid zich daarvoor ook in te zetten. En om de verbeteringen echt een kans te geven. Wanneer je bovenstaande voor elkaar hebt gekregen, dan het je op twee punten vaak al hulp voor draagvlak bij de "klant": hun belangrijkste problemen worden snel opgelost en ze zien dat het project wat oplevert. Door de eerdere oplevering, kan je je "klant" nu ook betrekken bij evaluaties en verbeteringen. Het project loopt nog, dus als er echt iets is, dan kan dat in de backlog worden opgenomen. Als het belangrijker is dan een stukje "nieuwbouw", dan pak je het dus ook eerder op dan de "nieuwbouw".Maar er is nog een belangrijke manier van werken om het draagvlak te vergroten: maak niet alle keuzes in je eentje of met je team. Draagvlak is vaak te herkennen, wanneer men niet meer spreekt over "hun project", maar "ons project". En één van de eenvoudigste manieren om van "hun" naar "ons" te gaan is: laat ze hun eigen bijdrage aan het project leveren. Kies hiervoor momenten, waarin de keuzes niet gaan tussen "goed" of "slecht". De mogelijke opties leiden altijd tot een goede weg, alleen de ene wat beter dan de ander. Hierbij is wel belangrijk: je moet bereid zijn om de slechtere keuze te accepteren. Mijn ervaring is: een slechtere oplossing met draagvlak heeft een beter effect dan een betere oplossing zonder draagvlak. Omdat in het tweede geval de inzet, het vertrouwen en het geloof in de oplossing zullen ontbreken. Wat regelmatig zorgt voor een "self fulfilling profecy".
Nee, dit is niet alleen een techniek om iedereen blij te houden. Je resultaat zal er ook flink beter van worden. De verbeteringen zijn vaak op initiatief van een manager, scrummaster, testcoordinator of senior tester. En met grote regelmaat ook op initiatief van iemand die vrij nieuw in het bedrijf is. Hoe veel deze personen ook zien, ze zien zeker niet alles. Ze weten niet alles, ze horen niet alles. Hoe is het om als junior tester in dit bedrijf te werken? Welke problemen loop je tegenaan als je wil groeien en leren? Grote kans dat je verbetertraject dezelfde problemen gaat ondervinden. Dus waarom zou je een junior tester niet betrekken bij je beslissingen over leer- en overdrachtstrajecten? Bijna elke groep heeft een of meer "vertrouwenspersonen", een persoon waar mensen zeer snel naar toestappen als ze problemen hebben. Zij kennen de organisatie vaak beter dan de officiële managers. Dus waarom zou je ze niet betrekken bij besluiten over informatiebijeenkomsten en andere communicatiemiddelen? Om de meest logische categorie "ze hebben gewoon van hun vakgebeid heel veel kennis, meer dan jij" nu eens niet als eerste te noemen.
