Starten met Scrum in de bouw? | Priom | Denk, doe en leer met Agile en Scrum

Starten met Scrum in de bouw?

Even snel waar ik vandaan kom: Al jaren mag ik mij leidinggevend en processturend bezig houden met een grote diversiteit aan projecten. Projecten managen heb ik in de basis geleerd in de vastgoedsector.  Mijn drive is continu te willen ontwikkelen, op zowel persoonlijk als professioneel vlak. Ik heb hierbij een lichtelijk obsessieve focus op
“anders denken / anders doen”. Dit komt tot uiting als grote promotor van Agile werken met nadruk op Scrum met een vleugje Lean. Op dit moment ben ik met allerlei leuke klussen bezig om Nederland een stukje Agiler te maken.
 
Hoewel Scrum is ontstaan voor het ontwikkelen van software, blijkt het veel breder inzetbaar als een algemeen project / programma management benadering. Deze blog gaat over het starten met Scrummen in de bouw aan de hand van de drie rollen binnen Scrum en twee van de meetings in Scrum. Er is nog veel meer over te zeggen en zal de komende blogs zeker aan de orde komen. Eerder schreef ik al een blog scrum in een notendop waarin alle meetings en rollen kort belicht zijn.
 

(Scrum)rollen in de bouw

De belangrijkste rollen in Scrum zijn; de "ScrumMaster", die vooral faciliteert; de "Product Owner", die de belanghebbenden vertegenwoordigt; en het "Team", een cross-functionele groep van mensen die de feitelijke analyse, ontwerp, implementatie, testen, etc. doen. Laten we eens beter kijken naar deze rollen en zien hoe ze kunnen worden toegepast in de bouw.
 
Een scrumteam bestaat uit maximaal 9 personen. Je zorgt dat elke discipline aanwezig is in dit team. Vanuit elke keten in de bouw neemt iemand plaats in het team. Eigenlijk zou elke keten een scrummaster, productowner en development team moeten hebben waarin ze hun eigen projecten draaien. In agile termen Scrum of scrums, vooralsnog beperk ik me tot één team.
 
De "Scrum master" beheert het proces en beschermt het team tegen afleiding. Hij verwijdert alle belemmering zodat het team zich kan blijven ontwikkelen. De Scrum master inspireert het team om de juiste taken te doen, en kan zelfs inhoudelijk taken oppakken. Hij of zij moet goede communicatieve vaardigheden hebben en communiceren met zowel het team en productowner. De Scrum master moet in staat zijn om de status van de sprint te kunnen meten. De Scrum Master inspireert het team om het verwachte product te leveren.
De Scrummaster zou ingevuld kunnen worden door diverse rollen, denk aan bijvoorbeeld aan een uitvoerder. Hij kan obstakels, die van invloed zijn op de voortgang van de werkzaamheden identificeren en verwijderen. Obstakels als gevolg van onduidelijke of onuitvoerbaar eisen moeten worden meegedeeld aan de productowner.
 
De “Productowner" (producteigenaar) is de opdrachtgever. Hij heeft het meeste belang bij het (software)product dat gemaakt wordt. Hij zorgt ervoor dat de rekening betaald wordt. Hij beheert ook de backlog (de brokken werk), hij bepaalt wat er moet gebeuren en in welke volgorde.
Een senior opzichter zou bijvoorbeeld prima een invulling kunnen gaan geven aan de rol van productowner, hij of zij moet kennis hebben van en commitment hebben op de visie van het totale project. En zal de interne bedrijfsdoelstellingen in lijn met de behoeftes van de stakeholders moeten krijgen. Immers de opzichter communiceert ook met zijn belanghebbende, dit doet een productowner ook.
 
Het "Team" moet tijdens de sprint in staat zijn ongestoord te werken en niet door externe invloeden afgeleid worden. Zij zijn zelf verantwoordelijk voor de taken en het tijdspad in de sprint. Het is prima als teamleden contact opnemen met belanghebbenden voor details over de vereisten van een cluster werk. Maar buitenstaanders worden buiten het team gehouden en mogen de individuele teamleden niet storen tijdens een sprint. Buitenstaanders (stakeholders) communiceren met de productowner.
 

Sprintplanning en de Daily Scrum

Het doel is om een werk in 'brokken’ of ‘clusters' te verdelen. Deze clusters worden in volgorde van prioriteit gerangschikt. Door te schatten hoeveel werk een cluster is, kan worden bepaald hoeveel clusters er in een sprint worden opgepakt. Een sprint is een periode tussen doorgaans een week of een maand. Het plannen van deze werkzaamheden gebeurt in een bijeenkomst die sprintplanning wordt genoemd. Zodra de sprint gepland is kan het team aan de slag om de taken af te handelen. Het team bewaakt de voortgang, plant een dagelijkse stand-up-bijeenkomst, genaamd de Daily Scrum. Hierover schreef ik al eerder deze blog. Aan het einde van elke sprint heeft het team een product gemaakt dat gebruikt kan worden en dat aan de belanghebbenden tijdens een Sprint review wordt gepresenteerd.
 
