Software Ontwikkel Methodologieën: Lean vs Agile Principes

“Lean” en “Agile” zijn termen die de laatste tijd veelvuldig in de mond worden genomen, vaak als het gaat om softwareontwikkelmethodieken, projectmanagement of organisatiestijlen.

Maar vraagt u zich ook wel eens af:

Wat is Lean? Wat is Agile? Is er een verschil?

Merriam-Webster Dictionary definieert Agile als “een snel, vindingrijk en aanpasbaar karakter hebben, of gekenmerkt worden door het vermogen om snel en gracieus te bewegen.”

Lean wordt simpelweg gedefinieerd als “dun en gezond, of met weinig of geen vet.”

Op basis van deze definities kunnen we aannemen dat iemand die lean is en iemand die agile is, veel gemeenschappelijke kenmerken kunnen hebben. Hetzelfde geldt in de context van softwareontwikkeling.

Wat is Agile? What is Lean?

Agile is nu algemeen bekend in de technologie wereld als een set van waarden en principes om de ontwikkeling van software te begeleiden. “Het Agile Manifesto beschrijft een set van vier waarden en 12 principes. Gedestilleerd tot de kern, is Agile precies wat je denkt dat het zou kunnen zijn. Het is Agile. De methodologie bevordert flexibiliteit, communicatie, samenwerking en eenvoud.

Lean wordt minder begrepen en mist een duidelijke definitie die wordt ondersteund door een professionele consensus.De term “Lean” is oorspronkelijk bedacht om een productie-organisatiemodel te beschrijven dat is gebaseerd op het Toyota Production System, maar wordt algemeen beschouwd als een subraamwerk binnen de Agile-paraplu van softwareontwikkeling.

Heden ten dage is er veel verwarring over wat Lean is, wat Agile is, of ze een en dezelfde zijn, en welke moet worden gebruikt.

De geboorte van nieuwe softwareontwikkelingsmethoden

Zowel Lean als Agile zijn ontwikkeld als reactie op de tekortkomingen van bestaande plangestuurde methoden zoals Waterval. Gebruikt sinds de jaren ’70, ontwikkelaars en software engineering managers begonnen de inefficiënties van Waterfall op te merken tegen de jaren ’90. Met meer dynamische markten en technisch onderlegde consumenten, was Waterfall niet in staat om snel genoeg te reageren op de eisen van de markt, veranderende technologie, of om bug-vrije software te leveren op een consistente basis.

In de zoektocht naar een beter model, probeerden de makers van Lean en Agile methodologieën te ontwikkelen met een meer klantgerichte aanpak. De nieuwe methodologieën omarmden het aanpassingsvermogen als een concurrentievoordeel, gaven de voorkeur aan vroegtijdig en voortdurend testen, en introduceerden een menselijk element in projectmanagement en -uitvoering.

Lean vs. Agile principes

Lean Software Development (LSD) werd voor het eerst voorgesteld door dr. Robert Charette als een manier om veranderingsbestendige organisaties op te bouwen die steeds afhankelijker werden van software.

Daarna kwam “The Agile Manifesto” waarin de 12 principes van Agile Software Development werden vastgelegd.

Het andere gezaghebbende werk over softwareontwikkelingsmethodologieën komt op naam van Mary en Tom Poppendieck, die Lean Software Development: An Agile Toolkit.

Hier vindt u een vergelijking tussen de waarden en principes van beide:

Als u de 12 principes van LSD van Dr. Charette vergelijkt met de 12 principes van Agile, kunt u zien dat ze opvallend veel op elkaar lijken. De zeven Lean-principes die door de Poppendiecks zijn voorgesteld, zijn minder doelgericht, maar overlappen toch met “The Agile Manifesto” en Charette’s Lean Software Development.

Hier zijn nog meer elementen die ze gemeen hebben:

• De waarde van snel inspelen op de behoeften van de klant
• Vroeg testen
• Een iteratieve benadering van ontwikkeling
• MVP (Minimum Viable Product) stijl van ontwikkeling boven feature heavy
• Samenwerking zowel binnen het bedrijf als met externe belanghebbenden

