Zelforganiserende teams – zo lukt het

Het vermogen om jezelf te organiseren is fundamenteel in alle agile methoden, inclusief Scrum. Zelforganiserende teams zijn zelfs een van de basisprincipes van het Agile Manifesto, dat stelt dat "de beste architecturen, eisen en ontwerpen voortkomen uit zelforganiserende teams".

Als het gaat om hoe een beoogd doel het beste bereikt kan worden, zullen sommige teams ervoor kiezen om de beslissingen over alle belangrijke technische vraagstukken aan één persoon in het team over te laten.

Andere teams zullen ervoor kiezen om de verantwoordelijkheid voor technische beslissingen langs technische grenzen te verdelen: de database-expert neemt de databasebeslissingen en de programmeur met de meeste ervaring met Python neemt de Python-beslissingen.

Weer andere teams kiezen er misschien voor dat degene die op dat moment aan een bepaalde feature werkt, de beslissing mag nemen, maar dat hij of zij de resultaten van die beslissing wel aan het team moet communiceren.

Niet elk agile team is op dezelfde manier zelforganiserend

Hierbij zijn er twee hoofdpunten:

• Niet elk agile team zal zichzelf op dezelfde manier organiseren, en dat is helemaal oké.
• Je kunt het werk beter organiseren als je de collectieve kennis van het team benut, in plaats van alleen te vertrouwen op de kennis van één manager.
  Het voordeel van zelforganiserende teams is niet dat het team een optimale manier van werken vindt die een manager vergeten was hun te laten zien. Het voordeel van een team de ruimte geven om zichzelf te organiseren is juist dat het team zich aangemoedigd voelt om zelf verantwoordelijkheid te nemen voor het uitvoeren van hun werk.

Kunnen we van agile teams echt verwachten dat ze zelforganiserend zijn?

Een veelgehoorde kritiek op zelforganiserende teams is: „We kunnen niet zomaar acht willekeurige mensen bij elkaar zetten, ze vertellen dat ze zichzelf moeten organiseren, en dan een positief resultaat verwachten."

Tja, ik weet niet zeker of het niet sowieso problematisch is om acht willekeurige mensen bij elkaar te zetten en een positief resultaat te verwachten, maar een agile team zou hoe dan ook niet uit een willekeurig samengeraapte groep mensen moeten bestaan. Degenen binnen het bedrijf die verantwoordelijk zijn voor het opzetten van een Scrum project zouden de individuele teamleden zorgvuldig moeten selecteren.

Het management oefent subtiele controle uit over de zelforganisatie

In het originele paper over Scrum, The New New Product Development Game, benoemden Takeuchi en Nonaka „subtiele controle" als een van de zes principes. Personeelsbeslissingen worden genoemd als een van de belangrijkste verantwoordelijkheden van het management.

De juiste mensen voor een projectteam selecteren en tegelijkertijd veranderingen in de groepsdynamiek in de gaten houden, en indien nodig teamleden toevoegen of uit het team halen, is een van de belangrijkste verantwoordelijkheden van het management.

„We voegen een ouder en wat conservatiever teamlid toe aan het team als het team te radicaal dreigt te worden", legde een manager bij Honda uit. „Na grondig overleg selecteren we met grote zorgvuldigheid onze projectleden. We analyseren de verschillende persoonlijkheden om te bepalen of ze goed met elkaar overweg kunnen."

De juiste mensen in het agile team opnemen

Als je een personeelsmanager bent of op een andere manier invloed hebt op de samenstelling van teams in je organisatie, zijn hier een paar dingen om rekening mee te houden:

Houd rekening met alle benodigde disciplines in agile teams
Voor interdisciplinaire teams is het belangrijk dat alle vaardigheden die nodig zijn van idee tot volledig geïmplementeerde feature in het team vertegenwoordigd zijn. Dit kan betekenen dat het team in het begin iets groter is dan gewenst.

Mix van verschillende technische kwalificatieniveaus in agile teams

Als het gaat om de teamgrootte, moet je altijd proberen een evenwichtige verhouding van verschillende kwalificatieniveaus in het team te creëren. Als een team drie senior developers heeft en geen minder ervaren programmeurs, moeten de ervaren developers ook minder belangrijke features programmeren die hen misschien vervelen.
Niet alleen zou een junior programmeur dit werk misschien graag hebben gedaan, hij of zij zou zeker ook profiteren van de samenwerking met de ervaren collega.

Evenwichtige verhouding van vakkennis in agile teams

