Scrum – een methode om snel producten op te leveren

Tekst groter

Scrum – een methode om snel producten op te leveren

Projectmatig werken is gedoe, en het gaat bijna nooit van leien dakje. Dat maakt dat er een voortdurende queeste is naar de methode die het ‘gedoe’ minimaliseert. Laat ik vooropstellen dat dit niet zal gebeuren, want een project speelt zich immers altijd af in een beweeglijke en onzekere context. Zo is er lang geloofd dat Prince2, door handboeken en waterdichte procedures, deze zekerheid zou geven. Nu is er een tegenbeweging (ook afkomstig uit de software wereld) onder de titel ‘scrum’. Je kunt scrum volledig toepassen, maar je kunt elementen er uit ook voor andere projectmanagement methoden gebruiken.

Ook zie ik mijn collega’s soms worstelen met de toepasbaarheid van de lineaire (waterval) fasering. Een van de oplossingen, die al jaren wordt gebruikt, is de toepassing van een cyclische fasering. Cyclische faseringen worden gekenmerkt door het ontwikkelen van oplossingen in het licht van de op dat moment bekende eisen. Deze eisen worden vervolgens zo snel mogelijk getoetst aan de praktijk (prototypes). De leringen hieruit worden weer vertaald in nieuwe eisen en oplossingen. Deze aanpak levert meer snelheid en flexibiliteit op dan de klassieke lineaire aanpak. Agile als filosofie en Scrum als methode spelen in op deze behoefte aan flexibiliteit en snelle feedback.

Maak interactie tussen betrokkenen mogelijk

Al weer een aantal jaren geleden is door een groep software ontwikkelaars, onder aanvoerderschap van Jeff Sutherland, het ‘Manifest voor Agile Software Ontwikkeling’ opgesteld: ‘Wij laten zien dat er betere manieren zijn om software te ontwikkelen door in de praktijk aan te tonen dat dit werkt en door anderen ermee te helpen. Daarom verkiezen we Mensen en hun onderlinge interactie (boven processen en hulpmiddelen) Werkende software (boven allesomvattende documentatie); Samenwerking met de klant (boven contractonderhandelingen); Inspelen op verandering (boven het volgen van een plan).'

Uitgangspunt bij de agile filosofie, en bij scrum als één van de agile methoden, is dat men er vanuit gaat dat klanttevredenheid ontstaat door snelle (binnen vier weken) en continue levering van werkende (deel)producten.

Naast software ontwikkeling wordt scrum (of elementen eruit) langzaam maar zeker en met vallen en opstaan, ook toegepast in andere gebieden. Ik denk dat veel van de principes van scrum ook toe te passen zijn door de gebruikers van andere projectmanagement methoden.

In zijn boek Scrum - tweemaal zoveel doen in de helft van de tijd (2014) noemt Jeff Sutherland een aantal uitgangspunten voor scrum. Als eerste, het project moet leuk zijn om te doen. Belangrijker is natuurlijk het product dat opgeleverd moet worden. Daarom is er naast een definition of fun, ook een definition of done (je moet weten wanneer je iets als klaar beschouwt), een backlog (takenlijst), sprints (korte periodes van twee tot vier weken waarin een werkend tussen product of prototype wordt opgeleverd).

Bij een niet functionerend projectteam‘ heb ik de hele afdeling bij elkaar geroepen, en we hebben het project opgebroken in tussenstapjes van elk een week. Op maandag keken we welke acties op dat moment de hoogste prioriteit hadden en hoe we die doelen op vrijdag konden bereiken. In de tussentijd zorgde ik ervoor dat alle vorderingen op een groot bord zichtbaar werden gemaakt, zodat iedereen wist waar in het proces we op welk moment waren.’

Jeff Sutherland, (interview in Managementboek.nl, februari 2015).

Het eindproduct is globaal bekend

Kenmerkend voor een met de scrum methode uitgevoerd project is dat alleen globaal bekend is wat precies er klaar moet zijn aan het eind van het project. Er wordt gewerkt met fixed time en budget (timeboxing). Er moet steeds na twee tot vier weken een werkend product of prototype zijn. Deze prototypes zijn bouwstenen voor een groter geheel. Staat bij ‘klassiek projectmatig werken het op te leveren resultaat centraal, bij scrum zijn deadlines heilig. Scrum past op te leveren resultaat (cq de scope) aan, niet de tijd.

