Development Value Streams

Een Development Value Stream is de reeks van activiteiten die worden uitgevoerd om een idee te transformeren naar een (digitale) oplossing. Deze oplossing wordt dan vervolgens binnen de organisatie gebruikt in de Operational Value Streams om waarde te creëren voor de (eind) klant.

De producten die worden gecreëerd door de Development Value Streams worden vrijwel altijd gebruikt door interne Operational Value Streams, maar niet altijd door een externe klant. De klant kan ook een interne klant zijn.

Indien een idee wordt getransformeerd tot een product die vervolgens wordt verkocht aan een klant dan spreken we van een Development Value Stream die het product heeft gemaakt (bijv in de Innovation Journey) en een Operational Value Stream die het product heeft verkocht (in de Customer Journey). Bij dit voorbeeld hebben we dus een combinatie van zowel een Interne als een Externe klant.

Echter, niet alle oplossingen die worden gecreëerd dienen als doel om waarde voor de externe klanten te creëren. Een dashboard dat wordt ontwikkeld voor het management of een in-house ontwikkelde HR registratie app dienen alleen de interne klant.

Product Teams

Het doel van een Development Value Stream is meestal het ontwikkelen en onderhouden van een product (bijvoorbeeld een website of app). Daarom worden Development Value Streams ook vaak aangeduid als Product Teams. In dat geval heeft men een cross-functioneel team samengesteld die verantwoordelijk is voor, en toegewijd aan, één specifiek product.

Agile en Lean Management

Omdat Agile zijn oorsprong kent binnen de wereld van IT en Tech zijn veel van de typische Agile methodes, zoals Scrum, gericht op de Development Value Streams. Door Agile te combineren met Lean Mangement, die zich met name richt op de Operational Value Streams, ontstaat een solide framework dat in staat is om de gehele organisatie te stroomlijnen.

Risico’s en uitdagingen voor Development Value Streams

Eigenaarschap van de Business Hypothese
Development Value Streams bestaan uit de reeks van activiteiten die nodig zijn om een Business Hypothese te transformeren in een (digitale) oplossing. Dit houdt in dat een Business Hypothese, vaak in de vorm van een Epic Hypothesis Statement, de value stream binnen komt en dat de teamleden van de Development Value Streams gaan onderzoeken hoe de hypothese kan worden getoetst en implementeren wat nodig is om de hypothese daadwerkelijk te toetsen.

De Development Value Stream is dus niet de eigenaar van de business hypothese. In veel gevallen zal een Product Owner van een Operational Value Stream of een Epic owner de eigenaar zijn van de business hypothese. Op het moment dat de Development Value Stream het eigenaarschap naar zich toetrekt, of wanneer een Product / Epic Owner zijn of haar rol niet goed pakt, lopen we het risico dat de (digitale) oplossing leidend gaat zijn in plaats van het probleem of wens van de klant. Als gevolg hiervan kan er een mismatch ontstaan tussen de oplossing en het probleem en eindigen we met een oplossing die het probleem niet oplost. Voorbeelden uit de praktijk laten dit vaak zien in een mooi vormgegeven systeem of app die noodzakelijke functionaliteiten mist, waardoor de eindklant uiteindelijk afhaakt. In deze situatie zie je dus dat de business hypothese, in de vorm van een experiment, uiteindelijk faalt. Maar is in dat geval het experiment gefaald doordat de hypothese niet kon worden bewezen of door een slechte implementatie ervan?

Development Value Stream KPI’s
De verantwoordelijkheden verschillen aanzienlijk tussen de Development Value Streams en de Operational Value Streams. Development Value Streams zijn verantwoordelijk voor de ontwikkeling van (digitale) oplossingen. De Key Performance Indicators die de prestaties van de Development Value Streams weergeven moeten dan ook de ontwikkeling van oplossingen vertegenwoordigen. In de praktijk zien we echter vaak dat de Development Value Streams vaak ook Operationele KPI’s en targets krijgt toebedeeld. De directe bijdrage aan operationele KPI’s door Development Value Stream Teams is echter moeilijk te bepalen en deze KPI’s zullen dan ook niet motiverend werken of er zelfs toe leiden dat een Development Value Stream zich als een Operational Value Stream gaat gedragen.

Een Development Value Stream die als KPI en target het aantal verkopen via de bedrijfswebsite mee krijgt zal zich uiteindelijk als een Operational Value Stream gaan gedragen. Ze worden immers verantwoordelijk gemaakt voor Operationele KPI’s. Als gevolg daarvan zal de prioritering van user stories zich gaan focussen op conversie optimalisatie en wellicht minder op stabiliteit, beveiliging en up-time van de website. Ook User Stories die via Product Owners (van Operational Value Streams) of Epic Owners binnen komen, maar niet direct bijdragen aan conversie zullen lager worden geprioriteerd. Het draagt immers niet bij aan de KPI’s en targets van de Development Value Stream.

Voor iedere Value Stream geldt dat hun hun performance moet worden weerspiegeld in de KPI’s. Dit betekent dat de KPI’s een directe afgeleide moeten zijn van hun werkzaamheden en uitgesplitst in Snelheid, Kwaliteit en Kosten. Een Development Value Stream die verantwoordelijk is voor de website zou dus bijvoorbeeld de volgende KPI’s kunnen hebben:

Snelheid:

  • Time to Value of Flow Time: Hoe lang duurt het gemiddeld voordat een user story, nadat deze de workflow is binnengekomen, wordt opgeleverd aan de (interne) klant.
  • Velocity: Het gemiddelde aantal backlog items (bijvoorbeeld stories) opgeleverd binnen een sprint.
  • Sprint Burndown report: In welke mate volgt het voorgangsverloop tijdens de sprint de geplande voortgang.

Kwaliteit

  • Sprint Accuracy: Hoeveel van de items gepland in een sprint worden daadwerkelijk afgerond binnen de geplande sprint
  • Escaped Defects: Hoeveel defecten/issues worden er gerapporteerd na een release.
  • Retro actions: Het aantal verbeteringsmogelijkheden geïdentificeerd tijdens de Sprint Retrospective.

Kosten

  • Average Cost per User Story: Hoeveel kost een User Story gemiddeld om af te ronden. Neem hiervoor alle kosten gedurende een sprint of een andere periode (bijvoorbeeld 3 maanden als er per 3 maanden wordt gepland) en deel dit door het aantal User Stories dat is opgeleverd in die periode. Indien de User Stories value points hebben toegewezen gekregen kan deze KPI ook per Value Point worden uitgerekend en beoordeeld.

KPI’s zoals conversie% of gemiddelde orderwaarde horen dus niet thuis bij een Development Value Stream. Dit zijn de KPI’s van de Operational Value Streams.