De product owner is eigenaar van het werk en zal de sprintplanning leiden en ik denk dat het ongeveer zo zou gaan: 
 
Uitvoerder: Een van de brokken werk deze sprint is het plaatsen en afwerken van de de kozijnen in kamer X. Hoeveel werk schatten we in dat het is? Uiteraard gaan de deelnemers pokeren om de hoeveelheid werk te bepalen (zie deze blog)
 
Timmerman: Nou, we moeten 3 taken realiseren en in dit korte tijdsbestek betekent dat ik 3 medewerkers meer nodig heb om deze klus te klaren.
 
Schilder: Wordt met plaatsen en afwerken ook bedoeld het afhangen van de deuren?
 
Installateur: Gaat het hier om het afwerken van de buiten kozijnen of binnenkozijnen.
 
Uitvoerder: Ok, het betreft het plaatsen van de binnenkozijnen, zonder afhangen van de deuren.
 
Timmerman: aha, nu is het me duidelijk en kan ik deze klus goed inschatten.
 
Deze gesprekken geven inzicht in de klus, waardoor er beter gepland kan worden in de sprintplanning. Zo zou de timmerman ook kunnen zeggen: “ in dit korttijdsbestek kan ik geen 3 timmermannen extra krijgen om de kozijnen op tijd geplaatst te krijgen. Deze kwestie ligt dan open op tafel. Doordat elke discipline aanwezig is, kan uit de totaal sprintplanning blijken dat de voorman van bijvoorbeeld de installateurs nog 3 man over heeft voor deze sprint. Deze medewerkers van het installatie bedrijf zouden de timmerman kunnen helpen de taak binnen deze sprint af te ronden. Het werken in korte tijdsspanne zorgt er mede voor dat de medewerkers op de bouw ook meer plezier hebben in het afmaken van een deel van de klus, dan dat ze uitzicht hebben op bouwplannen die maanden of soms wel jaren duren.
 
In de sprintplanning zijn een groot deel van de belangrijkste spelers in de bouw op elkaar afgestemd en heeft al geleidt tot een kortere bouwtijd. De faalkosten zijn drastisch verminderd door het wegnemen van onjuiste veronderstellingen. Het team levert na elke sprint het gemaakte werk op aan de opzichter en doet dit aan de hand van de specs die opgesteld zijn door de productowner met bv ingenieur en architect. Het opleveren van deelresultaten gebeurt in de review. Waarna het volledige team aansluitend de review de sprint doorneemt door elkaar feedback te geven in de zo geheten retrospective, deze meeting zorgt ervoor dat proces, mens en product door ontwikkeld. Hierover een volgende keer meer.
 
In de perfecte wereld zouden ook architecten en ingenieurs betrokken worden bij de sprintplanning. In de ontwikkeling van software worden de mensen die schrijven aan de eisen en testers altijd betrokken bij deze bijeenkomsten. Dat komt omdat alle software toetsbaar en aanvaardbaar moet zijn. In dezelfde zin geldt dit ook voor de bouw. Stel je de continuïteit en waarde voor die het kan brengen voor het project!
 

Daily stand-up

Elke dag tijdens een sprint is er een dagelijkse staande vergadering, genaamd de daily stand-up vergadering. Tijdens deze bijeenkomst, waarin alle teamleden aangeven wat ze gisteren deden, wat ze aan het doen zijn en gaan doen. En bespreekt daarin eventuele obstakels die de voortgang van de af te handelen taken van het project in de weg staan. Elk obstakel of probleem wordt geparkeerd, zodat direct na de stand-up deze obstakels verwijderd kunnen gaan worden. De vergadering begint elke dag op dezelfde tijd. De reden waarom het een staande meeting is, is omdat het kort genoeg is om niet de  behoefte te hebben om te gaan zitten. Dit staand “vergaderen zorgt op voor een actievere deelname van de leden. Overigens is het een goede gewoonte om staande te vergaderen en geen Scrum vereiste. De daily stand-up duurt 15 minuten. Als door een een teamlid een obstakel wordt geïdentificeerd, is het aan de Scrum master dit probleem te tackelen. Dit probleem kan ook op de productowner betrekking hebben. Hij is niet verplicht, maar vaak wel wenselijk dat deze persoon deze vergaderingen bijwoont, het geeft hem een dagelijkse statusupdate. De daily stand-up bijeenkomst geeft inzicht in de voortgang van het project elke dag weer. Het dient ook als een kans voor de coördinatie tussen alle disciplines op de bouw. Ze zullen allemaal weten wat de ander die dag aan het doen is en in staat zijn om na de stand-up dit verder te stroomlijnen. Door het voeren van de daily stand-up, zal het team als een goed geoliede machine gaan werken en daardoor de efficiëntie verhogen en faalkosten verminderen.
 

Conclusie

Ik zie grote kansen in het gebruik van Scrum in de bouwsector en ik hoop dat deze blog intrigeert om meer te weten willen komen over Scrum. Ik denk dat het een enorm concurrentievoordeel biedt!
 
 
 
 
 
 
 

Deel deze Blog