Privacy is belangrijk voor ons, dus u heeft de mogelijkheid om bepaalde soorten opslag uit te schakelen die mogelijk niet noodzakelijk zijn voor de basiswerking van de website. Het blokkeren van categorieën kan uw ervaring op de website beïnvloeden. Meer informatie.
In 2001 legde het Agile Manifesto de basis voor een andere manier van software ontwikkelen. Kleine teams, korte iteraties, werkende software boven uitgebreide documentatie. Veel van die principes zijn direct geleend uit Lean: voorraden verkleinen, flow creëren, kwaliteit inbouwen in het proces.
De stap van watervalontwikkeling naar Scrum is feitelijk dezelfde stap die Toyota eerder zette in de productie: stapels werk tussen stappen wegnemen. Analyse, bouw en test werden samengebracht in één team, in één sprint. Problemen die daarvóór pas laat aan het licht kwamen, werden zichtbaar voordat ze groot werden.
Dat was een grote stap vooruit. Maar het was stap één.
Agile heeft een aantal Lean-tools naar de softwareontwikkeling gebracht, maar de rest van de waardestroom bleef onaangeraakt. Een Scrum team werkt tegenwoordig soepel, maar de stappen ervoor en erna, van het identificeren van een behoefte tot portfolio-planning, integratie, marketing en deployment, bevatten nog steeds stapels werk en lange wachttijden.
Agile heeft de lokale efficiëntie van het development team verbeterd. De end-to-end doorlooptijd van idee tot productie is bij veel organisaties nauwelijks veranderd.
Maar er is iets dat nóg fundamenteler ontbreekt: probleemoplossing.
Een retrospective lijkt op probleemoplossing. Een team spreekt af wat beter kan, maakt een paar actiepunten, en gaat door. Maar wat er in de meeste retrospectives gebeurt, is dit: iemand noemt een vage zorg ("stories zijn onduidelijk"), het team springt naar een oplossing ("we stellen een Definition of Ready op"), en drie weken later is de afspraak vergeten of werkt ze niet.
Dat is geen probleemoplossing. Dat is wishful thinking met een notitieboekje.
In Lean onderscheiden we twee dingen die er uiterlijk hetzelfde uitzien maar fundamenteel anders zijn: kaizen en touzen. Kaizen is verbetering. Touzen is verbetering die nooit nodig had moeten zijn, rework die je uitvoert omdat de onderliggende oorzaak nooit is aangepakt.
Veel verbeterwerk in Agile is touzen. Teams lossen symptomen op, niet oorzaken.
De Lean aanpak werkt met een probleemoplossingsstrechter. Die begint bij een vage zorg, maar stopt daar niet. De stap die de meeste teams overslaan, is het verduidelijken van het werkelijke probleem: wat is er precies mis, wanneer, hoe vaak, en waar in het proces? Pas daarna ga je naar de gemba, de plek waar het werk daadwerkelijk gebeurt, om de directe oorzaak te zoeken. Van directe oorzaak ga je naar diepere oorzaken, totdat je de grondoorzaak bereikt. Dán ontwikkel je maatregelen. Daarna bevestig je het effect. Daarna standaardiseer je.
Dat is een ander soort gesprek dan "we schrijven betere stories". Het vraagt dat een teamleider of Scrum Master geleerd heeft om problemen te onderzoeken in plaats van op te lossen.
Stel dat stories regelmatig crashen tijdens de sprint doordat vereisten onduidelijk zijn. Een typische retrospective-aanpak: Definition of Ready opstellen, checklist toevoegen aan het proces.
Een Lean probleemoplossingsaanpak vraagt eerst: welke stories crashen precies? Zijn het stories van een bepaald type, uit een bepaalde bron, na een bepaalde stap in de refinement? Ga naar de plek in het proces waar stories worden aangemaakt. Kijk mee hoe dat gaat. Vraag mensen wat ze weten en wat ze niet weten op het moment dat ze een story schrijven.
Daarna: wat is de directe oorzaak? Misschien zijn er aannames over domeinkennis die niet expliciet worden gemaakt. Misschien ontbreekt een structurele terugkoppeling van development naar de business-analist. Dat zijn andere grondoorzaken dan "stories zijn onduidelijk", en ze vragen andere maatregelen.
Het verschil zit niet in de tools, maar in het denken. Lean probleemoplossing leert teams te onderscheiden wat ze waarnemen, wat ze aannemen, en wat ze weten. Dat is een vaardigheid. Retrospectives trainen die vaardigheid niet.
Probleemoplossing is niet het enige dat Lean toevoegt aan softwareontwikkeling. Marcel Aartsen van Thales Nederland, die jarenlang als trainer verbonden was aan het Lean Management Instituut en nu verantwoordelijk is voor Lean binnen Thales, beschreef tijdens de LMI Vriendendag een bredere agenda.
Value stream management gaat over het ontwerpen van de volledige delivery-stroom, van het moment dat een behoefte wordt geïdentificeerd tot het moment dat software in productie draait. Die stroom is bij de meeste organisaties nooit bewust ontworpen. Hij is gegroeid. En in die gegroeide stroom zitten wachttijden, handoffs en buffers die niemand meer ter discussie stelt.
Set-based concurrent engineering vraagt om een andere manier van beslissingen nemen in softwarearchitectuur. De gangbare aanpak is: kies één richting, bouw, test of het werkt, pas aan. Die aanpak lijkt op hoe Samuel Langley zijn vliegtuig bouwde: zeventien jaar, 70.000 dollar, en nooit gevlogen. De gebroeders Wright werkten anders: eerst leren door te testen, dan bouwen. Ze besteedden 22 maanden aan hun eerste succesvolle ontwerp en speneerden duizend dollar. Software-architecten die leren werken met causal influence diagrams en trade-off charts maken betere beslissingen eerder in het proces, waardoor kostbare herwerk later in de keten wordt voorkomen.
Hoshin Kanri adresseert het gat tussen strategie en uitvoering. OKR's en andere goal-setting frameworks helpen organisaties doelen formuleren. Maar het merendeel van de frameworks stopt daar. Hoshin Kanri gaat verder: het zorgt dat de vertaling van strategie naar dagelijks werk geborgd is, op elk niveau van de organisatie. Dat is leiderschapsontwikkeling, niet alleen planningsdiscipline.
Lean toevoegen aan een Agile omgeving is geen tooling-vraagstuk. Je hebt geen nieuw framework nodig. Je hebt mensen nodig die leren denken als Lean-probleemoplossers.
Dat begint bij teamleiders en Scrum Masters die leren het verschil te zien tussen een symptoom en een oorzaak. Die weten hoe ze een probleem verduidelijken voordat ze een oplossing zoeken. Die de gemba opzoeken in plaats van vanuit de vergaderkamer te redeneren.
In een softwareomgeving is de gemba de plek waar code wordt geschreven, waar stories worden geclaimd, waar bugs worden gevonden. Lean vraagt dat leidinggevenden die plek kennen, niet alleen beheren.
Agile heeft softwareontwikkeling verbeterd. Maar Lean heeft meer te bieden dan wat Agile in 2001 heeft meegenomen. Organisaties die de volgende stap willen zetten, van symptomen oplossen naar oorzaken aanpakken, van lokale optimalisatie naar end-to-end flow, vinden in Lean het denkkader dat daarvoor nodig is.
Het Lean Management Instituut begeleidt softwareteams en IT-organisaties bij het ontwikkelen van die vaardigheden. Neem contact op als je wil weten wat er concreet op tafel ligt voor jouw team.
Dit blog is mede geïnspireerd op de sessie "Van Agile naar Lean" die Marcel Aartsen (Thales Nederland) verzorgde tijdens de LMI Vriendendag 2026.
