Peer Conference Improve april 2016

Een mooi voorbeeld daarvan is de Peer Conference die we minimaal één keer per jaar organiseren. Een erg leuke, maar vooral leerzame manier om echte praktijkervaringen te delen en hierover te discussiëren. In een Peer Conference komen 10 tot maximaal 25 professionals bij elkaar om over hun ervaringen te spreken. Het doel is om elkaar te inspireren en te leren van elkaar met zogenaamde “experience reports”. Dit zijn verhalen en ervaringen uit je eigen praktijk, die je deelt met de overige deelnemers. We gebruiken hierbij dezelfde aanpak die men bij DEWT hanteert (an Experience Report guideline). Dit jaar was de bijeenkomst op 20 april.

De deelnemers brachten een pitch uit over het onderwerp waarna gekozen werd welke drie kandidaten daadwerkelijk hun experience report ten gehore mochten brengen. De eerste kandidaat deelde zijn ervaring wat voor invloed de Context-Driven training Rapid Software Testing op zijn huidige werkzaamheden heeft gehad. Hij vertelde met vol enthousiasme, zonder voorbereide presentatie, dat deze manier van testen tot een goed resultaat bij de klant heeft geleid en het past veel beter bij zijn manier van werken.

Na zijn betoog was er drie kwartier ruimte voor een gestructureerde discussie. Deze gaat als volgt:
Alle toehoorders hebben 3 kaarten die men omhoog kan houden. Een groene kaart om een vraag te stellen. Een gele kaart om een vervolgvraag op een eerder gestelde vraag te stellen. Een rode kaart om op een discussie in te breken omdat je een hele belangrijke mededeling hebt. De discussieleider houdt dit strak in de gaten zodat het een goede discussie blijft en waardoor iedereen een kans krijgt vragen te stellen en meningen en ervaringen te delen.

De tweede kandidaat zat met een dilemma in zijn testwerkzaamheden. Na het uitbrengen van een goed en degelijk advies over tekortkomingen aan het systeem wordt er op allerlei momenten in het vervolgtraject informatie gefilterd. Hierdoor wordt er toch vaak ingestemd om het systeem “live” te zetten met de toezegging om op korte termijn een aantal kritieke problemen te fixen. Vaak is die periode niet realistisch waardoor er “verbeteringen” moeten worden aangebracht. De kandidaat zit hier enorm mee, niet alleen voor hem zelf dat hij dat “duur” geld vindt maar ook voor Improve. Zou Improve hiervan gevolgen kunnen hebben als men vindt dat er geen degelijk werk is geleverd? Hopelijk hebben wij als collega’s hem overtuigd dat dit laatste zeker niet het geval is!

De laatste kandidaat wilde graag input op zijn huidige opdracht. Een klant wil vanuit HRM-oogpunt alle medewerkers gaan typeren onder een aantal competenties en kwalificeren van level 0 tot en met 5. Hierbij zit ook de competentie testen, waarbij de hulp van Improve is gevraagd. De vraag is simpelweg “Wat betekent nu elk level?”. Maar het antwoord is lastig. Men wil in de toekomst teams gaan samenstellen aan de hand van scores, dus bijvoorbeeld 3 ontwikkelaars level 3, 1 tester level 4, etc. De vervolgvraag is dan ook een opleidingsvraag, namelijk: hoe krijg je iemand opgeleid naar bijvoorbeeld. tester level 4.

Na deze uiteenzetting hebben diverse deelnemers input geleverd op zijn vraag. Er werd onder anderen aangedragen dat het een goed idee is om ook karaktereigenschappen mee te nemen door gebruik te maken van het model van Belbin. Bij Agile staat per slot van rekening de mens centraal. Er werd verder genoemd dat de Expertisegroep Agile bezig is om skills in kaart te brengen die nodig zijn bij een goed functionerend Agile team. Die zouden wellicht kunnen helpen. Omtrent opleidingen voor testers bij de klant werd aangedragen om vooral een training te geven die meteen toepasbaar is. In de discussies bleek dat er zowel voor- als tegenstanders waren voor de voorgestelde ISTQB Foundation training als basis.

In één avond zijn er drie totaal verschillende ervaringen en onderwerpen besproken. Dat maakt dergelijke avonden juist zo leuk en leerzaam maakt. Met je Peers leren van de praktijk om allemaal beter te worden in je vak. Daar kreeg ik weer energie van!