lean voor software ontwikkelbedrijven - prowareness.nl · lean voor software ontwikkelbedrijven...

Lean voor Software OntwikkelbedrijvenEnkele praktische tips

Auteur Peter KoningEnkele illustraties hebben copyright van Net Objectives

‘‘Door enkele concrete punten uit Lean op te pakken, loopt de

hele organisatie veel efficiënter en effectiever. Hoe u dit kunt doen

leest u in deze whitepaper.’’ Peter Koning, Agile Coach

Prowareness Tel: 0182-756500 Web: www.prowareness.nlHanzeweg 17 Fax: 0182-692021 www.scrum.nl2803 MC Gouda

2

Lean voor Software OntwikkelbedrijvenEnkele praktische tips

1. InleidingWie herkent de volgende situatie? Er is onlangs weer een oplevering van de huidige release gedaan bij een nieuwe klant. Het was een niet al te grote klant, de grootte waar we al heel veel klanten van hebben. En weer gingen er allerlei dingen mis. De afdeling Operations heeft tot in de late uurtjes in het weekend gewerkt om de oplevering toch nog tot een succes te maken. Het kon volgens de software ontwikkeling afdeling onmogelijk bugs zijn. ‘Het zijn vast instellingen’ zeiden ze. Diverse mensen van de software afdeling hebben meegekeken en daarmee hun eigen werk onderbroken. Uiteindelijk is de klant nog net op tijd live gegaan, maar waren er niet veel mensen tevreden over de oplevering. Achteraf bleek dat de klant een deel van de checklist van de oplevering niet volledig had uitgevoerd. Iemand in de organisatie kreeg daarvan de schuld.

Overal waar met mensen gewerkt wordt gaan er dingen mis. Veel mensen hebben zoveel taken die ze tegelijkertijd uitvoeren dat het hun ook niet echt te verwijten valt. Er is gewoon veel te doen. Het is wenselijk dat iedereen zich op één ding kan richten, want dat lijkt efficiënter. Maar hoe realiseer je dat in een kleine dan wel grote organisatie? Is dat voor het hele bedrijf efficiënter?

Door enkele concrete punten uit Lean op te pakken, loopt de hele organisatie veel efficiënter en effectiever. Daarbij worden slagen gemaakt van minstens 25% verbetering, maar wordt ook geregeld een verbetering van 200% gerealiseerd. Hoe u dit kunt doen leest u in deze whitepaper.

Lean intro - Wat is Lean? Prowareness heeft al een whitepaper geschreven over Lean vs Agile. Deze kunt u gratis downloaden op Scrum.nl.

Welke punten uit Lean zijn voor deze whitepaper van belang om te weten?

De belangrijkste kracht van Lean voor software bedrijven is het creëren van Flow. In Lean-termen: Manage delay. Flow is een snelle doorstroom van Business Value. Daarbij is niet alleen het leveren van een hoge Business Value van belang, maar ook het realiseren van een relatief korte tijd tussen het maken van Business Value en het opleveren ervan.

Peter Koning Agile Coach“De afgelopen jaren heb ik bij diverse teams en projecten Scrum geïntroduceerd en verder verbeterd. Ik ben al jaren enthousiast over Scrum en over het vakmanschap dat nodig is om kwalitatief goede software te schrijven. Met deze enthousiasme en ervaring wil ik u helpen om Scrum bij uw organisatie te introduceren en om het vakmanschap van Testers, Programmeurs en Analisten verder te verbeteren. Goed werkende teams zorgen voor een hoge productiviteit en geven energie. Energie aan de teamleden en ook aan de omgeving! Daar hoort een juiste leiderschapsstijl bij. Veel vertrouwen, mandaat en verantwoordelijkheid geven aan de medewerkers is in de praktijk een uitdaging.

Door mijn ervaringen als Manager, met het aansturen van teams aan de ene kant en mijn ervaringen als Programmeur en Tester aan de andere kant, kan ik u goed helpen om uw organisatie te laten groeien. Door elkaars ervaringen, talenten en passie te combineren, kunnen we samen uw organisatie op een hoger niveau krijgen!”

‘‘Door elkaars ervaringen, talenten en passie te combineren, kunnen we samen uw organisatie op een hoger niveau krijgen!’’


3

• Manage size (werk moet opgeknipt worden in brokken van 1-3 dagen);

• Manage timebox (kortcyclische Sprints en breng het werk binnen Sprints in kaart).

In deze whitepaper bekijken we vooral de eerste twee ingrediënten. De overige ingrediënten worden alleen zijdelings genoemd. 2. Optimize the WholeWat is Whole? Wat is het optimaliseren van het systeem?

Het systeem is alles wat betrokken is bij het proces: van idee tot consumptie. Van idee, tot het daadwerkelijk in gebruik nemen en van plan tot realisatie. Daar zijn voor een Software Ontwikkelbedrijf de klant, de Business, Ontwikkeling en Operations bij betrokken. Als we spreken over ‘Optimze the Whole’ dan willen we dit complete systeem optimaliseren. In onderstaande figuur is dit visueel gemaakt.

