Verbeterpunten bepalen
De eerste stap is om het kennisniveau van het team in kaart te brengen. Door gebruik te maken van een kennismatrix kun je onderscheid maken tussen enerzijds de verschillende systemen en projecten, en anderzijds de technische en functionele kennis van het betreffende systeem of project. Laat teamleden naar eigen inzicht de matrix invullen om snel duidelijk te krijgen op welke vlakken actie ondernomen moet worden. Zo kan de technische kennis over een project bijvoorbeeld bij één ontwikkelaar liggen, wat natuurlijk niet wenselijk is. Bespreek de kennismatrix in een retrospective, zodat je meteen kunt doorpakken op de verbeterpunten.
Daarnaast helpt het om eens per sprint een kennisdelingsessie te organiseren. Het teamlid met de meeste kennis van zaken over een bepaald onderwerp heeft dan de mogelijkheid zijn expertise over te brengen op zijn collega’s. Ook is het goed de expliciete kennis over een project kort en bondig te beschrijven op een centrale plek als Confluence. Daar kunnen betrokkenen precies (terug)lezen wat een project inhoudt en welke werkzaamheden en functionaliteiten zijn gerealiseerd.
Kennis verspreiden
Expliciete kennis is doorgaans gemakkelijk te documenteren en over te dragen. Met impliciete kennis, bijvoorbeeld over programmatuur of domeinkennis opgedaan door ervaring, is dat lastiger. Peer programming en reviews bieden uitkomst. In het eerste geval zorg je ervoor dat er altijd twee ontwikkelaars bij een project zijn betrokken. Zo verdeel je de technische knowhow over hoe iets is gebouwd over twee verschillende personen. Is een ontwikkelaar door ziekte of vakantie afwezig, dan kun je als team toch meters blijven maken.
Ook is het slim om teamleden elkaars werk te laten reviewen, zodat collega’s van elkaars aanpak kunnen leren. Een review is de ideale gelegenheid om nieuwe inzichten op te doen en impliciete kennis over te brengen. Door de review op te nemen in de Definition of Done, maak je hem onderdeel van de werkwijze van het team. De review kan het best uitgevoerd worden wanneer de ontwikkelaar eerst met de reviewer zijn aanpak bespreekt en een demo geeft van de gebouwde functionaliteit. Dat schetst kaders en duidelijkheid over wat de reviewer kan verwachten en waar hij op moet letten.
Verder kun je door in planningsessies user story’s globaal toe te kennen aan teamleden zorgen dat meerdere personen betrokken zijn bij een onderwerp. Tegelijkertijd voorkom je dat teamleden bij hun vertrouwde onderwerp blijven hangen en nooit nieuwe, onbekende zaken oppakken. Dat vereist in het begin een investering van tijd en geld, maar uiteindelijk pluk je er als business de vruchten van. Je bent als team minder kwetsbaar, kan opgedane kennis ook bij andere zaken toepassen en blijven leveren aan de business.
"In het kader van mijn cursus ‘Agile Practitioner’ deed ik onderzoek naar de mogelijkheden om kennisdeling binnen teams te bevorderen."
Kennisdeling buiten het team
Als team kun je veel doen om kennisdeling naar een hoger plan te tillen. Maar je hebt natuurlijk altijd te maken met andere partijen. Bijvoorbeeld omdat je functionaliteit onderdeel is van een grotere keten of omdat je kennis nodig hebt van specifieke specialisten in andere teams. Doe die niet aan kennisdeling, dan kun je zelf te maken krijgen met een impediment. Het kan zijn dat je een user story niet kunt afronden omdat een bepaalde specialist een maand op vakantie is.
Een manier om dat te ondervangen is door in een scrum of scrums – met teams uit dezelfde delivery unit – te laten zien hoe je zelf omgaat met het delen en verspreiden van kennis. Werk toe naar een standaard werkwijze voor kennisdeling. Heb je te maken met teams buiten de delivery unit? Dan is het van belang het impediment aan te kaarten bij de product owner en scrummaster. Zo wordt het probleem bespreekbaar en is voor iedereen duidelijk waarom er geen voortgang in een user story zit.