Naast een evenwichtige verhouding van technische vaardigheden moeten we ook een goede balans vinden tussen teamleden die over diepgaande vakkennis beschikken en het probleem dat we proberen op te lossen.
Dit wil niet zeggen dat we nooit een team zouden moeten hebben dat volledig uit vakexperts bestaat, als we daar de gelegenheid toe hebben. In plaats daarvan moeten we beter de langetermijndoelen van de organisatie in overweging nemen.
Een van die doelen is zeker het opbouwen van vakexpertise in de organisatie. Dat bereiken wordt moeilijk als alle vakexperts in één en hetzelfde team zitten.

Diversiteit in agile teams

Diversiteit kan veel betekenen: geslacht, afkomst en cultuur zijn slechts enkele voorbeelden. Maar het kan net zo belangrijk zijn hoe verschillend teamleden problemen aanpakken, hoe ze beslissingen nemen, hoeveel informatie ze nodig hebben voor een beslissing, enzovoort.
Onderzoek heeft aangetoond dat homogene teams weliswaar sneller consensus bereiken dan heterogene teams. Ze bereiken dit echter alleen omdat ze niet in staat zijn om alle mogelijke opties in overweging te nemen.

Doorzettingsvermogen bij het samenstellen van agile teams

Ook agile teamleden hebben even tijd nodig om te leren goed samen te werken. Probeer daarom teamleden die in het verleden goed hebben samengewerkt, ook in de toekomst in hetzelfde team te houden. Als je een nieuw team samenstelt, denk dan ook na over hoe lang de teamleden naar verwachting kunnen samenwerken voordat sommigen of zelfs allen weer andere verplichtingen moeten nakomen.

Veelvoorkomende bezwaren tegen zelforganiserende teams

Er zijn een aantal bezwaren tegen zelforganisatie van teams:

1) Een dominante persoon neemt alle beslissingen

Een veelvoorkomende angst is dat een dominante persoonlijkheid – bijvoorbeeld de technisch leider – besluit dat zelforganisatie betekent dat hij of zij alle beslissingen neemt.

Of een dominante persoonlijkheid dwingt het team zijn of haar mening op voordat het team überhaupt de kans heeft gehad om het onderwerp te bespreken.

Zodra je zoiets opmerkt, moet je de betreffende persoon apart nemen en over de problematiek informeren. Geef de persoon te verstaan dat hij of zij, ook als diegene ervan uitgaat de juiste oplossing te kennen, soms de eigen mening moet inhouden en anderen de gelegenheid moet geven om hun gedachten te delen.

Vraag de persoon of hij of zij denkt dat het team in staat zou zijn de juiste beslissing te nemen als diegene zijn of haar gedachten eerder als mening zou formuleren dan als onaanvechtbaar besluit.

Zet deze persoon in als mentor voor het team – zijn of haar taak zou niet alleen moeten zijn om ervoor te zorgen dat de juiste beslissingen worden genomen, maar eerder dat de teamleden groeien en ook in toekomstige projecten de juiste beslissingen kunnen nemen, waarin deze persoon er misschien niet voor hen is.

2) Mijn team verwacht dat de Scrum Master alles organiseert

Een tweede zorg die velen hebben, is dat het team te passief is voor zelforganisatie en in plaats daarvan verwacht dat de Scrum Master of coach het voortouw neemt en belangrijke beslissingen voor hen neemt.

Als dit gebeurt, zorg er dan voor dat de teamleden begrijpen dat het de taak van de Scrum Master is om hen te ondersteunen, en niet om beslissingen voor hen te nemen. Als je zelf in de dubbelrol van Scrum Master/teamlid zit, hoef je natuurlijk niet altijd je mening te onderdrukken en mag je gerust ook je stem laten horen.

In elk geval moet je naar mogelijkheden zoeken om anderen te betrekken en niet zelf alle beslissingen alleen te nemen. Vraag bijvoorbeeld eerst de andere teamleden om hun mening voordat je zelf de jouwe deelt.

3) Het team is te onervaren voor zelforganisatie

Een derde bezwaar tegen zelforganisatie is vaak dat de teams te onervaren zijn om zichzelf te organiseren.

Ik heb nog geen team gezien dat te onervaren was voor zelforganisatie. Als teamleden genoeg ervaring hebben om een softwareproduct te bouwen, hebben ze zeer waarschijnlijk ook genoeg ervaring om uit te vinden hoe ze zelforganiserend kunnen werken.

Als dat niet het geval is, moet je het team ondersteunen met training en coaching.

In de meeste gevallen betekent dit bezwaar echter alleen dat men het team niet toevertrouwt om zo zelforganiserend te zijn als men zou willen. Jammer dan! Oefen subtiele controle uit over het team; en wel met behulp van de teamsamenstelling en het doel dat je het team meegeeft, en niet via het "hoe" bij het dagelijkse werk van het team.