SCRUM, oorspronkelijk een methode om software ontwikkelaars te helpen bij het plannen van hun werk, wordt steeds populairder. Het wordt nu ook veel buiten software ontwikkeling 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. Na een aantal jaren ervaring met SCRUM wil ik graag mijn ‘lessons learned’ met u delen. Hopelijk helpt SCRUM u dan net zo goed als mij bij uw werkzaamheden.
Lessons Learned
In de SCRUM methode zitten verschillende leermomenten waarmee de zaken die verbetert 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 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 spel elementen die de methode juist aantrekkelijk maken. Zo wordt er planning poker 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 spel elementen wat kinderachtig en laten ze weg. Niet doen! Heeft u wel eens een voetbal wedstrijd bekeken waar de score niet wordt bijgehouden? Dat maakt de maakt 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 planning poker 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 planning poker, 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 team leden 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 team leden 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 project werkzaamheden als in dagelijkse activiteiten.
Jan Jacob Bos is werkzaam bij Schuberg Philis en auteur van Noodzakelijke kennis. Efficiënt omgaan met kennis is cruciaal om een voorsprong te nemen op concurrenten en om de strategie van een onderneming succesvol uit te voeren.
Kom met uw praktijkervaringen op het terrein van managen en organiseren
Deel uw kennis, schrijf 3 columns of artikelen en ontvang een gratis pro-abonnement (twv €200)
Word een pro!
SCHRIJF MEE >>
Alternatieven, zoals KANBAN, moeten altijd ook overwogen worden, bv bij kleine teams (minder overhead), bij teams die meerdere producten moeten servicen, bij onduidelijke research projecten (hoge mate van onzekerheden).
Dit artikel heeft naar mijn smaak te veel jargon voor mensen die niet al met scrum bezig zijn. Ik ben al 4 á 5 jaar bij scrum software-ontwikkelteams betrokken als tester/testcoördinator en deze lessen zijn we allemaal tegen gekomen.
Als je iets met Scrum wilt, zul je bij het begin moeten beginnen:
Het Agile manifest
(http://www.agilealliance.org/the-alliance/the-agile-manifesto/):
------
We are uncovering better ways of developing software by doing it and helping others do it.
Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
en de 12 principes ook op deze site te vinden
------
Dit gaat meer over attitude dan over methode. Als je met Scrum wilt gaan werken is het goed om tot je te laten doordringen wat Agile werken inhoudt voor je medewerkers en voor jezelf. En of Agile iets bij je oproept in de zin van: daar wil ik met mijn team naartoe.
Scrum is een methode om Agile werken beter te structureren, maar die attitude is in essentie belangrijker.
Dan je specifieke vragen.
1 het project is niet echt projectmatig.
Als met projectmatig bedoeld wordt: een planning en control aanpak zoals bv met Prince2, dan is het antwoord op deze vraag: dan zou Agile/Scrum een goede werkwijze kunnen zijn.
2 nadelen van het nieuwe werken systematisch te pakken
het nieuwe werken kan alles betekenen. Agile/Scrum is zelf zo'n vorm van het nieuwe werken.
Als je met het nieuwe werken bedoelt dat mensen niet meer op kantoorlokatie werken maar 'willekeurig' waar, dan is dat een probleem, omdat bij Scrum er van uitgegaan wordt dat de teamleden dicht bij elkaar zitten. Geen wet van Meden en Perzen: een stand-up kun je b.v. ook dagelijks via Skype wereldwijd organiseren.
3 periodiek nagaan of de contacten met opdrachtgevers goed lopen.
Contact met opdrachtgever/klant is essentieel in de Agile/Scrum methode: Opdrachtgever is een direct betrokkene en wordt meestal uitgenodigd bij de Demo aan het eind van elke sprint.
4 ruimte en kwaliteit om de hoofdtaken van een team goed te laten lopen.
Dit bepaalt het team zelf aan de hand van de keuze van op te lossen items uit de project backlog en die items in de sprint af te werken. Per sprint wordt dus telkens een nieuwe prioritering aangebracht in wat een team belangrijk vindt en in het tijdsbestek van de sprint ook daadwerkelijk kan oplossen.
Continue kwaliteit is 1 van de Agile basiselementen.
5 Soort van werkwijze en spelregels.
Met Agile/Scrum heb je niet een methode die van a tot z vast ligt en zo uitgevoerd moet worden als voorgeschreven. Je kunt beginnen met enkele eenvoudige punten op te pakken.
Begin eerst je er in te verdiepen door een paar boekjes te lezen of een basiscursus te doen. Dan krijg je al meer zicht op het waarom en het hoe.
En durf ruimte te bieden aan het experiment, zodat het team zelf kan bepalen hoe ver en hoe hard het gaat in het omarmen van de methode.
Tot slot: zit je in een strakke Angelsaksische organisatie, dan zou ik het met Scrum werken in eerste instantie tot een klein team en een klein domein beperken. Slaagt het dan kun je dat direct laten zien en je teamleden als ambassadeurs inzetten voor verdere uitrol van Scrum.
De zaak zit zo:
1 - uit enige onvrede met de bestaande medewerkersonderzoeken heb ik een alternatief gemaakt en ingezet. Gevraagd naar de relatie tussen hun ambities en hun werkelijkheid geven medewerkers redelijk massaal aan dat ze meer zouden kunnen en willen presteren voor hun klanten/opdrachtgevers. Mooi. Maar sommige condities en onvoldoende "gehoord worden" zorgen voor minder energie en innovatief vermogen.
2 - Daarnaast hebben leidinggevenden vaak geen behoefte aan "extra projecten": ze hebben hun handen al vol. En over de condities en de organisatie van het werk hebben ze soms een andere visie dan de medewerkers. Dat is een beetje jammer, want uit mijn metingen blijkt dat prestatie en energie een stuk omhoog schieten als er sprake is van "attent leiderschap". Daarmee bedoel ik: doelgerichtheid in combinatie met aandacht voor de ideeën en problemen van hun medewerkers.
3 - Dienend of faciliterend leiderschap zie ik zelf niet zo zitten. Leidinggevenden hebben ook zelf doelstellingen en ambities.
De vraag is dan: hoe krijg ik de rol van leidinggevenden (beweging, richting en focus) samen met het potentieel "goed werknemerschap" van de medewerkers. En dan niet als project maar als miniprojectjes of zelfs als "werkwijze". En dan denk ik aan scrum. Het voordeel lijkt me zowel de klantgerichte verbetering als de face-to-face-werkwijze als het opdelen van grotere doelen in kleine stapjes en de bijeenkomst op de werkvloer zelf.
Een eenvoudig maar actueel voorbeeld is: beter omgaan en meer resultaat krijgen bij de digitalisering van loketten bij een infobalie (en dan bedoel ik even niet het ICT-gedeelte, al kan dat later ook). Er is dan denk ik inderdaad een DOD nodig (al zal die gaande weg veranderen) en een opbrengstverwachting. En iemand moet de spelregels toepassen en zorgen dat de ideeën opgedeeld en gericht worden op behapbare brokjes. Maar wat mis ik als ik denk dat dat voldoende is?
En kan zoiets niet - op den duur - dagelijks: wat gaat iedereen doen en welke hulp of ideetjes van anderen zijn dan behulpzaam? Of wekelijks: welke positieve of negatieve klantervaringen waren er, wat kan beter in het werk? Hoe pakken we dat op?
Of raak ik dan te ver van de scrum af?
Een info balie afdeling lijkt mij een situatie waarin snel actie moet worden ondernomen. De waan van de dag regeert, maar je wilt niet dat er dingen verloren gaan of over het hoofd gezien wordt. Korte schakel momenten en kennisdeling zijn dan relevant. Ik hoop dat ik hiermee de schets goed gemaakt heb.
SCRUM heeft een fixeer moment voor werkvoorraad voor het team voor een termijn van 2-4 weken (de sprintbacklog). Komen er nieuwe taken dan moeten die periode minimaal wachten. Tussentijds bijsturen van de inhoud van de sprintbacklog mag niet (heel incidenteel!). Lijkt mij niet van toepassing in deze situatie, maar er zouden andere redenen kunnen zijn om dit alsnog in te voeren, bv juist om het team RUST te geven en de waan van de dag dus buiten de deur te houden.
Waar mensen vooral van houden binnen SCRUM is het overzicht op de werkvoorraad (het bord) en continue evaluatie hoe het gaat, waar we staan etc (de daily scrum) en andere evaluatie methodes.
Praktijk voorbeeld: Ik zit op dit moment in een team dat beheer pleegt (Adhoc requests) en ook deels R&D (ook niet planbaar). We moeten, helaas, dagelijks kunnen reageren op support vragen. etc.
SCRUM is bij ons niet zinvol, helaas. Aan het einde van de sprint kom je iedere keer weer tot de conclusie dat je je doel niet gehaald hebt, want je hebt je tijd onverwachts meer aan beheer taken moeten besteden. Dat vindt Management niet erg, maar is voor het team erg frustrerend, zeker als er zoveel moeite gestoken is in het formuleren van een doelstelling etc.
We zijn dan ook overgestapt van SCRUM naar KANBAN, aangevuld met een aspecten van SCRUM die ons goed bevallen waren: dagelijkse evaluatie, retrospective, DOD etc. We bewaken onze werkvoorraad is en blijft een issue.
Welke methode jullie gaan gebruiken, je moet altijd open blijven staan voor verbetering. Blijf Agile, niet alleen op de inhoud van het werk, maar ook hoe je met het werk omgaat.
Overweeg idd om een (externe) ervaringsdeskundige (tijdelijk) in te zetten om de verandering door te voeren.
Ik blijf het verbazingwekkend vinden dat wij mensen zoveel tijd besteden aan het formuleren van een methode om simpelweg van A naar B te gaan. Boekenvol worden er over geschreven.
Tijdens een cursus projectmanagement hebben we de gehele morgen oeverloos gediscusseerd over alle andere vormen van management.
Nu schrijven we over SCRUM, KANBAN, AGILE,etc.. Om te leren hebben we boeken, instructeurs. Hoeveel geld geven we met zijn allen uit om simpelweg van A naar B te gaan.
Probeer alles nuchter te bekijken. En van alle reacties ben ik meer begaan met Otto zijn verhaal. Tussen de regels door lees je de praktijk. Zwoegen om een doel te bereiken. Dat spreekt mij aan. Dat zouden meer mensen moeten doen.
Waar of voor wie je ook werkt het gaat altijd om het verdienmodel. Maar wij mensen, stuk voor stuk zijn heel druk bezig met "IK". Positie, geld, status, etc.
Natuurlijk zijn er uitzonderingen.
Als je voor de overheid werkt dan is je bestaansrecht qua werk redelijk geborgd. Bij grotere multinationals wordt het al wat spannender.
Maar voor een klein bedrijf, 5 werknemers, is het elk uurtje factuurtje. En kost het moeite om boven het maaiveld te blijven. Zij gebruiken een planbord zodat je dagelijks kunt zien waar je staat. En natuurlijk is overleg belangrijk. Vastleggen en registreren ook.
Maar dat leer je op school/avonduren en dan pas je het toe in de praktijk.
Waar wil ik naar toe. Wees eerlijk kijk in de spiegel een ieder van ons heeft de luxe om over deze onderwerpen te filosoferen. Maar denk ook af en toe aan de wereld om ons heen en wees dankbaar voor je positie. Probeer nuchter te blijven.
Kostenbeheersing voor het bedrijf, overheid, instelling etc
Streef naar een betere wereld maar begin bij jezelf.
(Het valt me overigens op hoe weinig mensen die reageren hun profiel hebben aangepast zodat je weet in welke organisatie ze werken. Misschien iets om te promoten, o Managementsite?)