Lean softwareontwikkeling, of de originele Engelse term Lean software development (LSD), is een combinatie van de best practices van lean manufacturing, lean IT en de agile-softwareontwikkeling.
Oorsprong De naam lean software development komt van een boek met dezelfde naam geschreven in 2003 door Mary Poppendieck en Tom Poppendieck.Mary Poppendieck, Tom Poppendieck (2003), "Lean Software Development: An Agile Toolkit", Addison-Wesley Professional, het boek beschrijft de traditionele lean principes in een aangepaste vorm, evenals de 22 gereedschappen die hierbij volgens hen gebruikt kunnen worden. Zij vergelijken deze gereedschappen met de best practises van agile. De betrokkenheid van de Poppendiecks in de agile gemeenschap, versterkt door hun aanwezigheid en presentaties op allerlei conferenties, inclusief de video's daarvanPresentatie van Mary Poppendieck over: "The five habits of successful lean development" verspreid via Youtube https://www.youtube.com/watch?v=hl4NSdYQacA. Gearchiveerd op 1 april 2023., heeft bijgedragen aan de verspreiding van hun gedachtegoed. Op het ogenblik is er mede daardoor een pro-lean subcultuur aan het ontstaan binnen de agile gemeenschap.
Lean principes Lean softwareontwikkeling kan worden samengevat in zeven principes, die erg lijken op de principes van de leanproductie: Voorkom verspilling Versterk het leereffect Beslis zo laat mogelijk Lever zo snel mogelijk Geef het team verantwoordelijkheid Kwaliteit Zie het geheel
Voorkom verspilling Alles wat geen waarde toevoegt voor de klant wordt gezien als verspilling (muda). Onder andere: Onduidelijke requirements Bureaucratie Langzame interne communicatie Vertragingen in het softwareontwikkelproces Onnodige code en functionaliteit Te weinig tests
Om verspilling te kunnen verwijderen moet men deze eerst herkennen. Een value stream mapping techniek wordt vaak gebruikt om verspilling op te sporen en vervolgens te verwijderen. Dit moet een aantal keren gebeuren totdat zelfs processen die aanvankelijk essentieel leken, verwijderd kunnen worden. Bijvoorbeeld; als sommige activiteiten overgeslagen kunnen worden, of als het resultaat ook op een andere manier zonder deze activiteit behaald kan worden, dan kan dit proces verwijderd worden. Programmeerwerk dat gedeeltelijk gedaan is en niet afgemaakt, is verspilling en kan verwijderd worden. Het maken en onderhouden van extra ongevraagde features en functionaliteit die weinig gebruikt wordt, is verspilling. Het wachten op andere activiteiten, teams, mensen of processen, is verspilling. Fouten en slechte kwaliteit zijn verspilling. Management overhead die geen echte waarde toevoegt, is verspilling.
Versterk het leereffect Het ontwikkelen van software is een continue leerproces wat nog toeneemt door het samenwerken in teams. De beste aanpak voor een verbetering van de softwareontwikkeling is het versterken van het leereffect. Het opstapelen van fouten moet voorkomen worden door zo vroeg mogelijk te testen, bij voorkeur nog voor er geprogrammeerd wordt. In plaats van meer documentatie te maken of een gedetailleerde planning kunnen beter verschillende ideeën uitgeprobeerd worden. Door deze aan de gebruiker te tonen wordt sneller duidelijk wat hun wensen zijn.
Het leerproces wordt versneld door het gebruik van korte verbetercycli, gekoppeld aan refactoring en integratietesten. Door korte feedback sessies bij elke korte verbetercyclus/iteratie wordt het iedereen snel duidelijk wat de mogelijkheden en wensen zijn, wat ten goede komt aan het leereffect en de toekomstige verbeteringen. Gedurende deze korte sessies leren zowel de vertegenwoordigers van de klant / gebruiker en het ontwikkelteam meer van het probleemgebied zodat zij gericht op zoek kunnen naar mogelijke oplossingen. Op deze manier begrijpen de klanten beter wat ze willen, gebaseerd op wat aan hen opgeleverd wordt en de ontwikkelaars leren beter hoe ze deze wensen kunnen realiseren.
Een andere aanpak van de communicatie en het leerproces is wat men noemt "set-based development", of ook de Theory of constraints. In deze aanpak worden de randvoorwaarden van de toekomstige oplossing aangegeven en krijgt het ontwikkelteam de mogelijkheid om daarbij oplossingen te zoeken, zonder dat die direct al door de klant verder beperkt wordt. Dit bevordert de ontwikkeling van de oplossing door een dialoog met de klant in plaats van door een dictaat van de klant. Het bevordert de inschakeling van het creatieve oplossingsvermogen van de ontwikkelaars en verhoogt daarmee hun motivatie.
Beslis zo laat mogelijk Het ontwikkelen van software heeft altijd een element van onzekerheid. Betere resultaten kunnen bereikt worden door gebruik te maken van een meersporenbeleid, waarbij tegelijkertijd gewerkt wordt aan meerdere mogelijke oplossingsrichtingen, waardoor de uiteindelijke de beslissingen zo lang mogelijk uitgesteld worden totdat zij gemaakt kunnen worden gebaseerd op feiten in plaats van op onzekere aannames en voorspellingen. Hoe ingewikkelder het systeem is, hoe flexibeler het ontwikkelproces moet zijn, zodat het mogelijk is om onomkeerbare dure beslissingen zo laat mogelijk te nemen. De stapsgewijze iteratieve aanpak gaat uit van dit principe; de mogelijkheid om op wijzigingen te reageren en vergissingen te corrigeren, vergissingen die erg duur kunnen worden wanneer zij pas laat in het proces onderkend worden.
In de flexibele agile aanpak krijgt de klant al in een vroeg stadium tussenproducten en opties te zien, waardoor zij beter zicht krijgen op de mogelijkheden en onmogelijkheden, waarbij definitieve beslissingen worden uitgesteld totdat de klanten beter bewust zijn van wat zij willen. Dit maakt het ook mogelijk om nog vrij laat te kunnen reageren op veranderingen in de wensen, ter voorkoming van dure vroege technische beslissingen. Dit betekent niet dat men helemaal niet moet plannen, integendeel, planning moeten zich concentreren op de verschillende mogelijkheden en moeten zich aanpassen aan de huidige situatie. Plannen moeten ook inzicht geven door de verschillende mogelijkheden voor snelle actie. Het evalueren van verschillende mogelijkheden is een effectieve aanpak zodra men begrijpt dat het openhouden van de verschillende mogelijkheden ook geld kost, maar wel flexibiliteit biedt om laat te kunnen beslissen.
Lever zo snel mogelijk In het tijdperk van de snelle technische ontwikkeling is het niet de grootste die overleeft, maar de snelste. Hoe sneller het eindproduct wordt opgeleverd zonder grote fouten, hoe sneller er feedback komt en hoe sneller dat meegenomen kan worden in de volgende verbeterslag. Hoe korter de iteraties, hoe sneller er gecommuniceerd wordt en hoe sneller er geleerd wordt door het team. Door deze snelheid kunnen beslissingen uitgesteld worden. Snelheid zorgt voor de realisatie van de huidige wensen van de klant en niet wat zij gisteren nodig hadden. Dit geeft hun de mogelijkheid om de besluitvorming uit te stellen totdat zij beter weten wat ze willen. Klanten kunnen het meestal wel waarderen wanneer er snel (tussen)resultaten worden opgeleverd.
De Just in time productie ideologie kan ook worden toegepast bij softwareontwikkeling. Dit kan worden bereikt door het team zichzelf te laten organiseren en de taken onderling te verdelen. In het begin van het proces en de iteratie komt de klant met de benodigde input. Dit kan worden gedaan in de vorm van kleine kaartjes met userstories – vervolgens schatten de ontwikkelaars hoeveel tijd nodig is om dit uit te voeren. Hierdoor verandert de organisatie van het werk in een self-pulling system – elke morgen gedurende de "stand-up meeting", vertelt elk lid van het team wat hij gisteren gedaan heeft, wat hij vandaag gaat doen en wat morgen. Hierbij wordt commentaar gevraagd van de anderen. Hierdoor wordt duidelijk wat iedereen doet en hoe men samenwerkt, wat voordelig is voor de teamcommunicatie.
Een ander basis idee in het Toyota's ProductontwikkelingssysteemYasuhiro Monden (1998), Toyota Production System, An Integrated Approach to Just-In-Time, Third edition, Norcross, GA: Engineering & Management Press, . dat is overgenomen in het lean gedachtegoed en vervolgens in lean softwareontwikkeling is het "set-based design". Als er bijvoorbeeld een nieuw remsysteem nodig is voor een auto kunnen drie verschillende teams bezig gaan om hiervoor een oplossing te bedenken. Elk team hoort wat de eisen en wensen zijn inclusief de beperkingen en gaat daarmee aan de gang om een mogelijke oplossing te ontwikkelen. Als een bepaalde oplossing onmogelijk lijkt gaat men er niet meer mee verder. Aan het einde van de ontwikkelperiode worden de overblijvende ontwerpen vergeleken en wordt er één gekozen, misschien met een paar aanpassingen gebaseerd op wat men bij de andere ontwerpen geleerd heeft. Een uitstekend voorbeeld van het uitstellen van een beslissing tot het laatst mogelijke moment. Het ontwikkelen van software kan ook gebruikmaken van deze werkwijze om het risico te verminderen dat geschapen wordt door het maken van grote systeemontwerpen voorafgaand aan het bouwproces. Grote ontwerpen die gemaakt worden op een moment dat men daar eigenlijk nog onvoldoende kennis voor heeft.
Geef het team verantwoordelijkheid Er is het traditionele beeld over besluitvorming in organisaties, namelijk dat de managers het personeel precies vertellen hoe ze het werk moeten doen. Dat werkt uitstekend zolang managers ook precies weten wat er moet gebeuren, dat is het geval in goed voorspelbare omgevingen, maar daarvoor zijn vaak al oplossingen / standaardprogrammas ontwikkeld. In een zogenaamde "Work-Out" techniek worden de rollen omgedraaid en wordt managers geleerd om te luisteren naar de ontwikkelaars, zodat zij beter kunnen uitleggen welke acties genomen moeten worden, evenals dat zij suggesties kunnen leveren voor verbeteringen. Binnen de lean aanpak is men een aanhanger van het gezegde: "vind goede mensen en laat hen het werk doen", verder moeten deze mensen aangemoedigd worden, moeten fouten gesignaleerd worden en moeten hindernissen weggenomen worden, maar er moet niet precies voorgeschreven worden wat er elke seconde gedaan moet worden, want dat is een verspilling van het creatieve oplossende vermogen van de ontwikkelaar.Presentatie van Mary Poppendieck over: "The Elefant in the room", over hoe men mensen moet motiveren Google https://www.youtube.com/watch?v=MSYlqx1Yvqk. Gearchiveerd op 5 juni 2015.
Een andere vergissing is om mensen te zien als "poppetjes". Mensen zijn misschien een "poppetje" vanuit een statistich standpunt, maar in softwareontwikkeling, net als elders, willen mensen niet gezien worden als "poppetje", zo hebben mensen meer nodig dan alleen een lijst van taken en de verzekering dat zij niet gestoord worden bij de uitvoering van hun werk. Mensen hebben vaak zoiets nodig als motivatie en een hoger doel om voor te werken. Een bereikbaar doel, waarbij het team zelf kan aangeven hoe zij dat aanpakken. De ontwikkelaars moeten daarom ook met de klant/gebruikers kunnen praten; de teamleider moet hen faciliteren en ondersteunen in moeilijke situaties en moet voorkomen dat scepticisme het goede groepsproces verstoort.Presentatie van Mary Poppendieck over: "The role of leadership in software development" verspreid via Google https://www.youtube.com/watch?v=ypEMdjslEOI. Gearchiveerd op 18 maart 2023.
Kwaliteit De klant moet een goede algehele indruk hebben van het gehele systeem: hoe het verkocht wordt in advertenties, hoe het afgeleverd wordt, gebruikt, de toegankelijkheid, hoe gebruikersvriendelijk het is, of de prijs goed is en hoe goed ermee problemen opgelost kunnen worden. Dit moet op elkaar aansluiten en dat is de integrale kwaliteit die de klant ervaart.