Een van het meest voorkomende en begrijpelijke misverstand is dat lean alleen geschikt is voor fabricage of routine situaties, met een zich steeds herhalende procedure en een sterke nadruk op de reductie van variatie ofwel verspilling. Volgens mij kan dit misverstand goeddeels opgelost worden door lean in de context te plaatsen van wat organisaties nu bezig houdt, speciaal gelet op de risico’s die ze lopen.
Altijd als ik betrokken ben bij lean implementaties in de afgelopen jaren is de meest opvallende en vaak te horen opmerking dat lean is bedoeld voor herhaalde, sterk gestandaardiseerde processen en daarom niet geschikt is voor ontwikkeling of projecten. Een van de argumenten is dat alle bekende en uitgewerkte voorbeelden uit fabricage omgevingen komen, te beginnen met Toyota. Een ander argument is de sterke focus op reductie van verspilling in procedures. Een derde argument is dat lean slechts een toolbox is voor management om variatie en dus kosten te reduceren.
Inderdaad, de lean filosofie is ontwikkeld in massa productie omgevingen als antwoord op de vraag hoe de kwaliteit, zijnde fitness-for-use, te borgen in een situatie dat de concurrentie positie werd bepaald door de mate van efficiency: het realiseren van economies-of-scale door grote markten te bedienen met goede producten tegen lage kosten.
Essentieel voor het borgen van kwaliteit in die situatie was het begrijpen van de klant, het product en het proces volgens welke dat product tot stand komt. Gezien het belang van efficiency is het niet vreemd dat de nadruk ligt op reductie van variatie in de processen. En variatie is het resultaat van risico’s die men loopt: gebeurtenissen waarvan niet duidelijk of en wanneer ze optreden. Dus iedereen zoekt naar de mogelijkheden om deze risico’s te elimineren. Dat kan gaan over risico’s met de kwaliteit van input materialen, de risico’s van slecht geëquipeerde medewerkers, de risico’s van onbekende procedures of de risico’s van geen begrip van ‘de klant’. De eerder genoemde argumenten waarom lean niet geschikt is komen door deze associatie met efficiency.
Nu leven we in een tijd dat het leveren van hoge kwaliteit op een voorspelbare manier gewoon is. Gelet op concurrentie positie staat vandaag de dag de relatie met de klant, gebruikers en allerlei andere stakeholders centraal. Om concurrerend te zijn moeten organisaties niet alleen focussen op het steeds sneller vernieuwen van hun producten maar tevens op het herdefiniëren van haar producten en services. Dit betekent onder meer het nauw betrekken van gebruikers bij de ontwikkeling en het volop ruimte geven aan creativiteit. Met deze eisen worden de bronnen variatie midden in het development proces, het kritieke pad, geplaatst. En de grote vraag is weer hoe kwaliteit, tijdigheid en kosten in bedwang te houden.
In standaard procedures wil je risico’s vermijden of elimineren. In een ontwikkelomgeving moet je deze risico’s echter omarmen. No guts, no glory, klinkt dat in goed Engels. De vervolgvraag is dan ook hoe de gevolgen van risico’s tijdens ontwikkeling of projecten te minimaliseren. Dat betekent onder meer het verbeteren van de identificatie en kwalificatie van risico’s, het schatten van de impact, het bepalen hoeveel risico je kunt nemen en het definiëren van een ontwikkelproces op zo’n manier dat de grootste risico’s met de meest impact als eerste getackeld worden en risico’s in hun algemeenheid zo snel mogelijk geëlimineerd worden. Het spel is nu beheersen van risico’s, niet het voorkomen ervan.
Voor software ontwikkeling zijn diverse agile raamwerken beschikbaar om dit te tackelen. Verrassend genoeg zijn deze gebaseerd op lean gedachtengoed. Ik ben ervan overtuigd dat er geen fundamentele reden is dat lean niet werkt in een ontwikkel- of projectomgeving. Haar schaalbaarheid over disciplines en zelfs over organisatiegrenzen zijn zelfs grote pluspunten. Het betekent wel dat de toepassing afgestemd moet worden op de huidige focus en risico attitude. Daarover is nog veel te leren. Laten we starten met het verzamelen van verhalen in deze context.