Scrum in twaalf stappen

Laat ik voorop stellen (en me daarmee indekken) dat ik geen recht doe aan de rijkdom van de door Sutherland en anderen beschreven scrum aanpak. Hieronder vat ik scrum vrijpostig samen in twaalf stappen:

  • Kies een ‘producteigenaar’: iemand met visie op wat er geproduceerd moet worden. En vorm een klein team die het werk gaan uitvoeren. En een wijs een ‘scrummaster’ aan: iemand die het team helpt en hindernissen verwijdert.
  • Controleer of de producteigenaar het mandaat vanuit zijn achterban heeft om zelf besluiten te nemen. Een belangrijke taak van de producteigenaar is het bepalen van de functionaliteit en de prioriteiten aangeeft (wat moet het kunnen). Hij bepaalt ook opleverdata, geeft feedback op de opgeleverde producten, managet stakeholders en accepteert of weigert opleveringen. De eigenaar is één persoon en geen comité.
  • Zoek een scrummaster die het team ondersteunt door de leden te coachen op het vlak van zelforganisatie en multidisciplinair werken. Hij begeleidt het team bij het maken van producten. Een belangrijke taak is het verwijderen van belemmeringen in de voortgang en ten slotte faciliteert en begeleidt hij de ‘stand up meetings’.
  • Vorm een team van drie tot negen mensen, die zelfsturend aan de slag kunnen gaan. Het team bevat verschillende mensen met diverse vaardigheden. Ze leveren in korte sprints steeds nieuwe werkende tussenproducten of werkende prototypes op. Zoek teamleden die zich kunnen aanpassen aan de omstandigheden, die elkaars fouten accepteren om er van te leren en die op gezette tijden willen evalueren.
  • Maak het mogelijk dat teamleden, zowel teamleden, scrummaster en de producteigenaar, dagelijks samen kunnen werken, bij voorkeur op dezelfde plek.
  • Maak een lijst van alles wat gedaan moet worden om de visie van de producteigenaar te realiseren (in scrum taal de Product-backlog). Plan met het team welke taken er in de eerste ‘sprint’ (werkperiode, van een dagdeel tot een maand) af kunnen komen. Schuif die briefjes tijdens de sprint naar de kolom ‘te doen’ – en dan naar ‘bezig’ en ‘klaar’.
  • Voer de sprint uit totdat de geplande tijd voorbij is, en hopelijk is dan ook een groot deel van het beoogde eindproduct is opgeleverd. Vraag feedback van de producteigenaar.
  • Houd als team elke ochtend een scrumvergadering van maximaal een kwartier, waarin ieder teamlid vertelt wat hij de vorige dag heeft gedaan, wat hij vandaag gaat doen en wat de hindernissen zijn die hem of het team verhinderen het sprint-doel te behalen?. Bepaal vervolgens als team, naar aanleiding van de vorige iteratie (sprint) wat in de volgende sprint wordt opgepakt.
  • Maak een takenlijst en zet daarbij wat het snelst afmoet. Ken aan elke taak een grootte toe
  • Zet alle taken op plakbriefjes en plak die in de linkerkolom van een ‘scrumbord’ dat zichtbaar aan de muur hangt. Op het zogenoemde Scrumbord
  • Demonstreer aan het eind van de sprint het werkende product dat tijdens die sprint is gemaakt. Het hoeft geen geheel uitontwikkeld product te zijn, maar wel een uitontwikkelde module daarvan. Iedereen is hierbij welkom, zoals Sutherland het zegt: ‘niet alleen de producteigenaar, de scrummeester en team, maar ook aandeelhouders, managers, klanten, noem maar op.’ En evalueer de manier van werken van het team: bepaal wat er beter kan.
  • Begin zo snel mogelijk aan de volgende sprint-cyclus, en houd daarbij rekening met de ervaringen van het team met hindernissen en verbeteringen in het proces

Een paar kanttekeningen

