Lean Software Ontwikkeling: Introductie, en Verminderen van Verspillingen

Lean SupermanLean Software Ontwikkeling breekt door! IT organisaties passen Lean toe in combinatie met Agile,  gedreven vanuit de business. Wat is Lean, en hoe kun je daarmee sneller software ontwikkelen, met hogere kwaliteit tegen lagere kosten? Een overzicht van de principes van Lean, en de toepassing met een praktijkervaring: Minder verspilling door het gebruik van Agile.

Principes

De grondleggers van Lean Software Development zijn Tom en Mary Poppendieck. In de onderstaande presentatie van de European Lean IT Summit geeft Mary een overzicht van Lean Software Development:

Lean Software Development heeft als doel “to optimize the entire software value stream”. Tom en Mary Poppendieck baseren hun Lean aanpak op de volgende 7 principes:

  1. Verminder Verspillingen (Eliminate Waste)
  2. Integreer Kwaliteit (Build Quality In)
  3. Leer Voortdurend (Learn Constantly)
  4. Lever Snel (Deliver Fast)
  5. Betrek Iedereen (Engage Everyone)
  6. Verbeter Continue (Keep getting Better)
  7. Optimaliseer het Geheel (Optimize the whole)

De principes zijn heel basaal en logisch. Het toepassen van de principes vraagt initieel tijd en geld, maar levert in de praktijk al snel resultaat; dit is een van de sterktes van Lean. In dit artikel ga ik met name in op het toepassen en mijn ervaringen met lean. Ik licht de principes kort toe, en laat vervolgens zien hoe ze gebruikt kunnen worden om sneller software te ontwikkelen, met een hogere kwaliteit tegen lagere kosten.

1: Verminder Verspillingen

Een eerste principe van Lean is “verminder verspillingen”. De definitie van een verspilling is: Alles wat geen klantwaarde toevoegt. Bij Lean Development gaat het om de software ontwikkelactiviteiten: Hoe draagt iedere activiteit bij aan het eindproduct: Software die aan de vraag van de klanten voldoet? Een veel voorkomende verspilling in software ontwikkeling is het maken van het verkeerde product. Bv. niet het product wat klanten wil hebben, onnodige functies, of een product wat niet bruikbaar is voor de klanten. Dit soort verspillingen duiden vaak op problemen met het definiëren en/of beheren van de producteisen (requirements development & management). Maar de oorzaken kunnen wel eens dieper liggen: onvoldoende communicatie tussen de klanten en het ontwikkelteam, onduidelijk wie de klant is, wijzigingen van eisen die niet goed verwerkt zijn, of onvoldoende kennis van het product en de klantbehoefte. Een andere verspilling die ik zie bij software ontwikkeling is ineffectief gebruik van documentatie. Bv het documenteren van het ontwerp, wat vervolgens nergens gebruikt wordt.  Of documentatie die pas achteraf word gemaakt, en tijdens software onderhoud niet bruikbaar blijkt te zijn. Met Lean kijk je naar de gehele keten, het ontwikkelproces, en zorg je ervoor dat de onderdelen goed op elkaar aansluiten. Goede communicatie, waar nodig aangevuld met bruikbare documentatie is essentieel om sneller software te ontwikkelen. Een eenvoudige manier die ik gebruik om het nut van documentatie te testen is met twee vragen. Allereerst, vraag aan diegene die een bepaalde taak doet welke informatie hij/zij daarvoor nodig heeft? En van wie ze die informatie ontvangt, en wat daarvan gedocumenteerd zou moeten zijn. En vraag aan diegene die een document maakt voor wie hij/zij het maakt? En of er afgesproken wat erin moet staan. Door vraag en aanbod op elkaar af te stemmen zorg je voor optimale documentatie, en voorkom je verspilling. Als je Lean gaat toepassen, dan begin je een verandertraject. Belangrijk is om daarbij de kennis en ervaring van je medewerkers te benutten (bv. met oplossingsgericht werken), betrek hen bij de verandering. Denk ook na over het borgen van de veranderingen, maar geef ook voldoende ruimte om nieuwe dingen uit te proberen: veranderen doe je door te leren.

Uit de Praktijk: Minder verspilling met Agile