Praktijk voorbeeld In de inleiding werd het voorbeeld geschetst van een afdeling Operations die samen met Ontwikkeling hard heeft gewerkt om een release bij een nieuwe klant succesvol neer te zetten. Dankzij het principe van ‘Optimize the Whole’ (zie pagina 2), is na enige analyse duidelijk waarom dit fout ging. De business (verkoop) krijgt een bonus zodra de order door de klant getekend is. Niet wanneer het product succesvol in productie is genomen en het complete proces doorlopen is. Daardoor wordt er door de verkoopafdeling niet direct gestuurd op een duidelijk uitleg aan de klant over wat hij kan verwachten rondom de in productie name van de gekochte software. Vaak zijn hiervoor bij de klant ook andere personen nodig. Vanuit de gedachte ‘Optimize the Whole’ is het verkoopproces nu uitgebreid: De klant wordt nu uitgelegd dat hij met deze deal ook een ander software onderdeel gratis krijgt. Hij kan hiermee controleren of de instellingen allemaal goed staan en het begeleidt de klant in het doorlopen van een checklist rondom de implementatie.

Zowel in situatie A als in situatie B wordt na verloop van tijd dezelfde Business Value opgeleverd. Alleen in situatie B is de ‘Flow’ veel groter omdat er een kortere tijd zit tussen het starten van de Business Value en het daadwerkelijk opleveren van de Business Value.

In dit voorbeeld is de totale doorlooptijd hetzelfde, in de praktijk is het vaak dat de doorlooptijd aanzienlijk korter wordt, omdat er minder gewisseld wordt tussen projecten. Als werk ligt te wachten, wordt het groter. Daarover verderop meer.

Door de ‘Flow’ te meten en deze continu te verbeteren, wordt er snel gefocust op het creëren van een pullbeweging en het zoeken naar perfectie voor het hele bedrijf. Deze pullbeweging levert effectiviteit en efficiëntie op. Dat noemen we ‘Optimize the Whole’. Daarnaast is dit vaak een enorme verbetering voor de liquiditeit van een bedrijf. Kosten gaan voor de baten uit. Hoe korter de tijd tussen het maken van de kosten en het innen van de baten, des te beter. Bedrijven gaan immers niet failliet door het maken van verlies, maar door een te lage liquiditeit.

Optimize the Whole. Optimize the System. Creëer maximale ‘Flow’ in het hele systeem, de hele organisatie inclusief klant.

Om dit uit te leggen zullen we eerst uitleggen welke Lean ingrediënten er zijn om continu te verbeteren, daarna wat Systeem-denken is, wat Business Value is en tot slot hoe dit toepasbaar is binnen het hele bedrijf. Lean ingrediënten Er zijn al vele boeken en artikelen over Lean gepubliceerd. Lean is een methode om continu verbeteringen door te voeren. De volgende ingrediënten zijn belangrijk als je het hele bedrijf continu wilt verbeteren vanuit deze Lean gedachte:

• Manage delays (vertragingen elimineren);• Manage load (voorkom opstoppingen door teveel

Work in Progress);• Manage structure/organisation (vorm Scrum Teams);


4

Waarom kost het direct oplossen van een bug nauwelijks tijd en het oplossen van een bug in functionaliteit, die weken of maanden geleden is geschreven, altijd meer? Het is vaak niet het daadwerkelijk schrijven van de code aanpassing, het is veel meer het uitzoeken van de functionaliteit en het reproduceren van de situatie. Als de programmeur tijdens het ontwikkelen de bug tegenkomt, kan hij het in een paar minuten oplossen. Weken of maanden later kost het hem uren werk.

Requirements of Backlog items die in een sessie zijn gemaakt kosten na maanden meer tijd om op te pakken. Vaak wordt een deel opnieuw gemaakt. Als ze de volgende dag opgepakt zouden worden, kost het nauwelijks extra tijd.

Daarom is het vooral voor software ontwikkelbedrijven belangrijk om op de ‘Flow’ te letten en deze te meten. Werkzaamheden die deze ‘Flow’ vertragen zijn automatisch ‘Waste’. Het uitzoeken van ’Waste’-activiteiten (activiteiten die geen waarde toevoegen) zonder het meten van de ‘Flow’ is veel lastiger. Het meten van de ‘Flow’ en deze verbeteren is ‘Optimize the Whole’. Meten van de ‘Flow’ Bij het meten van de ‘Flow’ is het vooral belangrijk om naar het werk zelf te kijken en niet naar de mensen. Het werk moet snel door het systeem. Niet de mensen moeten bezig zijn, maar het werk moet snel verplaatst worden. Dit kun je vergelijken met een autosnelweg. Een autosnelweg wordt niet gebouwd om elke vierkante meter asfalt benut te hebben. Anders zouden files optimaal zijn. Een autosnelweg wordt gebouwd om auto’s snel te laten rijden (verplaatsen).