Daar waar ik projecten gezien heb die door middel van een scrum methodiek aangepakt zijn, valt mij op dat het nog al wat vraagt van de betrokkenen. Betrokkenen moeten kunnen leven met een globaal omschreven projectresultaat en accepteren dat tijd (door timeboxing ) alles bepalend is en dat ze soms niet het gehoopte eindproduct krijgen. Teamleden moeten volledig beschikbaar zijn voor het project. En het is nodig dat er één gezamenlijke werkplek is voor het team. Deze voorwaarden zijn vooral in middelgrote en kleine projecten vaak te veel gevraagd. Deze projecten worden geleid door een deeltijd projectleider en het werk wordt uitgevoerd door teamleden die voor één of twee dagen zijn vrij gemaakt voor het project (en dan vaak nog niet eens op dezelfde dagen). En dan hebben we het nog niet over de producteigenaar die veel tijd in het project moet investeren (en terecht) en een volledig mandaat moet hebben (en dat in onze polder cultuur…).

Scrum voor niet-scrummers in 12 stappen

Naast software ontwikkeling wordt scrum (of elementen eruit) langzaam maar zeker en met vallen en opstaan, ook toegepast in andere gebieden. Voor me ligt het (zelfs voor iemand zoals ik die niet van scrum is) leesbare boek van Jeff Sutherland: Scrum - tweemaal zoveel doen in de helft van de tijd (2014). Ik denk dat veel van de principes van scrum ook toe te passen zijn door de gebruikers van andere projectmanagement methoden.

Projectmatig werken is gedoe, en het gaat bijna nooit van leien dakje. Dat maakt dat er een voortdurende queeste is naar de methode die het ‘gedoe’ minimaliseert. Laat ik vooropstellen dat dit niet zal gebeuren, want een project speelt zich immers altijd af in een beweeglijke en onzekere context. Zo is er lang geloofd dat Prince2, door handboeken en waterdichte procedures, deze zekerheid zou geven. Nu is er een tegenbeweging (ook afkomstig uit de software wereld) onder de titel ‘scrum’. Je kunt scrum volledig toepassen, maar je kunt elementen er uit ook voor andere projectmanagement methoden gebruiken.

Ik zie ook mijn collega’s soms worstelen met de toepasbaarheid van de lineaire (waterval) fasering. Een van de oplossingen, die al jaren wordt gebruikt, is de toepassing van een cyclische fasering. Cyclische faseringen worden gekenmerkt door het ontwikkelen van oplossingen in het licht van de op dat moment bekende eisen. Deze eisen worden vervolgens zo snel mogelijk getoetst aan de praktijk (prototypes). De leringen hieruit worden weer vertaald in nieuwe eisen en oplossingen. Deze aanpak levert meer snelheid en flexibiliteit op dan de klassieke lineaire aanpak. Agile als filosofie en Scrum als methode spelen in op deze behoefte aan flexibiliteit en snelle feedback.

Sutherland noemt een aantal uitgangspunten voor scrum. Als eerste, het project moet leuk zijn om te doen. Belangrijker is natuurlijk het product dat opgeleverd moet worden. Daarom is er naast een definition of fun, ook een definition of done (je moet weten wanneer je iets als klaar beschouwt), een backlog (takenlijst), sprints (korte periodes van twee tot vier weken waarin een werkend tussen product of prototype wordt opgeleverd).

Het eindproduct is globaal bekend

Kenmerkend voor een met de scrum methode uitgevoerd project is dat alleen globaal bekend is wat precies er klaar moet zijn aan het eind van het project. Er wordt gewerkt met fixed time en budget (timeboxing). Er moet steeds na twee tot vier weken een werkend product of prototype zijn. Deze prototypes zijn bouwstenen voor een groter geheel. Staat bij ‘klassiek projectmatig werken het op te leveren resultaat centraal, bij scrum zijn deadlines heilig. Scrum past op te leveren resultaat (cq de scope) aan, niet de tijd.

Scrum in twaalf stappen