Building Process Improvement Business  Cases Using Bayesian Belief Networks  and Monte Carlo Simulation Hoe zorg je ervoor dat je het juiste product maakt, en dus geen tijd en geld verspilt aan software die de klant niet kan gebruiken? Uit de praktijk: Bij een opdrachtgever werden fouten gevonden door klanten, die veroorzaakt waren door verkeerde producteisen. Met Lean Six Sigma gecombineerd met Root Cause Analyze heb ik uitgezocht over hoeveel fouten het ging in de organisatie, welke oorzaken een rol speelde, en wat het gekost had (zie onderzoeksrapport Building Process Improvement Business Cases Using Bayesian Belief Networks and Monte Carlo Simulation, een onderzoek wat ik gedaan heb als affiliate van het Software Engineering Institute). Uit de gegevens bleek dat de belangrijkste oorzaken te maken hadden met wijzigingen van de eisen, instabiliteit van de project scope, en met onvoldoende vaardigheden in het juist definiëren van de eisen. Agile werd gezien als een aanpak voor de organisatie om de problemen met het definiëren en beheren van eisen te verminderen. In een pilot project werd mbv een voorspellingsmodel voor het meten en besturen van kwaliteit uitgerekend wat het effect zou zijn op de kwaliteit van de software die aan de klant geleverd gaat worden. De verwachting was dat door het gebruik van Agile requirement practices zoals de planning game met een klantvertegenwoordiger (= product owner), dagelijke stand-ups, intensieve samenwerking met de klanten, en agile retrospectives het aantal fouten bij de klant omlaag zou gaan. Daarmee was er een business case, agile zou een besparing geven op de onderhoudskosten, en een hogere klanttevredenheid. Het aantal fouten bij de klant (gemeten in de eerste 6 maanden dat het product gebruikt werd) was inderdaad lager dan bij vorige producten. Nadere gesprekken met het team bevestigde dat agile inderdaad tot minder fouten had geleid. Het team had een beter begrip van de eisen door de planning game en de stand-ups, na aanleiding van retrospectives waren verschillende verbeteringen doorgevoerd tav beheer van eisen en verwerken van wijzigingen, en de kwaliteit van de eisen was beter dan in voorgaande projecten.

Conclusies

Lean Software Ontwikkeling is gebaseerd op 7 principes. Toepassing van die principes helpt organisaties om sneller software ontwikkelen, met hogere kwaliteit tegen lagere kosten. De praktijk laat zien hoe met Lean een business case opgezet is voor betere producteisen, waarna met Agile het aantal fouten in de software verminderd is. Gevolg: Lagere onderhoudskosten, en hogere klanttevredenheid.

(Deze blog is gepubliceerd op 5 november 2011, en aangepast op 7 januari 2013: aanvullingen en links toegevoegd).

(Visited 355 times, 1 visits today)
Tags: , , , , , , , , , , , ,

About BenLinders

I help organizations with effective software development and management practices: continuous improvement, collaboration and communication, and professional development, to deliver business value to customers. Active member of several networks on Agile, Lean and Quality, and a frequent speaker and writer.
Tagged , , , , , , , , , , , , . Bookmark the permalink.

3 Responses to Lean Software Ontwikkeling: Introductie, en Verminderen van Verspillingen

  1. Hoi Ben,
    Ik vind het verminderen van verspilling wel een spannend punt. Alles weglaten wat geen klantwaarde toevoegt, klinkt nuttig en simpel. Maar is het niet te simpel? 
    Onze research afdeling voegt niet (direct) klantwaarde toe. Als we die weghalen dan hebben we op korte termijn inderdaad minder kosten en meer winst, maar op lange termijn helemaal geen innovatie meer, en dus: einde bedrijf.

    • Ben Linders says:

      Research kan klantwaarde toevoegen, en heeft dan nut in de lean keten. Immers met de research maak je het mogelijk om nieuwe producten te ontwikkelen, waar de klant wat aan heeft.

      Inderdaad is er een vertraging, wat het lastiger gemaakt om te beslissen wat te onderzoeken in research. Een mogelijke aanpak om vroegtijdig inzicht te krijgen in klantbehoeftes is Lean Startup (http://theleanstartup.com/). Het geeft informatie die je helpt om gericht te investeren in research, en sneller aan je klanten te leveren!

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>