Kennis delen gaat vanzelf met SCRUM

Kennismanagement-projecten verheffen het delen van kennis vaak tot doel. Daarbij wordt de hoeveelheid opgeslagen ‘kennis’ als meetlat gebruikt om het succes te bepalen. Als er een kennisbank ingericht is, moet deze toch gevuld worden, nietwaar? Het vullen is meestal niet de favoriete bezigheid van professionals. De waarde van de opgeslagen kennis is dan ook niet altijd in verhouding met de daadwerkelijke kosten van de kennisbank.

In dit artikel belicht ik kennismanagement vanuit een andere hoek. Het gaat hierin niet over kennismanagement zelf, maar over slimmer plannen en werken. Daarbij wordt kennismanagement als vanzelf goed ingevuld door de medewerkers. De focus ligt echter op de doelstellingen van het werk zelf, niet op de kennis die daarvoor nodig is.

SCRUM is een methode die ontstaan is in de software ontwikkeling. Deze methode wordt inmiddels echter veel breder ingezet, en wordt zelfs op scholen toegepast. Ik zal eerst kort toelichten wat de SCRUM methodiek inhoudt. Vervolgens zal ik dieper in gaan op de verschillende aspecten waarbij ik toelicht hoe SCRUM bij kan dragen aan het efficiënt omgaan met kennis.

SCRUM in vogelvlucht

Veel planningsmethodieken proberen alles vooraf in te plannen. Als er dan wijzigingen nodig zijn, moet ook de planning weer aangepast worden. Eigenlijk worden op deze manier de goede ideeën die ontstaan in de loop van het proces de kop in gedrukt. Bij SCRUM is er juist volop ruimte voor verbetering tijden het proces. SCRUM bestaat uit vier belangrijke stappen:

1. backlog
   De product owner vertegenwoordigt de belangen van de klant. De product owner speelt ook een belangrijke rol in het opstellen van de backlog, zo sluit het resultaat zo veel mogelijk aan bij de wensen van de klant.
2. printplanning
   In de sprintplanning wordt bepaald welke items uit de backlog allemaal gedaan kunnen worden in de komen sprint (meestal 2 – 4 weken). De hoeveelheid werk wordt bepaald aan de hand van punten waarbij een bepaalde taak als referentie dient. Door dit puntensysteem en de regelmaat waarmee de sprintplanning plaats vindt, kan het team uiteindelijk vrij nauwkeurig bepalen hoeveel punten zij in elke sprint kunnen doen.
3. sprint
   Tijdens de sprint werkt het team aan alle items die afgesproken zijn. Dagelijks wordt er een stand-up gehouden waarbij iedere deelnemer uit het team (maximaal 7) antwoord geeft op de volgende vragen:
   - Wat heb ik gedaan sinds de vorige meeting?
   - Wat ga ik doen tot de volgende meeting?
   - Welke belemmeringen zie ik en welke hulp heb ik daarbij nodig?
4. demo
   Aan het einde van de sprint wordt het resultaat getoond en wordt bepaald welke verbeteringen er mogelijk zijn in de volgende sprint.

Al deze verschillende elementen van SCRUM dragen bij aan het slim omgaan met kennis in een organisatie. Geen overbodige ballast die alleen maar tijd kost, maar er moet natuurlijk ook geen cruciale kennis verloren gaan.

Uit de praktijk:
Hoewel de opzet van SCRUM vrij eenvoudig is, heb ik gezien dat het toch altijd wel een paar sprints kost om er goed in te komen. In het begin is een dosis doorzettingsvermogen dan ook onontbeerlijk. Wijk in het begin vooral ook niet te veel af van de vaste onderdelen. Ook al lijken bepaalde onderdelen weinig waarde toe te voegen en vooral tijd te kosten, in een later stadium verdient zich dit echt terug.

Samenstellen van het SCRUM team

Een SCRUM team bestaat meestal uit vier tot maximaal negen personen. Een ideale omvang voor een SCRUM team is zeven personen. Toch is SCRUM heel goed schaalbaar voor grotere projecten door het werk te verdelen over meerdere teams. Het samenstellen van een SCRUM team is al een belangrijke stap in het slim omgaan met kennis in uw organisatie.

Voor een SCRUM team heeft u de volgende mensen nodig:

• Product owner
  Deze vertegenwoordigt in SCRUM termen de belangen van de klant. Dit kan een ‘echte’ klant zijn, maar ook een ‘interne’ klant zoals dat in veel organisaties genoemd wordt. Voor welke klant bent u verantwoordelijk? De product owner beheert de backlog. Kies daarom iemand die structuur kan aanbrengen en daadkrachtig kan optreden.
• SCRUM master
  Dit is de coach van het team; hij neemt de verantwoordelijkheid op zich om belemmeringen op te lossen. Typische eigenschappen die een SCRUM master succesvol maken zijn coaching vaardigheden en leiderschap. De SCRUM master kan zowel iemand uit het professionalteam als iemand uit het managementteam zijn. De SCRUM master is een procesbegeleider en geen ‘baas’.
