SCRUM, oorspronkelijk een methode om softwareontwikkelaars te helpen bij het plannen van hun werk, wordt steeds populairder. Het wordt nu ook veel buiten softwareontwikkeling gebruikt en zelfs buiten IT-projecten. Zelfs in de populaire tv-serie ‘Silicon Valley’ wordt er met SCRUM gewerkt. SCRUM moet wel een soort wondermiddel zijn waarmee alle projecten ineens lukken. Toch zijn er punten waar je op moet letten om er inderdaad een succes van te maken. Jan Jacob Bos deelt met u zijn ‘lessons learned’ over SCRUM.
Lessons Learned
In de SCRUM methode zitten verschillende leermomenten waarmee de zaken die verbeterd kunnen worden aan het licht komen: review en retrospective.
Sprint Review
In de Sprint review of Sprint demo aan het einde van de Sprint wordt het resultaat van de Sprint gepresenteerd. Het team laat met een demo zien dat het product echt werkt en voldoet aan de definition of done. Het doel van deze meeting is te laten zien dat er voortgang gemaakt is. Voor de Product Owner is dit een belangrijk moment om feedback te krijgen van andere stakeholders.
Retrospective
De Sprint wordt afgesloten met de Retrospective. Tijdens deze meeting kijkt het team terug op het werkproces in de afgelopen Sprint. Alles wat goed ging moet in ieder geval worden behouden of verbeterd. Alles wat niet goed ging moet worden aangepakt, zodat in volgende Sprints niet dezelfde fouten gemaakt kunnen worden.
De sprint review is vooral bedoeld om de inhoud van het opgeleverde werk te beoordelen, terwijl de retrospective juist inzoomt op het proces. De inhoudelijke verbeteringen zullen van project tot project erg verschillen. De leerpunten uit de retrospective bieden een meer algemene kijk op de SCRUM-methode en zijn voor dit artikel dan ook het meest interessant.
Uit de praktijk
De sprint review en retrospective worden elke sprint, die meestal twee tot vier weken duurt, ingepland. Daarnaast ben ik gewend om minstens twee keer per jaar een grotere review te houden waarmee nog wat meer afstand genomen kan worden van de dagelijkse praktijk om te bepalen waar er nog verbeterpunten zijn die in de retrospective over het hoofd gezien worden.
SCRUM biedt dus zelf al veel mogelijkheden om te blijven verbeteren. Nog efficiënter is het natuurlijk om te leren van anderen voordat u er aan begint. Zo maakt u een vliegende start en kan SCRUM u echt helpen uw projecten en dagelijkse werkzaamheden goed te beheersen.
Durf te veranderen
Voorzichtig aan beginnen lijkt een goede strategie, daarmee kunt u wennen aan de nieuwe situatie. Veranderen is echter niet voor iedereen makkelijk. Een ‘voorzichtig aan wennen strategie’ maakt die verandering vaak alleen maar moeilijker. Dat SCRUM veranderingen vraagt is een gegeven. U kunt dan ook maar beter zorgen voor daadwerkelijke veranderingen van de omgeving, alle deelnemers worden dan dagelijks geconfronteerd met de verandering, wat het uiteindelijk makkelijker maakt om mee te gaan in de verandering.
Uit de praktijk
Er zijn tegenwoordig erg mooie elektronische hulpmiddelen om met SCRUM te werken. Zo kunt u digitaal de voortgang bijhouden en de voortgang goed te zien. Dit heeft echter als nadeel dat dit niet zichtbaar is zolang u die applicatie niet opstart (tenzij u hier continue een groot scherm voor beschikbaar heeft). In de opstartfase werkt een fysiek SCRUM board veel beter. Het board is continu zichtbaar, en geeft vaak aanleiding voor een praatje. Daarmee kunnen cruciale knelpunten soms heel snel opgelost worden. Ook is het zo zichtbaar voor andere mensen in de organisatie, dat kan helpen bij de motivatie om aan het einde van de sprint ook echt alle items op te lossen.
In het begin is minder meer
In een sprint bepaalt de groep welke items er allemaal in die sprint passen. Daarvoor ‘speelt’ het team planning poker om te bepalen hoeveel werk er in de sprint past. In de praktijk blijkt echter maar al te vaak dat er al snel te veel hooi op de vork genomen wordt. Dit blijft meestal heel lang doorwerken. De items die niet af komen, schuiven door naar de volgende sprint, in de nieuwe sprint worden nog nieuwe items toegevoegd die ook af moeten, waardoor de achterstand op blijft lopen. Dit is slecht voor de motivatie en kan de effectiviteit van SCRUM teniet doen. Begin de eerste sprints dus echt met een minimale hoeveelheid werk. De voldoening die dit geeft als in de eerste sprint alles op tijd af is, is onbetaalbaar!
Uit de praktijk
Zelf werk ik dagelijks met SCRUM, daarbij combineren we de werkzaamheden uit projecten met de dagelijkse taken die zich goed laten plannen. Mijn ervaring is dat je het beste in één SCRUM-team kunt werken in plaats van voor elk project in een ander SCRUM-team plaats te nemen. Dit maakt het soms wel lastig als veel mensen in verschillende projecten werken, waardoor er in het centrale SCRUM-team ook aandacht is voor zaken waar niet alle deelnemers direct mee te maken hebben. Zolang de planning en standups maar efficiënt gehouden worden, is het voordeel van de context waar iedereen mee bezig is, groter dan het nadeel van de extra tijd die het kost. Het grote voordeel van één SCRUM-team is dat je met elkaar verantwoordelijk bent om alle items uit de sprint op te pakken. Je kunt je dan ook niet verschuilen dat het in het andere team zoveel drukker is. Dit zorgt voor een goede focus op alle taken die gedaan moeten worden. In de praktijk komt het neer op zo’n twintig verschillende SCRUM-teams binnen onze organisatie. Waarbij iedereen in dezelfde tweewekelijkse sprints werkt. Dat maakt het gemakkelijker om in een ander team in te springen voor één of meerdere sprints.
Benut de spel elementen
SCRUM biedt een aantal spelelementen die de methode juist aantrekkelijk maken. Zo wordt er planningpoker gespeeld om te bepalen hoeveel werk er gedaan kan worden. Tijdens de sprint wordt de voortgang op een speelse manier bijgehouden in de burndown chart. Veel mensen vinden deze spelelementen wat kinderachtig en laten ze weg. Niet doen! Heeft u wel eens een voetbalwedstrijd bekeken waar de score niet wordt bijgehouden? Dat maakte de wedstrijd ineens minder spannend. Benut deze speelse elementen van SCRUM juist om de motivatie optimaal te houden.
Uit de praktijk
Ik heb ook een keer toegegeven aan de wil vanuit het team om de planningpoker maar over te slaan. Men was immers heel goed zelf in staat om in te schatten hoeveel tijd een bepaalde taak zou kosten. Na dit een aantal maanden geprobeerd te hebben, bleek toch dat er aan het eind van sprint veel items nog niet opgelost waren. Toen we toch weer begonnen met planningpoker, bleek de inschatting veel beter te verlopen en lukte het ook beter om alle items uit de sprint op te lossen.
Bepaal de optimale duur van een sprint
Als u de sprint te kort maakt, hebben mensen al snel het idee dat er te veel tijd gaat zitten in alle zaken om het eigenlijke werk heen: plannen, demo’s, retrospective, enzovoort. Als de sprint te lang wordt, is het juist weer heel lastig om de volledige periode efficiënt te plannen en komen er vaak toch andere zaken tussendoor. Volgens de standaard SCRUM-regels, duurt een sprint twee tot vier weken. Wat ik merk is dat men vaak te strak vast houdt aan de vooraf (meestal willekeurig) gekozen periode van een sprint. De ideale duur van een sprint hangt echter van zoveel factoren af, dat deze zich onmogelijk laat voorspellen. Speel daarom eens met verschillende perioden tussen één en vier weken. Wat het beste werkt in uw team, kunt u dan vasthouden voor volgende sprints.
Rouleer de verschillende rollen
Een SCRUM-master is een heel andere rol dan een projectleider. En hoewel niet iedereen de optimale vaardigheden van SCRUM-master bezit, is dit binnen een team meestal goed door verschillende mensen in te vullen. Iemand die snel commentaar heeft als SCRUM gebruikt wordt, kan het beste maar eens zelf ervaren wat er bij komt kijken om SCRUM-master te zijn.
Blijf vernieuwen
De procesmatige kant van projecten moet gewoon goed ingericht zijn, als dat eenmaal het geval is, moet je er vooral niet veel meer aan veranderen. Dat is niet altijd waar. Uiteindelijk zijn het de mensen in het team die er voor moeten zorgen dat het werk op tijd af komt en aansluit op de vooraf afgestemde eisen van de klant. Als er niks verandert, hoeft er met SCRUM ook niks te veranderen. Er verandert echter juist heel vaak wat: er komen nieuwe teamleden bij of de klant waar u voor werkt haalt een megaorder binnen, waardoor uw werkzaamheden zich ook aan moeten passen. Maar het kan ook zijn dat het team te veel op de automatische piloot werkt en niet meer ziet dat sommige teamleden te weinig betrokken zijn in dagelijkse standup bijvoorbeeld. Soms kunnen grote wijzigingen dan noodzakelijk zijn om iedereen weer optimaal betrokken te krijgen.
Conclusie
SCRUM biedt zelf al veel ingebouwde regels om het proces blijvend te optimaliseren. Toch is SCRUM daarmee nog niet automatisch een wondermiddel waarmee de planning van activiteiten geen knelpunten meer kent. Met een beetje discipline, creativiteit en doorzettingsvermogen kunt u met SCRUM echter wel goed voorspellen wat er wél en wat er niet kan. Hierdoor houdt u optimale grip op de planning en komt u niet zo snel meer voor negatieve verrassingen te staan voor wat betreft het werk dat gedaan moet worden. Daarbij is SCRUM inmiddels al lang niet meer voorbehouden aan ICT-organisaties, er zijn zelfs al scholen die SCRUM gebruiken! Bovendien helpt SCRUM om efficiënter te werken zowel bij projectwerkzaamheden als in dagelijkse activiteiten.
Jan Jacob Bos is werkzaam bij Schuberg Philis en auteur van Noodzakelijke kennis.
Bron: Managementsite
