Agile

Kennisdeling is een must voor een optimaal functionerend agile team. Toch zijn er genoeg organisaties die het delen en verspreiden van kennis achterwege laten, omdat ze er geen meerwaarde in zien. Eeuwig zonde, want het bevordert zowel de business value als teamontwikkeling. Ik vertel je graag waarom!

Binnen veel organisaties is kennisdeling een ondergeschoven kindje. Dat kan liggen aan de business, die snel resultaat wenst en het scrumteam min of meer dwingt te focussen op zaken als continious deployments. Dat is immers nieuw, uitdagend en helpt bij de teamontwikkeling en fast feedback. Kennisdeling gaat ten koste van business value, zo wordt vaak gedacht. Hoewel het in het begin extra inspanning vereist, biedt het op lange termijn veel voordelen. Zo kunnen teamleden van elkaar leren over ontwikkelmethodes en best practices, wat de kwaliteit van het werk uiteindelijk ten goede komt.

Een gebrek aan kennisdeling kan juist leiden tot een project dat in de soep loopt. Elke organisatie heeft (externe) medewerkers die ‘onmisbaar’ zijn door hun kennis over bepaalde systemen en functionaliteiten. Zodra die experts wegvallen, wordt duidelijk hoezeer de IT-organisatie afhankelijk van ze is. Daarom zou iedere sprint ruimte moeten bieden voor kennisdeling. Maar hoe integreer je dit met de dagelijkse werkzaamheden?

181119 – Het hoe en waarom van kennisdeling – foto Victor

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.

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

Ontwerp zonder titel (19)

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.

Mijn Paarsz