Tijdlijn

We hebben de waterscheiding gebeurtenissen en publicaties die geboorte gaf aan deze terminologieën onderzocht om te zien hoe ze populair werden. Bekijk hieronder onze tijdlijn met een gedetailleerde beschrijving van de progressie, en voeg ze toe aan uw leeslijst als u dat wilt!

Oorsprong van Lean en Agile

Zoals u kunt zien in de tijdlijn, werd de term Lean voor het eerst gebruikt door Womack et. al. in 1990 om het Toyota-productiesysteem te beschrijven in hun boek The Machine That Changed The World. Dr. Robert Charette paste later de Lean ideeën beschreven in eerdere publicaties aan om zijn “Lean Software Development” te creëren.

De term Agile werd pas op grote schaal gebruikt na de publicatie van “The Agile Manifesto” in 2001. De termen Agile en Lean zijn beide bedacht door westerse technologieprofessionals of academici die refereerden aan het Toyota Productiesysteem (waarover later meer).

We krijgen misschien wat kritiek te verduren omdat we dit zeggen, maar met dit in ons achterhoofd zijn de termen Lean en Agile eigenlijk niet zo belangrijk. Het hebben van twee termen die voortkomen uit dezelfde principes draagt eigenlijk bij aan verwarring over het onderwerp. Dat gezegd hebbende, dit is de terminologie die de industrie heeft aangenomen, dus we zullen ze blijven gebruiken.

De tijdlijn is ook een bron van verwarring. Dr. Robert Charette introduceerde zijn ideeën over Lean Software Development in het begin en het midden van de jaren negentig. Het tactische doel en de 12 principes van zijn Lean Development-aanpak werden in 1998 beschreven in een artikel met de titel “Lean Development”, bijna drie jaar vóór het “The Agile Manifesto”. Als bewijs van de overlap tussen Lean en Agile, werd dit artikel geschreven door Jim Highsmith, die later een van de grondleggers van de Agile beweging werd. Highsmith’s artikel werd echter niet op grote schaal verspreid, en het duurde tot 2003 voordat Charette zelf een meer diepgaande uitleg schreef achter zijn lean development aanpak in het onderzoeksrapport, “Challenging the Fundamental Notions of Software Development.”

In een e-mail uitwisseling met Dr. Charette, wees hij er al snel op dat zijn opvatting van Lean Development bedoeld was voor het organisatorische niveau binnen de softwaresector:

Het mijne kwam voort uit een zowel strategische als operationele behoefte om de zakelijke/missie-waarde van IT voor de organisatie te verbeteren, en ik benaderde dit vanuit een perspectief van risicobeheer.
-Dr. Robert N. Charette

Dit verschilt enigszins van Agile, dat eerst strikt werd voorgesteld als een “betere manier om software te ontwikkelen”, maar nu wordt toegepast op diverse projecten en managementmethoden.

2003 was ook het jaar waarin de Poppendiecks Lean Software Development: An Agile Toolkit. In dit boek werden zeven principes van Lean Development beschreven, die direct corresponderen met de zeven vormen van verspilling in Lean Manufacturing.

Het boek van de Poppendiecks versterkte tegelijkertijd Lean als een software-ontwikkelmethodologie en vervaagde het onderscheid tussen Lean en Agile, door Lean voor te stellen als een aanvullende methode binnen Agile. In feite werd het boek op het moment van publicatie verkocht als de laatste publicatie binnen The Agile Software Development Series.

Heden ten dage worden de vele werken van de Poppendiecks over het onderwerp beschouwd als essentiële lectuur voor Lean, en “aspirant-lean” software ontwikkeling beoefenaars.

Divergentie in toepassing

Volgens Dr. Charette, is een van de primaire verschillen tussen Lean en Agile dat Agile bottom-up is, terwijl Lean top-down is. Dit komt duidelijk naar voren in de end-to-end (E2E) structuur van Lean en het principe van See the Whole voorgesteld door de Poppendiecks. Hieronder leggen we deze principes uit in de praktijk van value stream mapping.

Value Stream Mapping

