Elimineren van „Waste"
Een van de Lean-principes is het elimineren van "Waste" (nl.: verspilling). Dit concept werd eind jaren 1940 door Toyota in de productie-industrie geïntroduceerd. In die tijd was het zeer kostbaar om voertuigen te produceren, en bedrijven moesten hun klanten zeer hoge prijzen vragen. De enige manier voor Toyota om de prijzen van de auto's te verlagen, was het reduceren van de productiekosten.
Wat betekent "Waste" bij Lean?
„Waste" ofwel „verspilling" is in feite het tegenovergestelde van „Value", oftewel „waarde" (een vermogen dat aan de klant wordt geleverd en waardoor deze een direct of indirect voordeel krijgt). Een teammeeting zonder concrete aanleiding is bijvoorbeeld pure tijdverspilling.
Hier zijn de zeven vormen van verspilling die in het Toyota Production System (TPS) door Shigeo Shingo zijn geïdentificeerd:
Voorraden: onderhanden werk (WIP: work in progress)
Overproductie: meer produceren dan de vraag vereist
Verwerking: extra stappen in het proces die niet nodig zijn
Transport: goederen van de ene naar de andere locatie verplaatsen
Wachttijden: onderbrekingen tussen de afzonderlijke verwerkingsstappen
Bewegingen: onnodige bewegingen in het proces
Fouten: fouten in producten die de eigenschappen en functies beïnvloeden
Wat zijn de soorten verspilling in softwareontwikkeling?
Op basis van de zeven vormen van verspilling in de maakindustrie hebben Mary en Tom Poppendiek de zeven vormen van verspilling bij softwareontwikkeling gedefinieerd:
Onafgemaakt werk: In elke Sprint zijn de teamleden verantwoordelijk voor een vastgesteld aantal User Stories. Soms lukt het ze echter niet om alle Stories af te ronden. Dan moeten ze uitzoeken waarom dat niet gelukt is, zodat ze dit type verspilling kunnen verminderen.
Extra features: Helemaal aan het begin heeft de Product Owner een visie gecreëerd en vervolgens een Product Backlog opgesteld met geprioriteerde features die waarde toevoegen aan het product. Het Pareto-principe stelt echter dat het vaak niet nodig is om alle features te ontwikkelen, omdat veel ervan nutteloos zijn.
Bijleren: In elke Sprint verzamel je steeds meer kennis die je kunt gebruiken om niet steeds opnieuw het wiel uit te vinden.
Overdracht: Hierbij wordt het werk doorgegeven aan een andere persoon zodra de eerste persoon ermee klaar is. Hoe kun je dit tegengaan? Het beste is om de afhankelijkheden tussen de User Stories (en features) weg te nemen, of je geeft alle User Stories met afhankelijkheden aan één team om het risico te beperken.
Vertragingen: Dit is alles wat de oplevering of de start van een waardetoevoegende activiteit vertraagt. Hoe kun je dit voorkomen? Je moet de knelpunten wegnemen en elk traag proces herstructureren om beide op elkaar af te stemmen.
Wisselen van taken: Dit gebeurt wanneer de Product Owner zijn prioriteiten wijzigt en de teamleden van de ene User Story naar een andere moeten overstappen zonder de vorige eerst af te kunnen ronden. De belangrijkste reden hiervoor is vaak dat de Product Owner geen duidelijke visie op het product heeft, of dat een concurrent een nieuw product op de markt heeft gebracht en je je eigen product zo snel mogelijk wilt aanpassen en uitbrengen.
Fouten: Dit is een van de grootste problemen in softwareontwikkeling. Na een bepaalde tijd heb je een enorme berg aan technische schuld opgebouwd en vanaf dat moment moet je veel tijd en moeite investeren om deze Sprint voor Sprint langzaam weer af te bouwen.
Tot slot kan ik zeggen dat veel mensen denken dat Lean geen goede aanpak is voor een team dat met Agile werkt. Maar ze hebben het mis. In feite zou elk bedrijf eerst Lean moeten toepassen en dan pas overstappen op Agile!!!
Deze tekst is afkomstig uit de blog van Mario Lucero en is door ons naar het Nederlands vertaald.
Product Backlog Refinement
=> Zo verloopt een Backlog Refinement in Scrum Teams.
Hoe verloopt een Sprint Review in agile teams?
=> Hier lees je hoe een ideale Sprint Review kan verlopen.