Je kunt de ‘Flow’ relatief eenvoudig meten door een ‘Value Stream’ te maken. Bestudeer een project en meet hoelang een project in iedere fase heeft gezeten. Kijk daarna per fase voor hoeveel tijd er ook echt aan het project gewerkt is.

Dit project heeft in totaal zo’n 3433 uur geduurd, waarvan 590 uur daadwerkelijk is besteed aan het project. Daarmee is de Process Cycle Efficiency (PCE) = 590/3443 = 14,9%. Dit bedrijf kan theoretisch 700% effectiever worden door de PCE

De afdeling Ontwikkeling heeft dit onlangs gemaakt en daarmee is het probleem structureel opgelost. Het wordt voor de klant extra aanlokkelijk gemaakt om deze check te draaien, omdat het gratis wordt weggegeven.

Hoe zorgen we er dagelijks voor dat mensen die over meerdere afdelingen verspreid zijn daadwerkelijk op elkaar zijn afgestemd? Dat zij daadwerkelijk hetzelfde doel voor ogen hebben? Hoe krijgen we als het ware (virtuele) multidisciplinaire teams door het hele bedrijf heen die bezig zijn om zo effectief mogelijk waarde op te leveren voor onze klanten? Dit kan niet volledig top-down geregistreerd worden. Het klassieke denken dat het management kan voorschrijven hoe medewerkers werken is verleden tijd. Bottom-up registratie kan ook niet, omdat het de hele organisatie betreft en elke afdeling zo zijn eigen belang heeft. Dit overlaten aan 150+ medewerkers is onmogelijk. Maar hoe dan wel? Vast iets met ‘Act locally, think globally’, maar hoe geef je dit in de praktijk vorm? Praktijk voorbeeld Stel je wilt een vliegtuig met een groter gewicht kunnen laten vliegen. Daarvoor heb je waarschijnlijk grotere vleugels nodig en grotere motoren. Grotere motoren vergen vaak weer een hoger landingsgestel, etc. Het is bij een vliegtuig niet mogelijk om aan te geven welk onderdeel verantwoordelijk is voor het vliegen. Zo is het in een bedrijf ook niet mogelijk om aan te geven wie of wat er verantwoordelijk is voor de ‘Flow’ van Business Value. Laat geen onderhanden werk liggen Alleen werkzaamheden waarmee het hele bedrijf, inclusief de klant, beter wordt, zijn effectieve werkzaamheden. Dat is de uitleg van het principe: ‘Optimize the Whole’. Het is alleen lang niet altijd duidelijk of datgene wat je doet waarde oplevert voor de klant. Van veel werkzaamheden is dat ook moeilijk aan te geven. Lean geeft ons een basisingrediënt om dit snel te kunnen bepalen. Daarbij draait het om ‘Flow’. Al het ‘onderhanden werk’ dat ergens in de organisatie ligt te wachten gaat ten koste van de ‘Flow’ en is daarmee in Lean termen ‘Waste’. Voor software ontwikkelbedrijven geldt dit nog veel meer dan voor fabricagebedrijven. Een halffabricaat tijdens het fabricageproces wat ligt te wachten kost investering, maar wordt vaak niet duurder om af te maken. Voor software ontwikkelbedrijven geldt dit wel. Wij werken vaak met hoog opgeleide mensen die intelligent werk doen. Daarvoor moeten zij zich inlezen. Al het werk waar zij enkele weken geleden al mee bezig zijn geweest en waar ze later mee verder gaan, kost meer tijd dan wanneer direct was afgerond. Het kost inleestijd. Details zijn vergeten. ‘Onderhanden werk’ dat blijft liggen wordt ondertussen groter.


5

Door dit bord dagelijks bij te houden (bij grote organisaties heb je hier een tool voor nodig), kun je direct zien waar ‘onderhanden werk’ ligt te wachten. En waar ‘Waste’ ontstaat. In alle kolommen met ‘Ready for …’ (pijlen in de Value Stream) ontstaat ‘Waste’. Door het vaststellen van maximale Work in Progress (WIP) voor alle kolommen ontstaat vrij snel (volgens Lean-termen) Pull. Pas als de stap daarna ruimte heeft voor bepaald werk, wordt in de stap daarvoor werk opgestart. Dit rolt als het ware tot vooraan het systeem. Zo ben je automatisch het hele systeem aan het optimaliseren. Ofwel: ‘Optimize the Whole’.

Rol management Bij bovenstaande verbeteringen is de rol van het management dat zij kaders scheppen. Zij zetten de cultuur neer zodat iedereen gebaat is bij een zo optimaal mogelijk systeem. Vaak moeten hiervoor bestaande bonusconstructies veranderd worden. Daarom is een open cultuur, waarbij medewerkers (zonder career-killing-actions) problemen ter sprake mogen en/of moeten brengen van groot belang. Toyota noemt dit het ‘Stop-the-line-principle’. Als iemand een idee heeft waarvan het hele systeem beter wordt, dan wordt het idee op zich al beloond, besproken en uitgeprobeerd.

