Channels

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.

Lees ook:

Agile + Scrum ≠ Teamwork

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? 17925

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.

Kennisbank onderwerpen:

Kennisbank onderwerpen:

 

Reageer

Na het plaatsen kunt u uw reactie nog 30 minuten aanpassen.

Reacties

Mooi artikel. Scrum in een nutshell… Echter, volgens de Scrum Guide:

– bestaat een Scrum team uit een Product Owner; een Scrum Master en een ontwikkelteam. (Een Scrum team kan natuurlijk geen Scrum team in zichzelf hebben. Dat lijkt mij niet logisch en zeer verwarrend);

– bestaat een ontwikkelteam team uit 3 tot 9 leden (de Product Owner en de Scrum Master niet meegerekend). Dus niet zoals hier vermeld: eerst “maximaal 7” en vervolgens “vier tot maximaal negen” en

– is het ontwikkelteam niet alleen zelf-organiserend maar ook cross-functioneel. De leden hebben dezelfde skills en kunnen elkaars werk overnemen. Dit is zeer wezenlijk voor Scrum.

Goed dat er een artikel over Scrum op managementsite staat, en goed dat er gezocht wordt naar manieren om dit buiten IT toe te passen! Mooie samenvatting ook.

Zelf werk ik al een aantal jaar als Scrum Master en geef ook regelmatig trainingen aan organisaties die in de IT-sector opereren maar ook daarbuiten. Vanuit die achtergrond heb ik een aantal toevoegingen op het artikel.

Ten eerste mis ik de term ‘business value’ in het artikel. Een belangrijk uitgangspunt van Scrum is dat teams elke sprint (business) waarde genereren door de taken die in de sprint voltooid worden. (Business) waarde kan zijn: het genereren van omzet, het verhogen van klanttevredenheid, het verminderen van supportcalls, het verminderen van waste in het proces, enzovoorts. De Product Owner is de persoon in het team die kan bepalen wat de (business) waarde is van elk item op de backlog en op basis hiervan beslissingen neemt en prioriteert.

Ik benadruk het belang van (business) waarde omdat je perfect kunt Scrummen zonder waarde te genereren voor de organisatie. Dat gebeurt helaas heel vaak. Het is tenslotte ook moeilijk om te bepalen wat de waarde is van punten op de backlog. Maar als je dit niet doet, dan ga je tijd verspillen aan niet-relevante zaken en introduceer je veel verspilling in je proces.

Ten tweede worden veel technieken genoemd die niet noodzakelijk of nodig zijn binnen Scrum. Planning poker is weliswaar nuttig, maar niet nodig. Ditzelfde geldt voor het schrijven van user stories. Dit is geenszins noodzakelijk, en werkt vaak juist tegen als het verplicht wordt gemaakt. Uiteindelijk gaat het er om dat een backlog bestaat uit afgekaderde brokken werk die (zoveel mogelijk) individueel (business) waarde realiseren als ze voltooid zijn en die zodanig zijn opgeschreven dat iedereen in het Scrum Team er kaas van kan maken.

Ten derde mis ik het concept van timeboxing. Binnen Scrum is het belangrijk dat alle ‘events’ (sprint planning, sprint review, retrospective) qua tijd duidelijk gekaderd zijn. Zo voorkom je eindeloos gepraat. Het voorkomt ook de observatie van de auteur dat het samenvoegen van de retrospective en de sprint planning problemen geeft. Ik merk dit probleem zelf niet zo vaak. Vaak combineer ik de sprint review, retrospective en planning zelfs op 1 dag. De retrospective is dan vaak juist het moment waarop een team op ontspannen wijze stoom af kan blazen. Hier zijn ook leuke werkvormen voor.

Ten vierde zou ik het gebruik van electronische middelen beperken. Het probleem met ‘tools’ is dat mensen denken dat de tool al het werk wel doet. Scrum is vooral een menselijk proces. Als je een grote monitor in de kamer zet met een backlog, dan slaat de energie vaak volledig dood. Iedereen zit te wachten tot de persoon die het keyboard heeft klaar is met tikken. Gebruik liever een paar whiteboards en postits. Eventueel kun je het na de sprint planning overnemen in een tool.

Tenslotte mis ik een belangrijk punt in de filosofie achter Scrum; complexiteit is niet beheersbaar. Ondanks al onze pogingen om te proberen van tevoren te voorspellen wat de loop gaat zijn van een project, gaat dit vrijwel altijd mis. De praktijk leert dat je beter kunt ‘denken door te doen’ in plaats van ‘denken voordat je doet’. Bij Scrum is het idee vaak dat je maar beter kunt beginnen, maar dat je zeer regelmatig kritisch kijkt of je nog business waarde aan het genereren bent. Zo niet, dan moet je bijsturen.

Om nog terug te komen op het begin; je ziet in alles direct of indirect terugkomen dat het al dan niet genereren van business waarde de drijvende motor is achter een Scrum Team. In de praktijk blijkt dit super belangrijk, maar super moeilijk.

Het kopje kennisdelen deed mij gelijk triggeren om dit artikel te lezen.
Wat ik niet begrijp hoe je corporate information en successes kunt delen.
Vooral doordat grotere bedrijven niet van elkaar dingen weten.
Zoals ik het lees is scrum bedoeld om tijdens een project fase met leden informatie te kunnen delen door de scrum aanpak.
Is dat correct?

Vriendelijke groet,
Luuk Mooibroek

Luuk, ik denk dat Scrum in die context vooral nuttig is omdat kennis wordt gedeeld binnen een team in plaats van dat de focus ligt op het vastleggen van kennis. Binnen Scrum is het inderdaad belangrijk dat wordt gedacht in termen van een ‘team mind’. Die kan meer onthouden dan de individueen, en is bovendien ook minder gevoelig voor het wegvallen daarvan. Kennis in een team, zo is de gedachte, is beter geborgd dan kennis in een systeem. Dan is het slechts informatie.

Doordat je binnen Scrum alles als team doet, en er geen sterke specialisaties meer zijn, is kennisdeling optimaler. Ik denk dat je het zo op moet vatten.

Helaas veel overbodige Engelse termen (‘agile’, ‘retrospective’, ‘stand-up’ enz.), wat voor de acceptatie van deze methode niet bevorderlijk is.

Toon alle 5 reacties
x
x