Sinds januari 2019 is op scrum.org de EBM Guide beschikbaar. (EBM Guide Downloaden) Tijdens een training die ik laatst mocht geven zag ik dat sommige cursisten veel interesse hadden in het onderwerp. Op zich niet zo vreemd; “Als je het niet kunt meten, kun je het ook niet verbeteren”.
EBM gaat voor het meten uit van outcome en niet van output. Wat is het verschil tussen die twee? Even een korte uitleg. We beginnen met een aantal voorbeelden van output:
- Aantal regels code opgeleverd.
- Hoeveelheid nieuwe features die opgeleverd is.
- Aantal story points verbrand in een sprint.
Een voordeel van output is dat het harde cijfers zijn. Het nadeel is, dat deze vaak eenvoudig te manipuleren zijn en dat het niets zegt over de waarde of kwaliteit van hetgeen geleverd is.
Wat bedoel ik met manipuleren? Neem als voorbeeld; we sturen op het aantal regels code dat opgeleverd is.
Je kunt een statement in 1 regel zetten:
If nr_aap = 5 then nr_visje = 10” end if
Maar je kunt ook schrijven:
If nr_aap = 5 then
nr_visje = 10
End if
Als ik weet dat er op hoeveelheid regels gestuurd wordt, dan is het een kleine moeite om de tweede notitie te gebruiken.
Hetzelfde geldt voor het aantal story points. Het is eenvoudig om als ontwikkelteam de stories een puntje meer te geven bij het pokeren. Worden er dan grotere stories opgepakt? Nee, dat niet. Maar zo lijkt het op papier wel.
Als we kijken naar outcome, dan wordt het anders. Een paar voorbeelden:
- Klant tevredenheid.
- Feature gebruik.
- Time-to-learn.
Feature gebruik geeft bijvoorbeeld aan hoeveel onderdelen van software gebruikt worden. Het gaat bij softwareontwikkeling om het creëren van waarde. Een feature die niet gebruikt wordt, kun je je van afvragen of die waarde heeft en of het veel toevoegt als je hier veel tijd in investeert.
Time-to-learn geeft aan hoe lang we erover doen om te leren. Als we kijken naar nieuwe features, hoe lang duurt het om van een idee tot customer feedback te komen? Daar zitten dus nog stappen tussen als uitwerken, bouwen, uitrollen, gebruiken.
De outcome voorbeelden zijn het resultaat / gevolg van je werk, niet wat je gemaakt hebt. Het geeft een eerlijkere waarde weer hoe je product ervoor staat.
Evidence Based Management (EBM) kent vier Key Value Areas (KVA’s):
- Current Value.
- Unrealized Value
- Ability to innovate
- Time to market
Current Value
Dit geeft de huidige waarde weer van het product. Hoeveel is het product nu waard met de huidige functionaliteit? Hoeveel van het huidige product wordt er daadwerkelijk gebruikt en hoe vaak? Hoe tevreden zijn mensen over het product? Het zegt dus niks over hoe hoog de waarde zou kunnen worden.
Unrealized Value
De ongerealiseerde waarde. Welke waarde zouden we binnen het product nog kunnen realiseren. Wat is het huidige marktaandeel? Dan weet je dus ook hoeveel je nog kan groeien. Wat is het verschil tussen de ervaring die de gebruikers nu hebben met het product en de gewenste ervaring? Dat gat kan overbrugt worden.
Ability to Innovate
Hoe goed kunnen we nieuwe features opleveren? Of juist, waarom kunnen we geen nieuwe features opleveren? Als we iets nieuws maken, hoeveel fouten zitten er dan in? Welke versies staan er overal geïnstalleerd? Des te meer verschillende versies, des te meer effort er in onderhouden van die versies gestopt moet worden. Wat is onze technical debt? De grootste vijand van gepland werk is ongepland werk. Als er veel technical debt is, is de kans groot dat er veel ongepland werk is. Dit gaat weer ten koste van de voorspelbaarheid van een team.
Time-to-market
Hoe snel kan de nieuwste versie van onze software bij de klant geïnstalleerd staan? Maar ook, hoe snel kunnen we gebruikers feedback terug krijgen en van deze feedback leren? Hoe vaak leveren we een release op aan de gebruiker? Hoe lang duurt het voordat een idee is uitgewerkt en bij de klant geïnstalleerd staat?
In de praktijk
Niet alle hierboven genoemde onderdelen heb je als organisatie direct invloed op. Bijvoorbeeld welke versie er bij een klant geïnstalleerd staat, kan ook van de gebruikersorganisatie afhankelijk zijn. Als je netjes iedere 2 weken een nieuwe versie oplevert, maar deze versies worden pas na vijf maanden geïnstalleerd, dan heb je daar niet veel directe invloed op. Dit is bijvoorbeeld afhankelijk van de contractvormen die je hanteert. Verplicht je de gebruikers om altijd bij te zijn met de software of ondersteun je de huidige versie en de drie versies ervoor ook. Of host je de software en bied je de software in een SaaS achtige constructie aan. Je kunt je gebruikers wel meenemen naar een dergelijke oplossing waarin je de gebruiker voor een groot deel ontzorgt.
Het is wel interessant om te kijken wat nu de waardes zijn van de verschillende EBM Key Value Measures (KVM’s). Dit zijn de waarden die je gebruikt om de KVA’s te meten. Bepaal wat wenselijk is en ga dan meten wat de huidige waarden zijn. Bepaal op basis daarvan welke wijzigingen je zou kunnen doorvoeren om te verbeteren.
In de EBM Guide staan verschillende voorbeelden van Key Value Measures die je kunt gebruiken. Je kunt kijken welke binnen jullie organisatie eenvoudig toe te passen zijn. Een aantal kan vrij snel:
Defect trends: hoeveel fouten komen er naar voren sinds de laatste meeting. Je meet hiervoor iedere maand de status van de openstaande incidenten. Maar kijk daarbij ook hoe lang een incident in een bepaalde fase zit. Denk bij de fasen aan zaken als “analyse door support”, “acceptatie door Product Owner”, “uitwerken door ontwikkelteam” of “opnemen van wijziging in release”. Kijk ook hoeveel van deze incidenten daadwerkelijk bugs zijn of bijvoorbeeld inrichtingsproblemen of gebruikersfouten.
Installed version index: welke versie van de software (inclusief patch nummer) staat bij de klant in productie geïnstalleerd? Als organisatie heb je niet direct invloed op de versie die geïnstalleerd wordt. Je kan echter wel onderzoeken waarom een klant bijvoorbeeld twee versies achter loopt en kijken wat je hieraan kunt veranderen.
Product incident trends: hoe vaak wordt een team tijdens het werken onderbroken om een probleem op te lossen in een productie omgeving. Je kunt dit nog verder tastbaar maken door de aantallen groot op te hangen in de teamkamer.
De overige KVM’s zijn wij nog aan het bekijken en beoordelen. We vragen ons daarbij af;
- Kunnen we dit meten?
- Hoe gaan we dit meten? Kan het meten bijvoorbeeld geautomatiseerd of moeten we handmatig gaan turven? Of op een vast moment een rapportje draaien en de waarden overnemen in Excel?
- Wat is een acceptabele waarde?
- Hoeveel invloed kunnen we hier zelf op uitoefenen?
- Is het verbeteren realistisch? Het kan zijn dat voor het verbeteren van een KVM een bestaand proces volledig omgegooid moet worden. Dat hoeft niet altijd een probleem te zijn maar soms is er te veel inspanning / kosten nodig om een kleine verbetering te realiseren. De vraag is hoe belangrijk de betreffende KVM is.
Je kunt EBM ook gebruiken bij het budgetteren van je organisatie. Kijk bijvoorbeeld naar de “opbrengsten per medewerker”. Wat zijn de opbrengsten van een team en hoe groot is het team? Je weet nu hoeveel een medewerker opbrengt. Je kunt afspraken maken over wat de opbrengst per teamlid moet zijn. Dit in tegenstelling tot wat de kosten van een team mogen zijn of wat het ontwikkelen van een feature mag kosten. Het is voor de PO een extra prikkel om hetgeen te leveren waar meer waarde in zit. Het ontwikkelteam heeft een extra prikkel om kwalitatief zo goed mogelijke software op te leveren. Als er veel fouten in zitten, dan zullen er veel bugs terug komen. Tijd die aan bugs besteed zijn, kan niet gebruikt worden om nieuwe features te ontwikkelen. Geen nieuwe features betekent geen waarde oplevering. Gevolg van het leveren van veel waarde en minder bugs is ook hogere klant tevredenheid. Voorwaarde is wel dat je het team voldoende vrijheid geeft om zelf beslissingen te mogen maken over zaken die invloed hebben op de opbrengst.
Conclusie
Ik adviseer om de EBM Guide door te lezen. Kijk naar de huidige manier van meten. Waarop meet je nu binnen de organisatie om te kijken hoe en of je waarde genereert. Meet je nu op output of op outcome? Achterin de EBM Guide staan per KVA voorbeelden die je inspiratie kunnen geven.
Bron: www.scrum.org/resources/evidence-based-management