Om het principe van See the Whole te realiseren, detailleren de Poppendiecks een methode van value stream mapping om de waardetoevoegende activiteiten versus de niet-waardetoevoegende activiteiten te onthullen gedurende het gehele end-to-end ontwikkelingsproces.

Value stream mapping analyseert de ontwikkelingscyclus vanaf het moment dat een vereiste wordt ontvangen tot het moment dat deze wordt opgeleverd aan de klant. Het doel is om de verspilling van zittende voorraad en wachten (vertragingen in de productie) te identificeren, en nieuwe praktijken te verkennen om Work-in-Progress (WIP) en doorlooptijd te verminderen.

Volgens de Poppendieck’s is het in kaart brengen van uw waardestroom een eenvoudige oefening die slechts een potlood en een stuk papier vereist. Het proces is als volgt:

1. Breng uw huidige waardestroom in kaart (beginnend met een vereiste en een tijdlijn van acties op de weg naar oplevering)
2. Analyseer de grootste oorzaak van verspilling (Wat houdt het onderhanden werk op?
3. Ontwikkel een plan om deze verspilling te halveren
4. Stel een toekomstige waardestroom kaart op

Het Agile paradigma zoals beschreven in “The Agile Manifesto” geeft de voorkeur aan korte iteratie cycli en frequente opleveringen boven een holistisch end-to-end beeld. De E2E focus is daarom uniek voor Lean. In feite is het vanwege de E2E constructie dat Lean (in plaats van Agile) vaker wordt toegepast als een organisatorische structuur en management stijl.

De end-to-end view vereist dat de hele organisatie deelneemt om verspilling te elimineren. Dit komt overeen met het door Dr. Charette genoemde doel van zijn oorspronkelijke Lean Development-concept:

Lean Development is een filosofie, een manier van kijken en denken over IT en de relatie ervan met een organisatie, net zo goed als het een ontwikkelingsaanpak is.

Lean Kanban Vs. Agile Kanban

Zowel Lean als Agile hebben het TPS Kanban-systeem overgenomen, met kleine variaties. Toyota’s Kanban-systeem is ontworpen om Work-in-Progress te beperken.

In tegenstelling tot de traditionele “push manufacturing”, waarbij inventaris naar de volgende stap in het proces wordt geduwd, trekt Kanban alleen nieuw materiaal in de productie zodra het huidige stuk is verwerkt en onderdelen moeten worden aangevuld.

Kanban-kaarten worden herbevoorradingsorders en worden teruggestuurd naar de vorige stap in de productie. Het resultaat is dat het onderhanden werk wordt geminimaliseerd en de ongebruikte voorraad wordt verminderd.

In softwareontwikkeling wordt in plaats van Kanban-kaarten van de ene productiestap terug naar de vorige te sturen, een Kanban-bord gebruikt. Sticky notes worden gebruikt, meestal om requirements in progress weer te geven.

Volgens het hoofdstuk van Kai Petersen in Modern Software Engineering Concepts and Practices: Advanced Approaches, gebruiken zowel Agile als Lean een geprioriteerde lijst met vereisten om taken uit te halen.

In tegenstelling tot Agile, dat iteratiecycli met een vaste duur gebruikt om de ontwikkeltijd te beperken en het Kanban-bord beheert, beperkt Lean het aantal taken dat op een bepaald moment is toegestaan. Hierdoor kan Lean zijn primaire doel van het beperken van WIP vervullen, terwijl het nauwkeuriger de doorlooptijd meet en verspilling in de productie identificeert. Zodra een taak is voltooid, kan een nieuwe taak van de geprioriteerde lijst worden gehaald. Terwijl Lean het concept van continue stroom gebruikt, begint Agile elke nieuwe iteratie met een nieuw bord.

Sommige teams erkennen de voordelen van beide benaderingen, en beginnen een hybride methode te gebruiken die bekend staat als scrumban.

Dit zijn slechts twee van de subtiele verschillen in aanpak die Lean en Agile hanteren om gemeenschappelijke doelen te bereiken. Een ander artikel, gepubliceerd op Codementor, gaat dieper in op het gebruik en de toepassingen van Lean en Agile.

In de praktijk is het onbelangrijk of uw team kiest voor een zogenaamde “Agile” aanpak of een “Lean” aanpak. Wat belangrijk is, is het vinden van de juiste werkwijzen om uw workflows te optimaliseren en consistent waarde te leveren aan uw klanten, wat beide methodologieën zien als het uiteindelijke doel.

The TPS Connection

Dus wat heeft dit alles te maken met het Toyota Productie Systeem? Vrijwel alles. De bedenkers van zowel Agile als Lean zijn sterk beïnvloed door TPS, zoals Womack et. al. beschrijven in The Machine That Changed the World. To better understand the inspiration for Lean and Agile methodologies, we will take a look the manufacturing system developed in Japan between the 1950s-70s, specifically:

• Just-in-Time Manufacturing
• Jidoka (intelligent automation)
• Eight Forms of Waste
• TPS Values

Warning:

The rest of this article contains jargon that you can use to sound scholarly after reading.

Just-in-Time Manufacturing

Following WWII, Toyota was on the brink of collapse with a damaged supply chain and depression-level demand for their automobiles. Het bedrijf kon niet hopen een Detroit-model van massaproductie te volgen en te overleven.

Onder deze omstandigheden stelden Taiichi Ohno en Kiichiro Toyoda zich ten doel winstgevend te blijven door verspilling in de productie te elimineren, de doorlooptijd te verkorten en alleen te produceren wat klanten nodig hadden, ook bekend als Just-in-Time (JIT) productie.

Om verspilling te elimineren, besloot Ohno alleen te maken wat nodig was, wanneer het nodig was, en alleen in de hoeveelheid waarin het nodig was.

Het iteratieve proces van Lean en Agile, dat zich richt op het minimaliseren van de ontwikkeling van functies en het maximaliseren van de levering van updates, weerspiegelt direct Toyota’s Just-in-Time-productie.

Jidoka

Jidoka (自働化) kan worden vertaald als automatisering met een menselijk tintje, soms aangeduid als “intelligente automatisering”. Jidoka speelt een belangrijke rol bij het elimineren van verspilling in de productie door machines onafhankelijker te maken, waardoor mensen vrij komen om een actievere rol in de productie te spelen en menselijke creativiteit wordt ontsloten.

Jidoka vertrouwt op intelligente machines die automatisch stoppen wanneer er een onregelmatigheid is.

Jidoka geeft ook iedere werknemer de bevoegdheid om de productielijn te stoppen wanneer een probleem wordt gedetecteerd. Het principe omvat een proces van vier stappen om de verspilling van defecte producten te elimineren:

1. Ontdek de afwijking
2. Stop de productie
3. Verhelp of corrigeer de onmiddellijke toestand
4. Onderzoek de hoofdoorzaak en verhelp de situatie

Jidoka is terug te vinden in de Lean en Agile focus op vroegtijdig en frequent testen om bugs uit te roeien, en de nadruk op overleg met de klant om de pijnpunten van de gebruiker te lokaliseren.

Verspillingen van TPS in een softwareontwikkelingscontext

Om JIT-productie te bereiken, schetste Taiichi Ohno zeven vormen van verspilling die moeten worden geëlimineerd. Nummer acht werd later toegevoegd. Als je de waarden, doelen en principes van Agile en Lean nader bekijkt, kun je zien dat ze zijn ontworpen om te waken tegen de acht verspillingen van TPS. In hun boek Lean Software Development: An Agile Toolkit, presenteerden de Poppendiecks TPS verspillingen in een software ontwikkelingscontext.

1. De verspilling van overproductie. De verspilling van overproductie is een van de grootste redenen waarom de Watervalmethode is verlaten. Overproductie wordt gezien als extra codering voor features waar niet om is gevraagd en die de klant misschien niet wil.

Dit komt tot uiting in de volgende principes:

Agile ⟶ eenvoud
Charette’s Lean⟶ minimalisme
Poppendiecks’ Lean ⟶ elimineer verspillingen

2. De verspilling van wachten. In JIT productie is wachten op een inactieve machine of arbeider verspilling. In software-ontwikkeling is wachten op een team met overcapaciteit verspilling. Als er vertragingen zijn in de productie waardoor een team stand-by moet staan, of waardoor de klant moet wachten op levering, is er sprake van verspilling.

Agile ⟶ frequente cycli
Charette’s Lean ⟶ ⅓ van de tijd (doel van LSD), 80% oplossing vandaag
Poppendieck’s Lean⟶ zo snel mogelijk leveren

3. De verspilling van transport. In software ontwikkeling wordt transport vertaald als “task switching”. Te veel overdrachten of medewerkers die aan meerdere teams worden toegewezen met een vraag naar overmatige multitasking is inefficiënt en een verspilling.

Passende principes:

Agile ⟶ samenwerking tussen belanghebbenden, zelforganiserende teams, cultuur van
trouwen, ondersteuning en motivatie
Charette’s Lean ⟶ teaminspanning
Poppendiecks’ Lean ⟶ empower het team

4. De Verspilling van Overprocessing. Dit zijn simpelweg extra processen die niet echt nodig zijn om waarde te leveren aan de klant. Het primaire voorbeeld is documentatie. Overdadige documentatie voor inflexibele processen zal niet waardevol zijn, evenmin als te gedetailleerde gebruikershandleidingen die in een pagina of twee kunnen worden samengevat. Documentatie is tijdrovend, maar biedt de eindgebruiker weinig waarde.

Gelijke principes:

Agile ⟶ eenvoud, werkende software als maatstaf
Charette’s Lean ⟶ minimalisme
Poppendiecks’ Lean ⟶ elimineer verspilling

5. De verspilling van inventaris. Inventaris verspilling is Work-in-Progress waarvoor een investering is gedaan, maar geen waarde heeft totdat het is voltooid. Met andere woorden, incomplete software biedt geen waarde aan de gebruiker. Lean en Agile hechten waarde aan snelle en frequente leveringen, met de nadruk op frequente iteratieve cycli en oplevering van werkende software.

Gelijke principes:

Agile ⟶ klanttevredenheid (door vroege en frequente klant
levering)
Charette’s Lean ⟶ 80% oplossing vandaag
Poppendieck’s Lean ⟶ zo snel mogelijk leveren

6. De Verspilling van Beweging. Verspilling van beweging is overtollige inspanning die nodig is om informatie te krijgen of vragen te beantwoorden. Dit komt vaak voor als teams niet op dezelfde locatie zitten, als taken worden voltooid en resultaten niet onmiddellijk beschikbaar worden gesteld aan alle relevante partijen, of als belanghebbenden niet direct beschikbaar zijn voor overleg.

Passende principes:

Agile ⟶ samenwerking met belanghebbenden, face-to-face communicatie
Charette’s Lean ⟶ klantparticipatie, teaminspanning
Poppendiecks’ Lean ⟶ elimineer verspilling

7. De verspilling van Defecten. Net als in de productie, is het produceren van defecte of buggy software een verspilde investering door het bedrijf. Hoe sneller een defect wordt ontdekt, hoe groter de kans dat verspilling wordt tegengegaan. Veel Agile en Lean principes zijn erop gericht de verspilling van defecten een halt toe te roepen. Om defecten te verminderen, hechten alle drie de methodologieën veel waarde aan vroegtijdig en frequent testen.

Gelijke principes:

Agile ⟶ technische uitmuntendheid, werkende software als maatstaf
Charette’s Lean ⟶ klanttevredenheid
Poppendiecks’ Lean⟶ amplify learning

8. De verspilling van ongebruikte creativiteit van medewerkers. In software ontwikkeling is ongebruikte creativiteit het gevolg van een starre roadmap en gebrek aan menselijke samenwerking. Net als Jidoka (自働化), proberen Agile en Lean de menselijke samenwerking en innovatie te maximaliseren om de beste resultaten uit de technologie te halen.

Passende principes:

Agile ⟶ samenwerking tussen stakeholders, teamreflectie
Charette’s Lean ⟶ “ongeschreven” 13e principe van tevredenheid door
werk
Poppendiecks’ Lean ⟶ versterken leren

TPS-waarden in softwareontwikkelingsmethodologie

Veel van de kernwaarden die TPS vormen, komen ook terug in Agile en Lean softwareontwikkelingsmethodologieën.

Kaizen (改善) vertaalt zich als continue verbetering. Met flexibele, iteratieve, klantgerichte modellen, is continue verbetering misschien wel de belangrijkste waarde van Agile en Lean software-ontwikkelingsmethoden.

Hansei (反省) betekent zelfreflectie. Als een middel om de efficiëntie te verbeteren, neemt het Agile Manifesto direct zelfreflectie van het team als zijn 12e principe. Bij de introductie van zijn Lean Development model, daagt Dr. Charette de lezers uit om na te denken over alle huidige veronderstellingen die de processen dicteren die ze gebruiken als een eerste stap naar het vinden van betere. Het principe “versterk het leren” van de Poppendiecks kan ook als Hansei worden beschouwd.

Respect voor mensen (尊重) staat centraal in alle drie paradigma’s. De eerste waarde van “The Agile Manifesto” is het “waarderen van individuen en interacties boven processen en gereedschappen.”

Respect voor mensen komt ook naar voren in Dr. Charette’s bewering van het belang voor individuen om voldoening te ervaren door werk, en het Lean-principe van de Poppendiecks van empowerment van teams. Deze waarde erkent dat wanneer individuen betrokken zijn bij de besluitvorming en het verbeteren van hun werkomgeving, zij meer innovatieve en efficiënte werknemers zijn.

Seiri (整理) is het principe dat verspilling tegengaat. Seiri dicteert dat wat overbodig is, moet worden verwijderd. Dit omvat alle van de oorspronkelijke zeven verspillingen van TPS, waarvoor we de parallelle verspillingen in de software-ontwikkelingsomgeving al hebben geïdentificeerd.

Gengchi Genbutsu (現地現物) vertaalt zich letterlijk naar “feitelijke plaats, feitelijk ding”. In de praktijk betekent dit “inspecteren om te begrijpen”. Wanneer er een probleem is in het productieproces, moet de manager naar de bron gaan om het probleem te begrijpen en te bepalen hoe het kan worden opgelost.

In softwareontwikkeling komt deze waarde tot uiting in de nadruk op korte iteratiecycli, vroegtijdig testen en samenwerking met de klant, zodat software-engineers werkende software kunnen bouwen die gebruikers ook echt willen.

Conclusie

Zoals we in de openingsalinea’s van dit bericht al aangaven, wordt Lean-methodologie minder goed begrepen en vaak beschouwd als een Agile-praktijk. Lean is misschien minder goed gedefinieerd, simpelweg vanwege de bredere toepassingen.

Lean heeft een directere relatie met het Toyota Productiesysteem en werd eerst voorgesteld als een organisatorische set methoden en praktijken voor bedrijfsmanagement, en pas later toegepast op softwareontwikkeling. Agile, daarentegen, is specifiek ontwikkeld voor software ontwikkeling door toegewijde professionals in het veld.

Na het in detail beschrijven van de gedeelde achtergrond en algemene principes van deze twee methodologieën, kun je zien dat deze twee paradigma’s meer gemeen hebben dan dat ze verschillen.

Een van de belangrijkste auteurs van “The Agile Manifesto”, Martin Fowler, die ook nauw met de Poppendiecks heeft samengewerkt, heeft erop gewezen dat Lean en Agile elkaar niet uitsluiten:

Lean en Agile zijn in de softwarewereld diep met elkaar verweven. Je kunt niet echt spreken van alternatieven….you don’t do Agile or Lean, you do Agile and Lean.

1. De 12 principes van Charette’s Lean Software Development werden eigenlijk voor het eerst beschreven in Jim Highsmith’s artikel “Lean Development” in 1998. Dit werd later uitgewerkt in Dr. Charette’s eigen artikel “Challenging the Fundamental Notions of Software Development” ︎