Lean Software Development principe #7 Optimize the Whole

Binnen een software ontwikkelingsproces zijn veel verschillende teams betrokken die elk hun steentje bijdragen. Maar zijn deze teams wel op elkaar ingespeeld? Kom in dit blog te weten hoe de principe 'Optimize the Whole' van Lean Software Development kan bijdragen aan een betere samenwerking tussen teams.

optimize the whole lean software development

Het gevaar van suboptimalisatie

Teams en personen binnen het software ontwikkelproces werken ieder aan eigen doelstellingen, zoals een Sprint Goal of een specifieke KPI. En dat is logisch. Maar het is niet goed als teams enkel bezig zijn met eigen taken en dit niet afstemmen met de andere teams. Dit noem je ook wel suboptimalisatie. Suboptimalisatie treedt op wanneer een team zijn eigen doelen haalt, maar dit niet tot een verbetering in de algehele waardeketen leidt.

Voorbeeld: een SCRUM team haalt de Sprint Goal, maar het duurt vervolgens nog een maand voordat de software in productie wordt gezet. In dat geval kun je je het nut van het behalen van de Sprint Goal afvragen. Het verraderlijke hieraan is dat het SCRUM team misschien het idee heeft goed bezig te zijn, terwijl het geen direct effect heeft op het eindresultaat.

De kracht van ‘Optimize the Whole’

In tegenstelling tot suboptimalisatie gaat het bij ‘Optimize the Whole’ om het optimaliseren van de gehele waardestroom. Een IT organisatie met een optimale waardestroom kenmerkt zich door een goede samenwerking tussen teams, een gestroomlijnde flow en een snelle levering van software. Het zal tevens minder last hebben van lange wachttijden zoals in het voorbeeld. Lees hieronder hoe je kunt profiteren van deze voordelen.

‘Optimize the Whole’ met een Value Stream Map

Zojuist bespraken we de voordelen van een optimale waardestroom. Maar hoe kom je daar? De eerste stap is de huidige waardestroom in kaart brengen met behulp van een Value Stream Map.

In een Value Stream Map schets je in grote lijnen alle stappen van het gehele proces: van de klantwens tot de uiteindelijke oplevering van software. De klantwens kan bijvoorbeeld de ontwikkeling van een nieuwe feature zijn, maar kan ook gaan om een epic, story of ticket.

Een Value Stream Map wordt opgesteld door de verschillende teams die betrokken zijn bij de ontwikkeling van software. Deze teams weten namelijk precies welke activiteiten plaatsvinden en om welke reden. De Value Stream Map geeft de betrokken medewerkers en hun managers inzicht in de flow van de gehele Value Stream. Ook biedt het een grond voor samenwerking tussen de teams en betrokken personen. Als eenmaal de Value Stream Map is opgesteld kan een nieuwe, continue, flow worden uitgedacht en uitgeprobeerd. Lees in dit blog meer over Value Stream Mapping.

Hoe meet je de vooruitgang van de Value Stream?

Nadat een Value Stream Map is opgesteld en er verbeteringen (liefst veel, maar kleine verbeteringen) zijn doorgevoerd, bijvoorbeeld op het gebied van samenwerking, is het tijd om de effecten te meten. Hiervoor kun je een aantal metrics gebruiken. Voorbeelden van metrics zijn Lead Time, Cycle Time, Customer Value of Market Share.

Lead Time

De tijd die verstreken is van een klantwens tot oplevering

Cycle Time

De tijd die nodig is om een nieuw stuk software op te leveren

Customer Value

De waarde die de klant geeft aan het product

Market Share

Het percentage van de markt dat met het product wordt bediend

Het betrekken van metrics is daarnaast ook een manier om iedereen aan boord te krijgen om de software of applicatie te verbeteren en de klantwaarde te verhogen.

Hoe is de Value Stream van jouw organisatie?

Doet jouw IT organisatie al aan ‘Optimize the Whole’? Of is er sprake van suboptimalisatie? In beiden gevallen is het zinvol om een Value Stream Map op te stellen als basis om de waardestroom te verbeteren. Lees meer over hoe dat werkt in de blog over Value Stream Mapping.

Vragen over 'Optimize the Whole'?

Bel met een expert

Paul Noordhuizen

06 484 31 088

Paul