Gezamenlijke afspraken en afgesproken processtappen moeten uiteraard strikt opgevolgd worden. Dit versnelt de ‘Flow’ als het goed is. Niemand is vrij om testen in bepaalde situaties over te slaan. Een vuistregel daarbij kan zijn: Don’t ask the team, let them advice management. Ga niet eindeloos polderen, maar neem keuzes. Toets deze keuzes in de praktijk en stel ze indien nodig bij.

Het management moet daarnaast op het volgende letten:

• Root Cause of Issues – bestudeer de bron van de fout. De bron is vaak niet op de afdeling/plek waar het issue ontstaat.

• Gebrek aan ‘echte teams’ – een groep, een team noemen is niet genoeg. Er moet synergie zijn. Het Team moet samen in staat zijn om een betere oplossing neer te zetten dan een individu had kunnen neerzetten. De teamleden moeten vaak fysiek bij elkaar zitten of door middel van digitale communicatie de beleving hebben dat zij fysiek bij elkaar zitten.

Daarnaast moeten ze over het juiste vakmanschap beschikken om daadwerkelijk kwaliteit te leveren over de langere termijn.

Act locally, think globally Door de reeds genoemde acties creëer je de cultuur van ‘Act locally, think globally’. Hierdoor is iedereen op elkaar afgestemd en krijgt iedereen hetzelfde doel voor ogen.

naar ongeveer 100% te brengen. 100% tot 200% effectiever is realistischer. Dit verbeterd de ROI. Het is zeer waarschijnlijk dat ook een veel groter marktaandeel wordt verkregen, omdat de organisatie de concurrentie voor is. Daarnaast wordt er waarschijnlijk minder dan 590 uur aan het project besteed omdat er geen ‘onderhanden werk’ blijft liggen dat ondertussen groter is geworden.

Door het inzichtelijk maken van ‘onderhanden werk’ dat blijft liggen en dit samen met medewerkers weg te nemen, worden ‘Waste’-activiteiten gevonden en verbeteringen stap-voor-stap doorgevoerd.

Werk kan inzichtelijk gemaakt worden door bedrijfsbrede Kanban borden te introduceren. Meer weten over Kanban? Kijk voor meer uitleg op wikipedia.org/wiki/Kanban_board.

Elke stap en iedere pijl van de ‘Value Stream’ wordt een kolom op het Kanban bord. Dat elke pijl ook een kolom wordt is belangrijk, omdat daarmee duidelijk wordt waar het werk zich opstapelt, waar werk wacht en vooral waar de hoeveelheid werk groeit.


6

Minimal Business Increment Zodra een bepaalde Business Value is geïmplementeerd, wil het nog niet altijd genoeg waarde voor de klant hebben om er daadwerkelijk gebruik van te gaan maken. Hiervoor wordt de term Minimal Business Increment (MBI) gebruikt. Genoeg waarde voor de klant om daadwerkelijk te investeren in de nieuwe functionaliteit en deze te gaan gebruiken (in productie). Hiermee wordt echt getoetst of het idee daadwerkelijk waarde oplevert voor de klant. Tijdens een demo of met een prototype kan hier wel een beeld van worden geschetst, maar het is vaak pas in de praktijk echt duidelijk of het waarde oplevert.

Het met elkaar (samen met de klanten) brainstormen over de eerste MBI is vaak een goede manier om een nieuw product of idee te starten. Zie hiervoor ook de whitepaper ‘Vision to Value’ op Prowareness.nl. In plaats van een groot pakket van eisen en contractonderhandeling wordt er concreet nagedacht over hoe beide partijen elkaar het snelst kunnen helpen. Als de MBI goed is bedacht, duurt het bouwen van deze MBI vaak net zolang als het opstarten van een klassiek project. Denk daarbij aan de budgetbepaling, het opstellen van het eisenpakket en de contractonderhandeling. Mocht de MBI geen succes zijn, is het stopzetten van het project ook veel goedkoper. Deze eventueel mislukte MBI levert wel heel veel inzicht op. Meestal wordt er succesvol gekozen voor het bijsturen, waarna er wel een succesvolle MBI opgeleverd wordt.

Embrace Change Het maken van uitgebreide plannen, het schrijven een gedetailleerde mijlpalen planningen en het uitwerken van requirements geeft vaak schijnzekerheid. Er staan wel veel details op papier, maar of de wereld er over meerdere maanden of jaren er echt zo uit ziet is onbekend. Het product dat ontwikkeld wordt is nog niet eerder gebouwd. Klanten geven wel aan wat ze willen, maar ze weten pas echt wat ze willen als ze iets concreets in handen hebben en er zelf mee hebben gewerkt. Juist daarom is het gezamenlijk brainstormen over een MBI en het met elkaar uitspreken van deze onzekerheid een goed begin. Op deze manier wordt het snelst onzekerheid weggenomen en waarde getoetst in de praktijk. Omarm dit proces. Omarm wijzigingen om zo de Business Value te maximaliseren.