Laat ik voorop stellen (en me daarmee indekken) dat ik geen recht doe aan de rijkdom van de door Sutherland beschreven scrum aanpak. Hieronder vat ik scrum vrijpostig samen in twaalf stappen:

  1. Kies een ‘producteigenaar’: iemand met visie op wat er geproduceerd moet worden. En vorm een klein team die het werk gaan uitvoeren. En een wijs een ‘scrummaster’ aan: iemand die het team helpt en hindernissen verwijdert.
  2. Controleer of de producteigenaar het mandaat vanuit zijn achterban heeft om zelf besluiten te nemen. Een belangrijke taak van de producteigenaar is het bepalen van de functionaliteit en de prioriteiten aangeeft (wat moet het kunnen). Hij bepaalt ook opleverdata, geeft feedback op de opgeleverde producten, managet stakeholders en accepteert of weigert opleveringen. De eigenaar is één persoon en geen comité.
  3. Zoek een scrummaster die het team ondersteunt door de leden te coachen op het vlak van zelforganisatie en multidisciplinair werken. Hij begeleidt het team bij het maken van producten. Een belangrijke taak is het verwijderen van belemmeringen in de voortgang en ten slotte faciliteert en begeleidt hij de ‘stand up meetings’.
  4. Vorm een team van drie tot negen mensen, die zelfsturend aan de slag kunnen gaan. Het team bevat verschillende mensen met diverse vaardigheden. Ze leveren in korte sprints steeds nieuwe werkende tussenproducten of werkende prototypes op. Zoek teamleden die zich kunnen aanpassen aan de omstandigheden, die elkaars fouten accepteren om er van te leren en die op gezette tijden willen evalueren.
  5. Maak het mogelijk dat teamleden, zowel teamleden, scrummaster en de producteigenaar, dagelijks samen kunnen werken, bij voorkeur op dezelfde plek.
  6. Maak een lijst van alles wat gedaan moet worden om de visie van de producteigenaar te realiseren (in scrum taal de Product-backlog). Plan met het team welke taken er in de eerste ‘sprint’ (werkperiode, van een dagdeel tot een maand) af kunnen komen. Schuif die briefjes tijdens de sprint naar de kolom ‘te doen’ – en dan naar ‘bezig’ en ‘klaar’.
  7. Voer de sprint uit totdat de geplande tijd voorbij is, en hopelijk is dan ook een groot deel van het beoogde eindproduct is opgeleverd. Vraag feedback van de producteigenaar.
  8. Houd als team elke ochtend een scrumvergadering van maximaal een kwartier, waarin ieder teamlid vertelt wat hij de vorige dag heeft gedaan, wat hij vandaag gaat doen en wat de hindernissen zijn die hem of het team verhinderen het sprint-doel te behalen?. Bepaal vervolgens als team, naar aanleiding van de vorige iteratie (sprint) wat in de volgende sprint wordt opgepakt.
  9. Maak een takenlijst en zet daarbij wat het snelst afmoet. Ken aan elke taak een grootte toe: 'mensen zijn slecht in het plannen vann werkuren, plan aan de hand van de relatieve omvang: klein, gemiddeld, groot' (Sutherland)
  10. Zet alle taken op plakbriefjes en plak die in de linkerkolom van een ‘scrumbord’ dat zichtbaar aan de muur hangt. Op het zogenoemde Scrumbord
  11. Demonstreer aan het eind van de sprint het werkende product dat tijdens die sprint is gemaakt. Het hoeft geen geheel uitontwikkeld product te zijn, maar wel een uitontwikkelde module daarvan. Iedereen is hierbij welkom, zoals Sutherland het zegt: ‘niet alleen de producteigenaar, de scrummeester en team, maar ook aandeelhouders, managers, klanten, noem maar op.’ En evalueer de manier van werken van het team: bepaal wat er beter kan.
  12. Begin zo snel mogelijk aan de volgende sprint-cyclus, en houd daarbij rekening met de ervaringen van het team met hindernissen en verbeteringen in het proces

Een paar kanttekeningen

Daar waar ik projecten gezien heb die door middel van een scrum methodiek aangepakt zijn, valt mij op dat het nog al wat vraagt van de betrokkenen. Betrokkenen moeten kunnen leven met een globaal omschreven projectresultaat en accepteren dat tijd (door timeboxing ) alles bepalend is en dat ze soms niet het gehoopte eindproduct krijgen.

Teamleden moeten volledig beschikbaar zijn voor het project. En het is nodig dat er één gezamenlijke werkplek is voor het team.

Deze voorwaarden zijn vooral in middelgrote en kleine projecten vaak te veel gevraagd. Deze projecten worden geleid door een deeltijd projectleider en het werk wordt uitgevoerd door teamleden die voor één of twee dagen zijn vrij gemaakt voor het project (en dan vaak nog niet eens op dezelfde dagen). En dan hebben we het nog niet over de producteigenaar die veel tijd in het project moet investeren (en terecht) en een volledig mandaat moet hebben (en dat in onze polder cultuur…).