Lean werken in de bouw

Met Lean-consultant Matijn van der Made ging ik in gesprek over de inzet van Lean in de bouw en softwareontwikkeling. 

Afgelopen maanden sprak ik met scrum masters, product owners en agile coaches. Ik vind het altijd leuk om bij iemand anders in de keuken te kijken en ervaringen uit te wisselen als het gaat om Lean en softwareontwikkeling. Dit keer maakte ik kennis met de bouw! Het was erg leerzaam en verhelderend om agile principes in een heel andere werkomgeving toegepast te zien worden. In deze blogpost vertel ik je meer over de verschillen en overeenkomsten die we ontdekten in dit gesprek.

Lean in de bouw

In de bouw wordt steeds meer gebruik gemaakt van lean planningen. “Het is onze uitdaging om efficiënter te werken en hogere kwaliteit te leveren” zegt Matijn. “In een bouwproject is dat geen kleine opgave. De hoofdaannemer schakelt een heel scala aan onderaannemers in: voor de electra, de vloeren, het stucwerk, etc. Ieder van die onderaannemers heeft eigen afspraken met de hoofdaannemer.” Hét recept voor suboptimalisatie dus: de ene onderaannemer heeft er geen belang bij om de ander te helpen, dus iedereen focust alleen op zijn eigen werkzaamheden. In de bouw is ook geen sprake van crossfunctionele teams: het zijn stuk voor stuk specialisten die geen overlappende vaardigheden hebben.

Het is onze uitdaging om efficiënter te werken en hogere kwaliteit te leveren. In een bouwproject is dat geen kleine opgave!

“Ik zag dat alleen de hoofdaannemer deze impasse kan doorbreken: hij kan de belangen van de individuele partijen oplijnen. Daarom heb ik mijn baan bij een elektrotechnisch installatiebedrijf opgegeven om me fulltime als lean consultant te kunnen inzetten bij hoofdaannemers en hun ketenpartners.”

Welke verschillen zijn er met lean-softwareontwikkeling?

Met Matijn heb ik de verschillende onderdelen van het proces vergeleken, vanaf de planning tot en met de oplevering. We ontdekten opvallende overeenkomsten én verschillen. Deze zeven hoofdpunten wil ik in deze blogpost met je delen.

1. Implementatie-traject
In de bouw vindt de transitie plaats van het traditionele (directief) werken naar samenwerken; in software-ontwikkeling is deze transitie al langer aan de gang. Dat vraagt een andere houding van verschillende partijen: de uitvoerder moet de omschakeling maken naar meer coachend begeleiden. En van de werkvloer vragen we meer assertiviteit en initiatief. Ik herken dat wel van de eerste scrum-projecten bij Infi. Je vraagt heel andere vaardigheden van de teamleden.

Ik was positief verrast over het gemak waarmee developers in gesprek gingen met de opdrachtgever en hoe snel ze de brug wisten te slaan tussen de taal van de business en de taal van de technologie. En wat ikzelf echt heb moeten afleren: het toedekken van fouten en tegenvallers. Dat was zo’n vanzelfsprekende reflex in het ‘oude werken’. Maar nu zie ik hoeveel energie er los komt bij alle teamleden (inclusief de opdrachtgever) als je je problemen deelt.

2. Bouwers willen bouwen
“Tja, eigenlijk zitten die bouwers helemaal niet zo te wachten op meetings”, zegt Matijn. “‘Nog meer post-its plakken’, zeggen ze dan.” Deze ‘doener’-mentaliteit vind je niet alleen in de bouw. Ook onder developers hoor ik vaak ‘Goede refinement, maar nu weer lekker aan het werk!’. Alsof de refinement geen onderdeel van je werk is! Voor de retrospectives geldt dat natuurlijk nog sterker. Als scrum master let ik er altijd op dat er heldere en concrete verbeteracties uit volgen, zodat je meteen de meerwaarde van de meeting ziet. Lees meer hierover in mijn blogpost over ROTI.

3. Feedbackloops
Matijn vertelt: “Ik ben aan het experimenteren met verschillende feedback loops. Deze wil je het liefst zo kort mogelijk hebben zodat de verbeteringen direct doorgevoerd kunnen worden. Hiervoor kun je werken in batches van gelijksoortig werk. Bijvoorbeeld: bij de inrichting van een verzorgingshuis zou je de lessen van het inrichten van de eerste kamer kunnen toepassen bij de inrichting van de tweede. Maar zo ver zijn nog niet veel bedrijven in de bouw. Klein beginnen werkt goed. Zorg dat er door het organiseren van een dagstart interactie ontstaat tussen de verschillende disciplines. Zet om te beginnen een aantal voor de klant en het team belangrijke onderwerpen op de agenda en kijk hoe je die als team positief kan beïnvloeden.” 

Qua feedbackmogelijkheden hebben wij het in de softwareontwikkeling best luxe. Met de juiste tools zie je al tijdens het programmeren dat je nieuwe code de tests doen falen. Daarnaast duurt de ontwikkelcyclus van ‘ready for dev’ tot ‘done’ hooguit een paar dagen. En de meeste geschreven code is heel meetbaar: de tests slagen, of ze slagen niet. In de bouw zijn er veel meer manieren om ‘half werk’ op te leveren.