Praktijk vergelijking Het verschil tussen uitgebreide plannen schrijven en iteratief te werk te gaan kan vergeleken worden met twee type raketten. Er zijn raketten die zelf niet kunnen bijsturen. Ze worden met een bepaalde hoek, richting en snelheid afgeschoten en afhankelijk van de wind en andere factoren bereiken zij hun doel.

3. Business ValueDe Business Value is meer dan alleen maar de waarde die de klant eraan geeft. Business Value is o.a.:

• Customer Value – de waarde die de klant ervoor wil betalen;

• Technological Insight – weten welke techniek werkt (en welke niet);

• Market Value – het bedrijf kunnen positioneren in de markt;

• Impact Insight – weten hoeveel werk het waarschijnlijk gaat kosten om het te maken;

• Reduced Technical Dept – toekomstige aanpassingen worden goedkoper.

Het bepalen en het meten van de Business Value is een hele belangrijke stap in het introduceren van de ‘Lean Flow’ door de hele organisatie. Het is niet altijd gemakkelijk. Afhankelijk van het gedetailleerde niveau waarin je de ’Flow’ wilt meten moet je ook gedetailleerder de Business Value bepalen.

Praktijk voorbeeld Stel dat in een bedrijf projecten vaak twee tot drie jaar lopen voordat de klant er daadwerkelijk in productie mee aan de slag gaan. Management wil deze tijd terugdringen tot enkele maanden. Het is dan niet nodig om heel gedetailleerd de verwachte complete Business Value te bepalen. Het is genoeg om de Minimal Business Value te bepalen en deze binnen een paar maanden op te leveren. Dit wordt geschetst in onderstaande figuur. Voorheen werd er pas na 2-3 jaar echt Business Value geleverd. Zodra de focus komt op ‘Flow’ van Business Value worden er in het begin diverse punten uitgezocht en getoetst bij klanten. Zodra dat duidelijk is, wordt er in korte tijd veel Business Value geleverd (in korte iteraties) en is de totale Business Value ook groter omdat de functionaliteit beter is afgestemd op de klant. Helemaal als de Cash Flow meegenomen wordt.


7

verschillende teams een beroep op hun kennis gedaan. Het is belangrijk om hier rekening mee te houden.

Geen ready team Een verkeerde aanpak is het oprichten van een ready team waar deze SME’s in zitten. Sommige bedrijven kiezen hiervoor. Zij zetten als het ware het werk klaar voor een volgend Scrum Team.

Om de juiste aanpak uit te leggen, maken we eerst een vergelijking.

Voorbeeld: Stel je hebt een hoge vaas waar je grote stenen in hebt gestopt. Op een gegeven moment kunnen er geen grote stenen meer bij. Je kunt er nog wel kleine stenen in doen. Daarna vaak nog wel zand en tot slot water. Wanneer je was begonnen met het vullen van de vaas met de kleine stenen en het zand, hadden er nooit daarna zoveel grote stenen in gekund. Werk waarbij deze SME’s nodig zijn, zijn als het ware de grote stenen in de vaas. Dit werk moet als eerste gepland en op elkaar afgestemd worden. Dit is de bottleneck van het proces.

SME’s en Scrum Teams Deze Subject Matter Experts (SME’s) haken voor bepaalde onderwerpen aan bij een vast multidisciplinair Scrum Team. Dit Scrum Team kan veel onderwerpen zelfstandig opleveren. Ze zijn samen in staat om veelal de MBI op te leveren. Echter hebben ze soms de hulp nodig van één of meerdere SME’s.

In een bepaalde sprint heeft Scrum Team 2 geen SME’s nodig. Scrum Team 1 heeft er twee nodig. Deze aangehaakte SME’s staan vervolgens in ieder geval bij de dagelijkse stand-up en werken in pairs (bijvoorbeeld pair-programming) samen om direct, op een natuurlijke wijze, voor kennisoverdracht te zorgen. SME1 kan gedurende dezelfde sprint bij twee Scrum Teams helpen. De overall prioriteit van de verschillende onderwerpen die in de verschillende teams lopen bepaald ook de prioriteit voor een SME.

Kanban voor SME’s Het risico voor deze SME’s is dat ze veel work-in-progress hebben. We hebben hierboven al gezien dat ‘onderhanden werk’ dat stil ligt, ondertussen groeit. Daar ontstaat ‘Waste’. Als deze SME’s niet strak hun work-in-progress minimaliseren, worden ze een nog grotere bottleneck. Hoe kunnen ze dit doen?

Er zijn ook raketten die kunnen bijsturen. Zij hebben bijvoorbeeld een hitte sensor of een eigen GPS. Deze raketten worden ook met een bepaalde hoek, richting en snelheid afgeschoten maar kunnen onderweg bijsturen om beter het doel te bereiken.

