artikel

Scrummen volgens Rudy Kor

Projectmanagement

Projectmanagementicoon Rudy Kor geeft een korte samenvatting van de methode ‘scrummen’.

Scrum: een methode om snel producten op te leveren
Projectmatig werken is gedoe, en het gaat bijna nooit van een leien dakje. Dat maakt dat er een voortdurende queeste is naar de methode die het ‘gedoe’ minimaliseert. Laat ik vooropstellen dat we deze methode niet gaan vinden, want een project speelt zich altijd af in een beweeglijke en onzekere context. Zo is er lang geloofd dat de methode Prince2, door handboeken en waterdichte procedures, deze zekerheid zou geven. Nu is er een tegenbeweging (ook afkomstig uit de De lineaire fasering helpt vaak niet en er kan beter gebruik worden gemaakt van een cyclische fasering. Cyclische faseringen worden gekenmerkt door het ontwikkelen van oplossingen in het licht van de op dat moment bekende eisen. Deze oplossingen (prototypes) 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
Alweer een aantal jaren geleden is door een groep softwareontwikkelaars, onder aanvoerderschap van Jeff Sutherland, het ‘Manifest voor agile softwareontwikkeling’ 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 een van de agile-methoden, is dat men ervanuit gaat dat klanttevredenheid ontstaat door snelle (binnen vier weken) en continue levering van werkende (deel)producten.

Scrummen moet wel leuk zijn
In het boek Scrum – tweemaal zoveel doen in de helft van de tijd van Jeff Sutherland (2014) staat 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 zijn 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 tussenproduct of prototype wordt opgeleverd).
Kenmerkend voor een met de scrummethode uitgevoerd project is dat alleen maar globaal bekend is wat er klaar is aan het eind van het project. Er wordt gewerkt met fixed time en fixed 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 het op te leveren resultaat (c.q. de scope) aan, niet de tijd.

Er is een aantal condities die moeilijk te realiseren zijn
Bij projecten die door middel van een scrummethodiek zijn aangepakt, valt mij op dat er nogal wat wordt gevraagd van de betrokkenen. Betrokkenen moeten kunnen leven met een globaal projectresultaat en accepteren dat de tijd (door timeboxing) allesbepalend 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 deeltijdprojectleider en het werk wordt uitgevoerd door teamleden die voor één of twee dagen zijn vrijgemaakt 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 poldercultuur…).

Scrum je project in twaalf stappen
Scrum (of elementen eruit) wordt langzaam maar zeker en met veel vallen en opstaan, ook toegepast in andere gebieden dan softwareontwikkeling. Zo stond op 24 januari 2015 in het NRC een artikel onder de kop: ‘Scrum jij al? Bij Apple doen ze ’t wel’. Je gaat je bijna afvragen: als al deze succesvolle organisaties scrummen, wie zijn de niet-scrummers om de projecten niet al ‘scrummend’ te realiseren?

Twaalf stappen
Laat ik vooropstellen (en me indekken) dat ik geen recht doe aan de rijkdom van de scrumaanpak door deze samen te vatten in onderstaande twaalf stappen om de vraag te beantwoorden: hoe scrum je in je project?

1. Kies een ‘producteigenaar’: iemand met visie op wat er geproduceerd moet worden. Vorm een klein team dat het werk gaat uitvoeren. En 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 het aangeven van prioriteiten. 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 gebied van zelforganisatie en multidisciplinair werken. De scrummaster begeleidt het team bij het maken van producten. Een belangrijke taak is ook 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 mensen met verschillende vaardigheden. Zij 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 ervan te leren en die op gezette tijden willen evalueren.

5. Maak het mogelijk dat teamleden – zowel de leden, de scrummaster als de producteigenaar – dagelijks samen kunnen werken, bij voorkeur op dezelfde plek.

6. Maak een lijst van alles wat moet worden gebouwd om de visie van de producteigenaar te realiseren (in scrumtaal: de ‘product-backlog’).

7. Plan met het team welke taken er in de eerste ‘sprint’ (werkperiode, van een dagdeel tot een maand) af kunnen komen.

8. Zet alle taken op post-it’s en plak die in de linkerkolom van een ‘scrumbord’ dat zichtbaar aan de muur hangt. Schuif de post-it’s met taken tijdens de sprint naar de kolom ‘te doen’ – en dan naar ‘bezig’ en ‘klaar’.

9. Voer de sprint uit totdat de geplande tijd voorbij is; hopelijk is dan ook een groot deel van het beoogde eindproduct opgeleverd. Vraag feedback van de producteigenaar.

10. 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. Bepaal als team, naar aanleiding van de vorige iteratie (sprint) wat in de volgende sprint wordt opgepakt.

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 scrummaster en het 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 sprintcyclus en houd daarbij rekening met de ervaringen van het team met hindernissen en verbeteringen in het proces.
Auteur: Rudy Kor (met dank aan J.Sutherland, 2014)

Reageer op dit artikel

Gerelateerde tags

Lees voordat u gaat reageren de spelregels