Klein beginnen werkt goed. Zorg dat er door het organiseren van een dagstart interactie ontstaat tussen de verschillende disciplines.

4. Teamsamenstelling
Een groot verschil tussen de bouw en softwareontwikkeling zit in de teamsamenstelling. In de bouw bestaat het ‘team’ feitelijk uit een reeks specialisten die niets anders doen dan de taak waarvoor ze zijn ingehuurd. Bij Infi werken we ook met specialisten, maar die hebben de vaardigheden om ook andere werkzaamheden op te pakken. Daardoor kun je de workload makkelijker verspreiden. 

Bovendien werken we allemaal aan hetzelfde doel: zoveel mogelijk value leveren. Ook als je daarvoor iets op moet pakken dat eigenlijk niet jouw expertise is. Dat gemeenschappelijke doel ontbreekt in de bouw: de onderaannemers richten zich alleen op hun eigen specifieke taak, niet op wat voor het gehele project het beste is.

5. Stabiel team
Hoofdaannemers hebben eigenlijk maar één selectiecriterium voor onderaannemers: de prijs. Je weet nooit zeker of je bij een volgend project opnieuw geselecteerd wordt. “Dat gebrek aan cohesie is een van de grootste uitdagingen”, vertelt Matijn. “Welke motivatie heb je om een hoge kwaliteit te leveren als je puur op prijs geselecteerd wordt? En waarom zou je een stapje extra doen voor een ander, als de kans dat je elkaar nog een keer treft nihil is?”

Daarom streeft Matijn naar een ommekeer in de manier waarop aannemers naar de onderaannemers kijken. “Kies er één of twee per vakgebied en bouw daarmee een band op. Je zult zien dat de samenwerking veel soepeler verloopt en dat de proceskosten omlaag gaan.” Dat is precies hoe wij bij Infi ook met onze opdrachtgevers willen werken. We willen een nauwe relatie aangaan, zodat je beslissingen kunt nemen die op de lange termijn de meeste waarde creëren.

6. Planning
Het scrumbord op de bouwplaats is nauwelijks agile te noemen. Er ligt voor de komende twintig weken al precies vast welke werkzaamheden op welke dag zullen plaatsvinden. Het scrumbord is gewoon een weergave van de planning van de huidige week. In de stand-up wordt daarom vooral gekeken naar overschrijdingen: wie heeft zijn werk niet op tijd af en welke gevolgen heeft dat voor anderen.

“Daar is een goede reden voor: om het werk uit te kunnen voeren moeten a. de voorafgaande werkzaamheden afgerond zijn, b. de juiste mensen gereed staan en c. alle benodigde materialen geleverd zijn”, zegt Matijn. “Wij kunnen niet zo flexibel zijn als jullie developers. Natuurlijk blijft het een uitdaging om te kijken welke stappen je kunt zetten om wél zo flexibel mogelijk te zijn.”

7. Upfront design
In de bouw heeft de architect het ontwerp al tot in detail uitgewerkt voordat de aannemer in beeld komt. Er is dus geen ruimte voor aanpassingen. Matijn: “Het lean-aspect zit voor ons veel meer in de procesinrichting: hoe krijg je de verschillende onderaannemers opgelijnd zodat ze echt samenwerken, uitloop tijdig inzichtelijk wordt en ze snel kunnen reageren.” Dat is een groot verschil met software-ontwikkeling natuurlijk: daar probeer je (ontwerp)beslissingen uit te stellen tot het laatste moment. Per sprint kijk je wat voor de komende sprint de functies zijn die de meeste waarde toevoegen aan het product.

Herkenning en weerstand

Ik vond het heel erg leuk om te zien welke elementen en principes van Lean in de bouw toegepast worden en hoe Matijn om de verschillende obstakels heen weet te manoeuvreren. Een deel was heel herkenbaar: de weerstand tegen ‘al die meetings’ bijvoorbeeld. Andere obstakels zijn typisch voor de bouw. Vooral alle afhankelijkheden en gedetailleerde plannen, die het lastig maken om écht agile te werken.

Het was heel interessant om de principes en practices waarmee ik zo vertrouwd ben geraakt in de afgelopen jaren op een heel ander domein toe te passen. Dank je wel Matijn! Zeker voor herhaling vatbaar! 

Werk je zelf in een interessante omgeving met agile principles? Stuur mij een berichtje. Ik zou het leuk vinden om van gedachten te wisselen!

[Dirk is project & scrum master bij Infi]

Gezocht: ondernemende nerds!

› Wil jij je hersens bij ons laten kraken?

Wil je iets waarmaken met Infi?

Wil jij een eigen webapplicatie of mobiele app waarmee jij het bij anderen maakt?

Waargemaakt door de nerds van Infi.
Nerds met liefde voor softwareontwikkeling en die kunnen communiceren. En heel belangrijk: wat we doen, doen we met veel lol!

Wij willen het fixen. Laat jij van je horen?

Voor wie heb je een vraag?