Doel van MBI Een aanpak die gericht is op de ‘Flow’ van Business Value levert als het goed is het volgende op:

• Maximale Business Value – doordat samen met klanten geëvolueerd wordt naar een steeds grotere ’Business Value’, is het uiteindelijk bereikte niveau hoger;

• Eerder – doordat er eerder live wordt gegaan met een eerste versie, wordt er eerder Business Value gecreëerd, wat o.a. goed is voor de liquiditeit;

• Voorspelbaarder – er wordt in korte iteraties gewerkt, in de praktijk vaak niet groter dan 1 a 2 maanden. Na elke iteratie gaat de klant er echt mee werken. Daardoor wordt het gehele proces voorspelbaarder dan met een mijlpalenplanning van enkele maanden, die pas na meerdere maanden een soort toets met klanten krijgt.

4. Toepassing binnen ScrumNadat we uitgelegd hebben wat ‘Optimize the Whole’ is en wat ‘Business Value’ is, zullen we in dit hoofdstuk kijken naar de toepassing. Daarbij passen we het vooral toe op Scrum Teams. Als u geen Scrum toepast, zijn er wel diverse aspecten uit dit hoofdstuk die u ook zonder Scrum kunt toepassen.

Met enkele (< 5) Scrum Teams is de ‘Flow’ door het systeem uiteraard makkelijker te bepalen dan bij een groter aantal Scrum Teams (>20). Daarbij gaan er bij meerdere Scrum Teams bepaalde zaken meespelen die bij een klein aantal Scrum Teams minder spelen.

Er zijn namelijk mensen die Subject Matter Expert (SME) zijn. Dat kan zijn:

• Omdat ze als enige heel gede tailleerd de bestaande functionaliteit kennen;

• Of ze kunnen als enige ontwikkelen in een bepaalde legacy software taal;

• Of ze kunnen als enige een bepaalde discipline of vaardigheid;

• Of ze weten als enige precies hoe de klant werkt.

Sommige SME’s zitten goed in 1 Scrum Team. Maar het wil niet altijd zo zijn dat er in elke sprint voldoende werk voor hun unieke kennis is. Of er zijn minder SME op een bepaald onderdeel dan het aantal Scrum Teams. Of er wordt vanuit


8

• Business Area – een portfolio bestaat uit één tot enkele Business Area’s. Een Business Area is een groep van applicaties die logischerwijs bij dezelfde business horen;

• Team Area – Eén of meerdere Scrum Teams werken voor één Application Area. Vaak zijn zij expert op een specifieke Application en kunnen ze evt. eenvoudig werk doen in andere Applications.

Per Area zijn er verschillende rollen die belangrijk zijn. Deze lichten we nader toe in de komende hoofdstukken.

Portfolio Area Twee belangrijke rollen binnen de Portfolio Area zijn:

• Value Stream Owner – De Value Stream Owner is verantwoordelijk voor het realiseren van de hoogste Business Value in de optimale (kortst mogelijke) Cycle Time. Dit kan ingevuld worden door de directeur of vaak door iemand die rechtstreeks aan de directeur rapporteert. Deze is verantwoordelijk voor het maximaliseren van de winst en de liquiditeit. Is actief bezig om de ‘Flow’ te meten en om deze flow te verbeteren. Overal waar ‘onderhanden werk’ ligt te wachten, ontstaat ‘Waste’, wordt het werk groter en daalt de ‘Flow’;

• Business Sponsor – De Business Sponsor focust zich op het behalen van de ROI (Return on Investment). Zorgt ervoor dat de Business Value bepaald wordt en bepaalt de prioriteit tussen de verschillende Businesses op Portfolio niveau.

Business Area Belangrijke rollen binnen de Business Area zijn:

• Business Product Owner (BPO) – De Business Product Owner bepaalt de prioriteit binnen de business tussen alle onderwerpen die actueel zijn binnen de business. Daarnaast coördineert hij het werk tussen de verschillende Product Owners. Wordt aangewezen door, en krijgt mandaat van, de Business Sponsor;

• Product Owner (PO) – Ieder Scrum Team heeft één Product Owner. Een PO kan meerdere Scrum Teams bedienen. Hij bepaalt voor het Scrum Team de prioriteit op de backlog en managet de verwachtingen van de verschillende stakeholders. Zodra aan de verwachtingen van de stakeholders wordt voldaan of zelfs overtroffen wordt, wordt de kans dat ze tevreden zijn groter;

• Business Projectleader – De Business Projectleader coördineert de afstemming met de stakeholders. Hij bewaakt het budget en coördineert het werk dat de verschillende klanten moeten doen om de MBI in gebruik te nemen. Daarnaast verzorgt hij zo nodig checklists.

