Agile

“We krijgen geen vertrouwen om zelfsturend te zijn en dat is de reden waarom we niet aan onze sprintdoelstellingen voldoen”. Die kreet heb ik de afgelopen jaren regelmatig gehoord vanuit de teams waarbij ik als test/agile-coach betrokken ben geweest. Maar zelfs als dat vertrouwen werd gegeven, viel kort erna op dat de sprintdoelen opnieuw niet werden gehaald. Ze werden zonder pardon doorgeschoven naar een volgende sprint, of die erna. Hoe komt het dat teams moeite hebben om hun verantwoordelijkheid te nemen, en wat kun je daaraan doen? Dat is even eenvoudig te beantwoorden als op te lossen.

Om maar gelijk met de deur in huis te vallen: de voornaamste reden is dat teams simpelweg niet weten waarvoor ze ‘het’ doen. Ze hebben geen antwoord op de vraag ‘Waartoe zijn wij op aarde?’.  Slechts eenmaal ben ik een team tegengekomen dat wél verantwoordelijkheid nam voor opgeleverde zaken. Dat zorgde voor tijdige en kwalitatief hoogwaardige producten, behaalde sprintdoelen en gemotiveerde teamleden.

Het team werkte nog niet lang met elkaar samen en bevond zich in de ‘norming’ fase, zoekend naar goede werkafspraken, rolverdelingen en gedeelde doelen. Als testcoördinator had ik de taak om testen een plaats te geven binnen het team en de bijbehorende werkzaamheden. Al gauw ontpopte ik me tot de tot dan toe afwezige scrummaster en coach op het gebied van Agile/Scrum werken en denken.

“Teams die hun verantwoordelijkheid nemen, worden steeds autonomer”

In refinement sessies werd het team richting de Product Owner en andere stakeholders kritisch wanneer dat nodig was, en meegaand wanneer het goed ging. Tijdens reviews waren ze in staat om (bijna) alle klanten mee te nemen in de gehele klantreisoplossing en niet enkel de oplossingsrichting van het team. Ze escaleerden tijdig wanneer ze een sprint niet haalden en gaven aan welke acties ze zouden ondernemen om dit in de toekomst te voorkomen. In retrospective sessies daagden ze elkaar uit te (blijven) begrijpen waarom ze dit deden. Dat zorgde ervoor dat ze sneller bereid waren verantwoordelijkheid te nemen, wat weer leidde tot meer autonomie voor het team.

Storming

Helaas komt een situatie als deze in de praktijk weinig voor. Dat merkte ik al snel toen ik als test/agile-coach aanhaakte bij een team dat al langer samenwerkte. Dit team zette – onder druk van de product owner – altijd meer punten in dan ze waar konden maken. Doelen werden continu doorgeschoven naar een volgende sprint en afstemming met klanten was er nauwelijks. De product owner had daar vreemd genoeg geen problemen mee.

In eerste instantie dacht ik dat disciplinaire straffen zouden helpen om het gedrag van het team te veranderen. Toen ik het team plotte op het Tuckman-model kwam ik echter tot de conclusie dat het zich bevond in de ‘storming’ fase. Er was een echte pikorde, waarbij twee personen bepaalden welk werk er gedaan werd. Na een aantal retrospective sessies en een sessie waarin ik ze heb meegenomen in het Tuckman-model kwam het team gelukkig tot dezelfde conclusie.

Na de sessie zijn we gaan werken aan het verkrijgen van een baseline voor wat binnen een sprint gedaan kan worden. Daarnaast hebben we alle teamleden meerdere rollen gegeven. Dat zorgde voor kleinere achterstanden en wederzijds respect voor elkaars werk. Het team bewoog richting de normingfase en de output steeg.

“Teamleden moeten van elkaar begrijpen waarom ze doen wat ze doen”

Desondanks hebben we het niet voor elkaar gekregen om in een continue stroom de doelen te halen. Zodra het ook maar één keer misging, kreeg de buitenwereld de schuld. Zelf heb ik geleerd dat teams eerst intern met elkaar moeten samenwerken. Ze moeten door onderlinge communicatie beter van elkaar begrijpen wat ze doen en welke waarde dit heeft. Een team dat alleen met zichzelf bezig is en niet naar het grotere plaatje kijkt, zal nooit in staat zijn om autonoom te werken.

Trots

In mijn meest recente opdracht ben ik als DevOps-coach gevraagd om Agile werken en denken te introduceren. Met het bovenstaande in het achterhoofd ben ik gestart om een team samen te stellen en leden te vragen waarom ze eigenlijk doen wat ze doen. Die input hebben we gebruikt om onze doelen, klanten en werkwijze vast te leggen en om doelgericht met elkaar te communiceren. Het team was gelijk in staat om aan te geven aan klanten waarvoor ze iets deden en welke waarde zij in het klantproces leverden.

Ook konden ze tijdens sprint reviews precies de juiste klanten uitnodigen en tijdens refinement sessies de juiste repliek te geven (wanneer nodig) met de juiste teamleden. Betekent dit ook dat het team al optimaal werkt? Nee. Ze worstelen nog met elkaar over wie, wat, wanneer doet. Houden ze zich aan aan de ‘voorgeschreven’ werkwijzes en spreken ze elkaar daar altijd op aan? Ook niet. Maar ze zijn wel zijn trots op hun werk en nemen hun verantwoordelijkheid. En dat is wat mij betreft het belangrijkst.

Wil je ons nieuwste Paarsz magazine per post ontvangen? Laat dan je gegevens achter.

Bartosz_Header_004

Werken bij Bartosz?

Vincent Verhelst

Geïnteresseerd in Bartosz? Dan ga ik graag met jou in gesprek. We kunnen elkaar ontmoeten met een kop koffie bij ons op kantoor. Of tijdens ontbijt, lunch, borrel of diner op een plek die jou het beste uitkomt. Jij mag het zeggen.

Bijtanken bij Bartosz

Gamification

Jan25

Software testen is geen handwerk maar keihard denkwerk. We maken een mentaal model van hetgeen we aan het testen zijn en aan de hand daarvan gaan we op zoek naar hoe we dat model kunnen kraken. Belangrijke skills die je hierbij nodig hebt zoals Critical Thinking en Problem Solving kun je ontwikkelen.

Ben je in staat om je analytische vaardigheden in te zetten om een puzzel op te lossen of een algoritme te kraken? Kun je onder woorden brengen wat de oplossing was? En wat was je aanpak was om de uitdaging aan te gaan?

Zo kennen we verschillende vormen van Gamification binnen het testvak. De eerste Bijtanken bij Bartosz van 2019 laat zien welke spelvormen we daarbij inzetten en waarom we daar zoveel waarde aan hechten. Maar we gaan vooral ook doen!

Mijn Paarsz