Vlak voor mijn zomervakatie werd ik gebeld door collega Rob, een business consultant. “Jij moet eens met de CIO van mijn klant praten,” zegt hij. “Die is bezig om zijn hele IT-organisatie te herstructureren.” Even is het stil. Rob bouwt de spanning genadeloos op. “Hij past daarbij de lean principles van Toyota toe,” vervolgt hij, ”en die sluiten volgens mij perfect aan bij de manier waarop jij agile software development propageert.”
Mijn nieuwsgierigheid is gewekt. Gelukkig sta ik niet meteen met mijn mond vol tanden. Ik herinner me dat ik enkele jaren geleden een boek over het onderwerp heb gelezen. Van Mary en Tom Poppendieck – inderdaad man en vrouw. Maar dat handelde over het toepassen van de lean principles op software development, en niet op het reorganiseren van organisaties. Mary en Tom Poppendieck beschouwen software development als een vereenvoudige vorm van product development, zoals het ontwikkelen van een nieuw type auto. Deze visie is in zoverre bijzonder dat de meeste hogere managers in ons vak nog altijd lustig kwetteren over ontwikkelfabrieken, waar nieuwe software haast als vanzelf van de band rolt. Maar software development is een kennisintensief, creatief proces. We maken maatwerk, en geen duizenden nagenoeg identiek geconfigureerde auto’s. Hoog tijd om deze T-Ford metafoor naar de schroothoop af te voeren. Net op het moment dat ik, ook na enkele gesprekken met deze CIO, besluit meer energie in lean software development te steken ontdek ik het nieuwe boek van Tom en Mary Poppendieck. Implementing lean software development heet het.
De Poppendiecks laten zien dat de (zeven) lean principles uitstekend passen op agile methodieken – door hen steevast empirical development genoemd. Het boek start met een korte beschouwing van de lean principles. Een korte bloemlezing. De bekendste is natuurlijk: Eliminate Waste. Focus op datgene dat waarde toevoegt, schrijven de auteurs. Al het andere is waste. Ook werk dat half af is, zoals beschikken over een volledig uitgewerkt ontwerp, zonder ook maar een regel code te hebben geschreven, is waste. Zo’n ontwerp veroudert, groeit en bovenal voegt nog geen waarde toe. In een recente discussie met architecten, analisten en pakken van McKinsey stel ik de prikkelende vraag wie er meer waarde toevoegt in een project: de analist of de developer? Leveren we documenten op of software? Een volgend lean principle dan maar? Principle nummer drie
luidt: Create Knowledge. Mensen doen voortdurend nieuwe kennis op in projecten, en vooral tijdens het ontwikkelen van de software. Te vaak wordt dit voortschrijdend inzicht als ongewenst uitgebannen. In agile software development wordt voortschrijdend inzicht echter omarmd, met als gevolg betere software met een hogere graad van acceptatie. Mijn favoriete lean principle blijft echter nummer vier: Defer Commitment. Mijn motto is: stel niet uit tot morgen wat je overmorgen ook nog kunt doen. Hoe lui dit ook moge klinken, overmorgen neem je betere beslissingen. Je weet meer. Je hebt meer geleerd. Het dichtspijkeren van projectplannen, zoals ik projectleiders te graag zie doen, leidt tot starheid en inflexibiliteit, eigenschappen die je je niet kunt veroorloven in een project. Taiichi Ohno van Toyota spreekt het verlossende woord: “If one sticks to the idea that once set, a plan should not be changed, a business cannot exist for long”.
De serene rust die het Japans aandoende eerste deel van Implementing Lean Software Development uitstraalt is verzadigend. Als dan ook het punt bereikt wordt dat Mary en Tom Poppendieck ieder van deze zeven principes in een eigen hoofdstuk eren, wordt het boek langgerekt. Leuke praktische tips worden afgewisseld met te veel anekdotes, waarvan er te veel uit andere industriën afkomstig zijn. Leuk om in te bladeren, maar minder beklijvend dan het eerste deel. Zonde eigenlijk. Eliminate waste lijkr me.