Veel SME’s hebben hun expertise in een bepaald gebied. Zoals reeds beschreven, ze zijn bijv. goed in een bepaalde legacy programmeertaal of ze weten heel veel van een onderwerp. De processtappen die deze SME moet uitvoeren bij de verschillende Scrum Teams zijn vaak hetzelfde. Deze processtappen en de eventuele wachttijd daartussen kan op een persoonlijk Kanban bord bijgehouden worden. De prioriteit op dit Kanban bord is identiek aan de prioriteit van de actuele onderwerpen.

Praktische tips Tot slot nog enkele praktische tips:

• Cross functionele teams – werk zoveel mogelijk met deze teams. Cross functionele teams kunnen zoveel mogelijk het proces overzien van klant tot klant. Ze zijn samen zo goed mogelijk in staat om de ‘Business Value’ te realiseren;

• Automatische integratie tests – draai het liefst elke nacht integratie tests. Dit geeft zo snel als mogelijk feedback aan de teams over de opgeleverde kwaliteit van de afgelopen dag;

• Verbeter Acceptance Test Driven Development (ATDD) – ontwerp testcases gezamenlijk met het team en evt. zelfs met de klant voordat er gebouwd wordt. Dit zorgt ervoor dat de specificaties in het begin nog duidelijker worden en de kans op fouten kleiner wordt;

• Manage ‘Flow’ continu – door de ‘Flow’ door het bedrijf te visualiseren en inzichtelijk te maken kan deze continu verbetert worden;

• Explicit policies - regels zijn noodzakelijk (zie hierboven over Management). Regels zorgen ervoor dat binnen deze regels medewerkers met elkaar goede oplossingen kunnen creëren.

5. Scaling Scrum with Lean [Appendix van maken!]Als er veel Scrum Teams zijn, zijn er expliciete rollen nodig om het werk soepel te laten lopen. In dit hoofdstuk worden enkele rollen benoemd. Hiermee worden belangrijke punten uit eerdere hoofdstukken toegewezen aan concrete rollen. Voordat we deze rollen gaan toelichten, is het belangrijk om enkele termen te introduceren. Voor meer informatie zie Lean-Agile Framework van Net Objective:

• Portfolio Area – een thema, een productlijn. Elk bedrijf heeft één tot enkele portfolio’s;


9

Team Area Belangrijke rollen binnen de Team Area zijn:

• Multidisciplinair Scrum Team – Het Scrum Team is in staat om daadwerkelijk zelfstandig vaak de MBI op te leveren. Geregeld is er werk nodig van één of meerdere SME’s. Verantwoordelijk voor de kwaliteit;

• Scrum Master – De Scrum Master bewaakt het Agile proces. Hij faciliteert de synergie in het Scrum Team en stimuleert continu verbeteringen. Daarnaast zorgt hij dat in iedere iteratie Minimal Viable Increment (MVI) wordt opgeleverd die tijdens de review gedemonstreerd kan worden aan de stakeholders;

• Subject Matter Expert (SME) – DE SME kan gedurende één of meerdere sprints aan één of meerdere Scrum Teams gekoppeld worden zodat ze gezamenlijk de MBI kunnen opleveren.

6. Metrics en KPI’sDe juiste rapportage en managementinformatie is belangrijk om de Lean-Agile transitie succesvol te maken. Het is belangrijk dat het management weet wat ze meet, want waar je op meet wordt vaak vergroot omdat dit indirect door het management wordt beloond.

Praktijk voorbeeld Klassiek wordt bijvoorbeeld het aantal gevonden bugs per regel code gemeten. Stel er zijn twee teams. Team A en Team B. Na een bepaalde periode zijn de onderstaande cijfers bekend.

Echter het volgende is er aan de hand. Als Team A zelf focust op efficiency en niet op effectiviteit zullen ze meer code schrijven dan Team B die focust op effectiviteit (zo min mogelijk doen en alleen datgene doen dat echt waarde toevoegt voor de klant). Een groot deel van de geschreven functionaliteit van Team A wordt niet gebruikt. In Team A worden er 40.000 regels code gebruikt en 60.000 regels worden in de praktijk niet gebruikt.

Waar het management op rapporteert is ook het gedrag dat je krijgt. Vaak wordt er gerapporteerd op bovenstaande zaken. #bugs en #bugs per 1000 regels code. Daarmee zou Team A op alle fronten beter zijn. Echter er is iets anders aan de hand. De juiste rapportage haalt dit wel naar boven. Team B doet het eigenlijk op alle fronten beter. Team A heeft namelijk veel

functionaliteiten geschreven die niet worden gebruikt:

Als je niet krijgt wat je wilt, ben je vaak het verkeerde aan het meten.

KPI’s De allerbelangrijkste KPI’s moeten over de ‘Flow’ en de geleverde Business Value gaan. Het denken in ‘Flow’ en Business Value is een nieuwe mindset. Een enkele cursus of een enkel boek gaat er niet voor zorgen dat de mindset anders wordt, dat er in stresssituaties op de nieuwe manier wordt gedacht. De juiste KPI’s gaat daarbij wel helpen.

