Het belang van Agile teamontwikkeling

Als Agile coach help ik teams met hun Agile werkwijze. Op professionele wijze Kanban of Scrum inzetten om zo problemen op te lossen, prettig te werken en resultaat te boeken. Maar minstens zo belangrijk is de team effectiviteit zelf: de communicatie, de samenwerking…Ook hier moet volop aandacht voor zijn.

Hoe werkt team effectiviteit?

We hopen allemaal dat we productief kunnen zijn in een team. En de meeste teamleden zullen echt gemotiveerd zijn om werk uit te voeren dat gedaan moet worden. Maar systemisch gezien werkt het niet zo gemakkelijk. In het systeem (in dit geval het team of de organisatie) ontstaat gedoe. En zo lang dat ‘gedoe’ onderwater speelt, staat dat het team in de weg om zijn doel te bereiken. Het is dus belangrijk dat het team dit gedrag gaat herkennen en hiermee aan de slag gaat.

Maar als je er zelf middenin zit, is het vaak lastig om er uit te komen. Dan is het fijn als een manager, een Scrum Master, een coach of een proactief teamlid aanbiedt om het team te helpen. Ik geef wat voorbeelden uit mijn eigen praktijk:

1. Nieuwe team samenstelling

Een organisatie besluit om de structuur van de Marketing afdeling te wijzigen, waardoor nieuwe teams ontstaan. Ik ben bij een opstartworkshop met één van die teams. Als ik vraag hoe ze het vinden om met elkaar een team te vormen blijft het lang stil. Een aantal mensen kijkt naar de grond. Iemand begint te praten, maar vertelt vooral wat hij in zijn vorige team heeft gedaan. Niemand sluit bij zijn verhaal aan. Gelukkig start de manager met het erkennen dat het wennen is om zomaar in een nieuw team terecht te komen.

Ik mag een volgende workshop faciliteren en besluit om aan de slag te gaan met het definiëren van het gezamenlijke doel van het nieuwe team. Ik vraag hen om individueel te bedenken en vervolgens met elkaar te delen wat hen drijft in hun werk. Als mensen vertellen over hun drijfveren, beginnen hun ogen te sprankelen. Er ontstaat energie en mensen beginnen elkaar vragen te stellen en aan te vullen. Zodra dit contact bewerkstelligd is, vraag ik het team om gezamenlijk op zoek te gaan naar de gemene delers in hun drijfveren. Zo weet het team om tot een gezamenlijk teamdoel te komen. Overigens met ruimte voor de verschillen die er ook wel degelijk zijn.

2. Developers in de weerstand

Ik woon een Daily Scrum bij die erg stroef verloopt. De developers delen maar mondjesmaat waar ze mee bezig zijn. Ik hoor vooral:

“Nee, ik werk niet aan iets dat invloed heeft op jullie werk.”

“Hier ben ik nog mee bezig, dit loopt.”

“Het kost mij meer tijd om de post-it te schrijven dan om het werk uit te voeren, dus ik zet het niet op het bord.”

Op het eerste gezicht denk ik dat ze vooral niet willen delen met elkaar. Maar als ik doorvraag blijkt dat er meer achter zit. Er is grote terughoudendheid om kennis met elkaar te delen, want kennis is macht. Daarnaast is er sprake van angst en onzekerheid. Developers twijfelen aan de kwaliteit van hun eigen werk én aan hun Scrum kennis.

Door rustig met het team te spreken en in te gaan op deze weerstand, angsten en onzekerheden ontstaat er ruimte. Het team wil graag een opfrisdagje Scrum en kiest er vervolgens voor om in gezamenlijkheid het sprint doel vast te stellen en de Sprint Backlog te creëren. Daardoor is er veel meer samenhang in hun werk en ontstaat vanzelf de noodzaak én de wil dit met elkaar te delen.

3. Wij zijn ok, zij zijn sukkels

Een manager vraagt mij om hulp. Het team loopt aardig, maar het blijft nu al een tijdje hangen op een bepaald niveau. Bovendien wordt er irritatie geuit op de rest van de organisatie en overkoepelende werkwijze. Kan ik eens meekijken?

Ik woon één van hun Sprint Retrospectives bij. Het team is erg eensgezind over wat ze (zelf) allemaal goed hebben gedaan. De briefjes die hangen bij ‘wat kan beter’ gaan over grote thema’s. Direct uit het team ook zijn frustratie over het nut van een retro. Ze weten wat goed ging en de verbeterpunten zijn eigenlijk altijd dezelfde. En dus blijkbaar niet te veranderen… Kunnen we die retro niet maar beter skippen en gewoon aan het werk gaan?

Ik moet op mijn tong bijten om hen niet te (onder)wijzen op het nut van zelfreflectie en het doel van de Retrospective, maar besluit het anders aan te pakken. Ik vraag hen aan welk van de punten ze zich het allermeest ergeren. Daar zijn ze weer unaniem over. Het is het feit dat ze afhankelijk zijn van externe leveranciers. Vervolgens vraag ik elk individu naar hun meest concrete voorbeeld van die afhankelijkheid van één van de leveranciers. Die voorbeelden delen ze met elkaar en vervolgens gebruik ik de Liberating Structure 15% Solutions om hen een eerste aanzet tot de oplossing te laten bedenken die ze direct kunnen uitvoeren.

Dit triggert het team. Ze beseffen dat ze er vooral last van hebben dat teamleden op verschillende momenten contact hebben met één leverancier en dat daar elke keer iets anders uit komt. Hun oplossing is om de leverancier twee keer per week na afloop van de Daily Scrum uit te nodigen. Dit helpt niet alleen dat probleem oplossen. Het doet hen bovendien beseffen dat ze wel degelijk nog voldoende te verbeteren hebben én dat ze daar ook zelf invloed op hebben. En dat ze dat moeten doen in kleine stapjes. Het team wordt weer kritischer op het eigen handelen en raakt meer gemotiveerd om verder te groeien.

Hoe help jij je team verder?

Doen mijn voorbeelden je denken aan situaties in je eigen team? En gaan je handen jeuken? Mooi zo! Als jij je team verder wilt helpen is het handig om je eigen team eens te observeren. En te zien welk gedrag er plaatsvindt en welke patronen je ontdekt. Als je die patronen eenmaal hebt ontdekt kun je daar effectieve interventies voor bedenken.

In het Whitepaper Agile Teamontwikkeling publiceren wij een tool waarmee jij aan de hand van de theorie van Tuckman’s Stages of Team Development jouw team kunt analyseren. Zo krijg je zicht op waar jullie staan én handvatten voor slimme interventies. Heb je meer vragen? Vraag dan gerust vrijblijvend advies aan een van onze Agile coaches.