• SCRUM team
  Het SCRUM team als geheel is verantwoordelijk voor het resultaat. SCRUM leent zich het beste voor zelforganiserende teams. Houd hier rekening mee bij de samenstelling van het team.

Met het SCRUM team als geheel gaat u aan de slag om goed te plannen werkzaamheden uit te voeren. Dat kan in een projectvorm zijn, maar dat kunnen ook dagelijkse werkzaamheden zijn. U kunt met een team werken dat volledig inzetbaar is voor de SCRUM taken, maar dat hoeft niet. Het kan zelfs gunstig zijn dat mensen naast hun reguliere werkzaamheden ook in een SCRUM team werken aan een bepaald project. Door het mixen van projecttaken en reguliere werkzaamheden wordt kennis via verschillende kanalen in de organisatie verspreid.

Uit de praktijk:
De rol van een SCRUM master is echt wezenlijk anders dan die van een projectleider. Als u met een team werkt waarmee u ook op traditionele manier aan projecten gewerkt heeft, dan kunt u meestal beter niet de projectleider de SCRUM master maken. Voor een projectleider is het vaak erg lastig om de omschakeling te maken naar deze nieuwe rol. In het team is vast wel iemand beschikbaar die wel de rol van coach op zich kan nemen. Soms is het zelf beter om helemaal een nieuwe samenstelling van het team te maken.

Alleen noodzakelijke activiteiten uitvoeren

Het opstellen van de backlog bepaald welke activiteiten er de komende periode uitgevoerd gaan worden. Door deze activiteiten in de juiste volgorde te zetten worden de belangrijkste taken als eerste opgepakt. De product owner speelt een belangrijke rol bij het opstellen van de backlog. Aangezien de product owner de klant vertegenwoordigd, is de backlog een afspiegeling van taken die het meest belangrijk zijn voor de klant. Het opstellen van de backlog gebeurt in dezelfde regelmaat als de sprints (meestal tussen de twee en vier weken dus). Hierdoor is de backlog altijd actueel.

Uit de praktijk:
Om één sprint vooruit te plannen met de zaken die voor die sprint nodig zijn, is het belangrijk dat de taken op de backlog ook echt de taken zijn met de hoogste prioriteit en er later geen ad-hoc taken toegevoegd hoeven te worden. Dit zie ik vooral gebeuren als de backlog niet goed weergeeft wat voor de klant het belangrijkst is. Besteedt dus ruime aandacht aan bepalen van de backlog.

Iets wat moeilijk is moet je vaak doen, dan wordt je er steeds beter in

Waarom mislukken veel projecten? Vooral grote projecten vragen een uitgebreide planning vooraf om vervolgens ook nog veel tijd te spenderen om alle wijzigingen ingepland te krijgen. Dit heeft twee belangrijke nadelen. Als zo’n groot project gepland moet worden, dan doe je niet zo vaak, dat betekent dat je er nooit heel goed in kan worden. Bovendien biedt het weinig ruimte om alle goede ideeën die tijdens het project opkomen mee te nemen in het project zonder de planning aan te passen. In SCRUM wordt voor elke sprint een nieuwe planning gemaakt. Dat betekent dat er elke paar weken gepland wordt. Als je dat zo vaak doet, wordt je er vanzelf heel goed in. Bovendien wordt de planning gemaakt door de mensen die de werkzaamheden ook uitvoeren. Zij kunnen veel beter inschatten hoe lang zij ergens over doen dan iemand die vooral bezig is met plannen zonder zelf de taken uit te voeren. Daar komt nog bij dat in SCRUM niet gewoon uitgegaan wordt van een inschatting in uren, maar door gebruik te maken van punten. Dit werkt als volgt: Er wordt een relatief eenvoudige taak als uitgangspunt genomen en daar wordt een aantal punten aan toegekend. Voor andere taken wordt dan het aantal punten ingeschat op basis van deze referentietaak.

Een belangrijk hulpmiddel bij het plannen van de taken is planningspoker. Met behulp van kaarten waar een aantal punten op staat, kan iedereen aangeven hoeveel puntenhij denkt dat een bepaalde taak zou moeten zijn. Als hier grote verschillen in zitten tussen de verschillende deelnemers, zullen de deelnemers aangeven waarom zij een bepaald aantal punten gegeven hebben. Hierdoor ontstaat voor de hele groep inzicht in het uitvoeren van de taak. Zo helpt SCRUM dus niet alleen met het maken van een goede planning, het helpt alle deelnemers ook om inzicht te krijgen in het werk van elkaar en kennis te delen.