Daarnaast moet er creatief nagedacht worden hoe de volgende risico’s gemanaged kunnen worden. Als deze risico’s niet gemanaged worden, zal snel gedacht worden dat Lean-Agile en Scrum niet werkt. Er wordt wel een nieuw proces gebruikt alleen de omgeving wordt niet aangepast. De mindset verandert niet.

Juiste Metrics Waar in ieder geval op gemeten kan worden is:

• Velocity – wat is de velocity van de verschillende teams en Business Areas;

• Happiness – wat is de happiness van de medewerkers en de teams;

• Verstoringen – wat is het percentage van de tijd dat niet besteed kon worden aan gepland werk;

• Flow – wat is de ‘Flow’ binnen de Business Area;• Reliability – wat is de verhouding tussen de toegezegde

hoeveelheid storypoints en de daadwerkelijke velocity;• Verbeteringen – welke verbeteringen zijn doorgevoerd en

in hoeverre hebben ze daadwerkelijk effect gehad.

7. SamenvattingLean levert voor veel bedrijven een goede manier om continu verbeteringen door te voeren. Voor Software Ontwikkelbedrijven geeft één aspect een eenvoudig handvat om te beginnen met continue verbeteringen door te voeren. Voor Software Ontwikkelbedrijven is het verbeteren van de ‘Flow’ van Business Value deze goede start.


10

• Lerend vermogen – Er wordt eerder iets opgeleverd waardoor het bedrijf feedback krijgt over datgene wat ze gedaan heeft waardoor ze hiervan kan leren voor de volgende keer.

Rol Management De Lean aanpak voor Software Ontwikkelbedrijven geeft direct focus aan het management. De belangrijkste taak wordt het verbeteren van de ‘Flow’ van Business Value. Door kaders te scheppen waarbinnen medewerkers vrij mogen opereren, door continu de ‘Flow’ te meten en door verbeteringen te faciliteren, kan een bedrijf snel en continu verbeteringen doorvoeren.

Metrics en beloningssystemen zijn daarbij één van de ingrediënten die het management heeft om de samenwerking binnen het hele bedrijf en de opgeleverde Business Value te vergroten.

Daarbij is het mantra om met kleine stappen deze verbeteringen door te voeren. Maak geen grote plannen vooraf, maar begin met meten, analyseer verbeteringen en voer deze door en meet vervolgens weer. Dit moet het ritme zijn waarmee grote verbeteringen gerealiseerd kunnen worden.

Business Value Business Value is meer dan alleen de waarde die de klant ervoor geeft. Business Value is o.a.:

• Customer Value – de waarde die de klant ervoor wil betalen;

• Technological Insight – weten welke techniek werkt (en welke niet);

• Market Value – het bedrijf kunnen positioneren in de markt;

• Impact Insight – weten hoeveel werk het waarschijnlijk gaat kosten om het te maken;

• Reduced Technical Dept – toekomstige aanpassingen worden goedkoper.

Flow De ‘Flow’ van Business Value kan relatief eenvoudig in kaart worden gebracht door de doorlooptijd (van idee tot in productie bij de klant) t.o.v. de besteden tijd te meten. Als een project elf maanden heeft geduurd van idee tot productie en daarvan is netto gedurende drie maanden echt aan het project gewerkt, dan is de CycleTime 3/11 = 27%. Vaak wordt er binnen een bedrijf tegelijkertijd aan veel projecten gewerkt. Veel medewerkers moeten dan dagelijks taskswitchen tussen de projecten. In Lean termen ontstaat dan ‘Waste’. ‘Onderhanden werk’ dat blijft liggen wordt ondertussen groter, daardoor moet er meer werk gedaan worden dan wanneer de medewerker of het team zijn werk eerst goed kan afronden. Daarom is het verbeteren van de ‘Flow’ een goede start, het is namelijk voor Software Bedrijven vaak de grootste bron van ‘Waste’. Daarnaast moet de ‘Flow’ eerst gemeten worden voordat deze verbetert kan worden en levert het alleen al meten van de ‘Flow’ al direct inzicht in overduidelijke verbeteringen.

Voordelen Het daadwerkelijk snel leveren van Business Value als gehele bedrijf levert o.a. de volgende voordelen op:

• Samenwerking – Business Value geeft focus waardoor het hele bedrijf moet samenwerken. Waarbij afzonderlijke afdelingsbelangen minder belangrijk worden dan het verbeteren van de ‘Flow’ van de Business Value. Medewerkers moeten daardoor over afdelingsgrenzen heen beter kunnen samenwerken;

• Liquiditeit – De liquiditeit van de organisatie wordt vaak flink beter. Er is een kortere tijd tussen het maken van de kosten en het innen van de baten;

• Klanttevredenheid – Er worden vaker kleinere opleveringen aan de klant gedaan waardoor de klant eerder live kan met een deel van de functionaliteit en door vervolgstappen samen af te stemmen wordt het uiteindelijke resultaat beter;

lean voor software ontwikkelbedrijven - prowareness.nl · lean voor software ontwikkelbedrijven...

Documents