Lean voor Software

Lean voor Software
Ontwikkelbedrijven
Enkele praktische tips
‘‘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
Auteur Peter Koning
Enkele illustraties hebben
copyright van Net Objectives
Lean voor Software
Ontwikkelbedrijven
Enkele praktische tips
1.Inleiding
Wie 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!’’
ProwarenessTel: 0182-756500Web:
www.prowareness.nl
Hanzeweg 17Fax:
0182-692021www.scrum.nl
2803 MC Gouda
2
•
•
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.
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);
2. Optimize the Whole
Wat 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.
ProwarenessTel: 0182-756500Web:
www.prowareness.nl
Hanzeweg 17Fax:
0182-692021www.scrum.nl
2803 MC Gouda
3
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.
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
ProwarenessTel: 0182-756500Web:
www.prowareness.nl
Hanzeweg 17Fax:
0182-692021www.scrum.nl
2803 MC Gouda
4
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.
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.
ProwarenessTel: 0182-756500Web:
www.prowareness.nl
Hanzeweg 17Fax:
0182-692021www.scrum.nl
2803 MC Gouda
5
3. Business Value
De 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.
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.
ProwarenessTel: 0182-756500Web:
www.prowareness.nl
Hanzeweg 17Fax:
0182-692021www.scrum.nl
2803 MC Gouda
6
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 Scrum
Nadat 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
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?
ProwarenessTel: 0182-756500Web:
www.prowareness.nl
Hanzeweg 17Fax:
0182-692021www.scrum.nl
2803 MC Gouda
7
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 LeanAgile Framework van Net Objective:
•
Portfolio Area – een thema, een productlijn. Elk bedrijf
heeft één tot enkele portfolio’s;
•
•
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.
ProwarenessTel: 0182-756500Web:
www.prowareness.nl
Hanzeweg 17Fax:
0182-692021www.scrum.nl
2803 MC Gouda
8
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’s
De 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.
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 LeanAgile 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:
•
•
•
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
•
•
•
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.Samenvatting
Lean 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.
ProwarenessTel: 0182-756500Web:
www.prowareness.nl
Hanzeweg 17Fax:
0182-692021www.scrum.nl
2803 MC Gouda
9
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.
•
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.
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;
ProwarenessTel: 0182-756500Web:
www.prowareness.nl
Hanzeweg 17Fax:
0182-692021www.scrum.nl
2803 MC Gouda
10

Download Report