Uit de praktijk:
Planningspoker lijkt in het begin wat kinderachtig, en veel teams denken tijd te kunnen besparen door snel akkoord te gaan met de eerste persoon die aangeeft hoeveel punten (of tijd) een bepaalde taak kost. Iemand die het hier niet mee eens is, voor zover ik heb gezien, meestal niet snel bereid om daar wat van te zeggen. Door het gebruik van planningspoker moet iedereen vooraf bepalen hoeveel punten hij een taak geeft. Juist als er verschillen opduiken is de complexiteit van de taak dus niet duidelijk. Een goede interactie hierover helpt om de taak beter te kunnen plannen.

Problemen oplossen? Gebruik de kracht van de groep!

Een andere krachtig hulpmiddel van SCRUM is de dagelijkse stand-up. In deze stand-up geven alle deelnemers uit het team antwoord op de volgende vragen:

• Wat heb ik gedaan sinds de vorige meeting?
• Wat ga ik doen tot de volgende meeting?
• Welke belemmeringen zie ik en welke hulp heb ik daarbij nodig?

Door deze vragen te beantwoorden is iedereen in het team op de hoogte van wat er speelt. Als er iemand tegen problemen aan loopt kan zo ook gemakkelijk het hele team geïnformeerd worden. Hoewel de problemen niet opgelost moeten worden in de stand-up zelf, is dit wel een uitgelezen mogelijkheid om andere teamleden te betrekken bij het probleem. Direct na de stand-up kunnen die personen die het probleem herkennen direct helpen. Hoewel veel mensen in het begin wat moeite kunnen hebben met delen van de issues waar ze tegen aan lopen, merk ik dat dit in veel SCRUM teams uiteindelijk vanzelf gaat. Een mooie manier om invulling te geven aan kennismanagement!

Uit de praktijk:
De grootte van het team is bepalend voor de succesgraad. Bij meer dan 8 mensen wordt het echt lastig om de dagelijkse stand-up efficiënt te houden. Bij te kleine groepen is het lastig om momentum te creëren. Scrum biedt ook mogelijkheden om groepen op te splitsen en op een hoger niveau toch weer de noodzakelijke kennis samen te voegen. Het blijft echter wel lastig om met andere groepsgroottes te werken dan 4-8 mensen.

Vastleggen van kennis is geen doel op zich

In veel projecten wordt er aan het einde van het project een ‘lessons learned’ sessie gehouden en wordt de projectdocumentatie afgerond. Het is natuurlijk een goede zaak om proberen te achterhalen wat er beter kon en dit ook vast te leggen zodat het in de toekomst hergebruikt kan worden. Echter, bij lang lopende projecten is achteraf lastig om alle details boven water te krijgen die bijgedragen hebben aan het al dan niet slagen van het project. In SCRUM wordt ten eerste al goed vastgelegd wat er gedaan moet worden. In SCRUM-termen zijn dit ‘user stories’. Bovendien wordt er ook afgesproken wat de definitie van ‘klaar’ is. Daarin kun je bijvoorbeeld afspreken dat het werk pas echt af is, als ok de documentatie klaar is. Tenslotte wordt er aan het einde van elke sprint een ‘retrospective’ gehouden waarin besproken werd wat er goed ging en wat verbeterd kan worden. In de volgende retrospective worden die verbeterpunten dan weer besproken, je komt er dus niet onderuit. Binnen SCRUM is het vastleggen van bepaalde zaken een onderdeel van de werkwijze zonder dat er van alles vastgelegd wordt om het vastleggen. Het is vaak erg praktisch om elektronische hulpmiddelen te gebruiken voor het bijhouden van de backlog, de sprints en de retrospectives. Veel benodigde gegevens worden dan automatisch vastgelegd.

Uit de praktijk:
Ik heb vaak gezien dat de retrospective en de sprintplanning in één sessie worden gehouden. Het risico is dan groot dat de retrospective niet de aandacht krijgt die het verdient en er snel naar de nieuwe sprint gekeken wordt. Plan hier echt twee aparte sessies voor, daarmee bespaart u op de lange termijn tijd doordat de retrospectives echt helpen om efficiënter te werken, als er  tenminste serieus tijd voor genomen wordt.

Conclusie

SCRUM is veel meer dan een projectmethodiek voor het ontwikkelen van software. Ook buiten de ICT kan SCRUM heel goed toegepast worden. Het beperkt zich niet tot projecten. Ook voor veel dagelijkse werkzaamheden helpt SCRUM om efficiënt te werken. SCRUM is gebaseerd op een ‘agile’ manier van werken. Dit betekent dat er flexibel ingesprongen kan worden op veranderingen waarbij de focus blijft liggen op een werkende oplossing. Ik heb in dit artikel laten zien hoe SCRUM bijdraagt aan het efficiënt omgaan met kennis in een organisatie. Durft u de uitdaging aan om zelf aan de slag te gaan?

Verder lezen, Noodzakelijk kennis: Kennismanagement in lijn brengen met de strategie waarbij ook aangegeven wordt  hoe dit met behulp van SCRUM toe passen is in de eigen organisatie.