{"id":73,"date":"2019-08-15T14:08:47","date_gmt":"2019-08-15T14:08:47","guid":{"rendered":"http:\/\/scrum-agile.nl\/?page_id=73"},"modified":"2019-08-29T07:27:25","modified_gmt":"2019-08-29T07:27:25","slug":"evidence-based-managment-in-de-praktijk","status":"publish","type":"page","link":"https:\/\/scrum-agile.nl\/?page_id=73","title":{"rendered":"Evidence Based Managment (in de praktijk)"},"content":{"rendered":"\n<p>Sinds januari 2019 is op scrum.org de EBM Guide beschikbaar. (<a href=\"https:\/\/www.scrum.org\/resources\/evidence-based-management-guide\" target=\"_blank\" rel=\"noreferrer noopener\" aria-label=\"EBM Guide Downloaden (opent in een nieuwe tab)\">EBM Guide Downloaden<\/a>) Tijdens een training die ik laatst mocht geven zag ik dat sommige cursisten veel interesse hadden in het onderwerp. Op zich niet zo vreemd; \u201cAls je het niet kunt meten, kun je het ook niet verbeteren\u201d.&nbsp; <\/p>\n\n\n\n<p>EBM gaat voor het meten uit van outcome en niet van output.\nWat is het verschil tussen die twee? Even een korte uitleg. We beginnen met een\naantal voorbeelden van output:<\/p>\n\n\n\n<ul><li>Aantal regels code opgeleverd.<\/li><li>Hoeveelheid nieuwe features die opgeleverd is.<\/li><li>Aantal\nstory points verbrand in een sprint. <\/li><\/ul>\n\n\n\n<p>Een voordeel van output is dat het harde cijfers zijn. Het\nnadeel is, dat deze vaak eenvoudig te manipuleren zijn en dat het niets zegt\nover de waarde of kwaliteit van hetgeen geleverd is.<\/p>\n\n\n\n<p>Wat bedoel ik met manipuleren? Neem als voorbeeld; we sturen\nop het aantal regels code dat opgeleverd is. <\/p>\n\n\n\n<p>Je kunt een statement in 1 regel zetten: <\/p>\n\n\n\n<p><em>If nr_aap = 5 then\nnr_visje = 10\u201d end if<\/em><\/p>\n\n\n\n<p>Maar je kunt ook schrijven:<\/p>\n\n\n\n<p><em>If nr_aap = 5 then<br>\n&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; nr_visje = 10<br>\nEnd if<\/em><\/p>\n\n\n\n<p>Als ik weet dat er op hoeveelheid regels gestuurd wordt, dan\nis het een kleine moeite om de tweede notitie te gebruiken.<\/p>\n\n\n\n<p>Hetzelfde geldt voor het aantal story points. Het is eenvoudig\nom als ontwikkelteam de stories een puntje meer te geven bij het pokeren.\nWorden er dan grotere stories opgepakt? Nee, dat niet. Maar zo lijkt het op papier\nwel.<\/p>\n\n\n\n<p>Als we kijken naar outcome, dan wordt het anders. Een paar\nvoorbeelden:<\/p>\n\n\n\n<ul><li>Klant tevredenheid.<\/li><li>Feature gebruik.<\/li><li>Time-to-learn.<\/li><\/ul>\n\n\n\n<p>Feature gebruik geeft bijvoorbeeld aan hoeveel onderdelen\nvan software gebruikt worden. Het gaat bij softwareontwikkeling om het cre\u00ebren\nvan waarde. Een feature die niet gebruikt wordt, kun je je van afvragen of die\nwaarde heeft en of het veel toevoegt als je hier veel tijd in investeert. <\/p>\n\n\n\n<p>Time-to-learn geeft aan hoe lang we erover doen om te leren.\nAls we kijken naar nieuwe features, hoe lang duurt het om van een idee tot\ncustomer feedback te komen? Daar zitten dus nog stappen tussen als uitwerken,\nbouwen, uitrollen, gebruiken. <\/p>\n\n\n\n<p>De outcome voorbeelden zijn het resultaat \/ gevolg van je\nwerk, niet wat je gemaakt hebt. Het geeft een eerlijkere waarde weer hoe je\nproduct ervoor staat.<\/p>\n\n\n\n<figure class=\"wp-block-image\"><img loading=\"lazy\" width=\"1024\" height=\"665\" src=\"https:\/\/scrum-agile.nl\/wp-content\/uploads\/2019\/08\/EBM-1024x665.png\" alt=\"\" class=\"wp-image-67\" srcset=\"https:\/\/scrum-agile.nl\/wp-content\/uploads\/2019\/08\/EBM-1024x665.png 1024w, https:\/\/scrum-agile.nl\/wp-content\/uploads\/2019\/08\/EBM-300x195.png 300w, https:\/\/scrum-agile.nl\/wp-content\/uploads\/2019\/08\/EBM-768x499.png 768w, https:\/\/scrum-agile.nl\/wp-content\/uploads\/2019\/08\/EBM.png 1213w\" sizes=\"(max-width: 767px) 89vw, (max-width: 1000px) 54vw, (max-width: 1071px) 543px, 580px\" \/><figcaption><br><\/figcaption><\/figure>\n\n\n\n<p>Evidence\nBased Management (EBM) kent vier Key Value Areas (KVA\u2019s):<\/p>\n\n\n\n<ol><li>Current Value.<\/li><li>Unrealized Value <\/li><li>Ability to innovate <\/li><li>Time to market<\/li><\/ol>\n\n\n\n<p><strong>Current Value<\/strong><\/p>\n\n\n\n<p>Dit geeft de huidige waarde weer van het product. Hoeveel is\nhet product nu waard met de huidige functionaliteit? Hoeveel van het huidige\nproduct wordt er daadwerkelijk gebruikt en hoe vaak? Hoe tevreden zijn mensen\nover het product? Het zegt dus niks over hoe hoog de waarde zou kunnen worden.<\/p>\n\n\n\n<p><strong>Unrealized Value<\/strong><\/p>\n\n\n\n<p>De ongerealiseerde waarde. Welke waarde zouden we binnen het\nproduct nog kunnen realiseren. Wat is het huidige marktaandeel? Dan weet je dus\nook hoeveel je nog kan groeien. Wat is het verschil tussen de ervaring die de\ngebruikers nu hebben met het product en de gewenste ervaring? Dat gat kan\noverbrugt worden.<\/p>\n\n\n\n<p><strong>Ability to\nInnovate<\/strong><\/p>\n\n\n\n<p>Hoe goed kunnen we nieuwe features opleveren? Of juist,\nwaarom kunnen we geen nieuwe features opleveren? Als we iets nieuws maken,\nhoeveel fouten zitten er dan in? Welke versies staan er overal ge\u00efnstalleerd?\nDes te meer verschillende versies, des te meer effort er in onderhouden van die\nversies gestopt moet worden. Wat is onze technical debt? De grootste vijand van\ngepland werk is ongepland werk. Als er veel technical debt is, is de kans groot\ndat er veel ongepland werk is. Dit gaat weer ten koste van de voorspelbaarheid\nvan een team.<\/p>\n\n\n\n<p><strong>Time-to-market<\/strong><\/p>\n\n\n\n<p>Hoe snel kan de nieuwste versie van onze software bij de\nklant ge\u00efnstalleerd staan? Maar ook, hoe snel kunnen we gebruikers feedback\nterug krijgen en van deze feedback leren? Hoe vaak leveren we een release op\naan de gebruiker? Hoe lang duurt het voordat een idee is uitgewerkt en bij de\nklant ge\u00efnstalleerd staat?<\/p>\n\n\n\n<p><strong>In de praktijk<\/strong><\/p>\n\n\n\n<p>Niet alle hierboven genoemde onderdelen heb je als\norganisatie direct invloed op. Bijvoorbeeld welke versie er bij een klant\nge\u00efnstalleerd staat, kan ook van de gebruikersorganisatie afhankelijk zijn. Als\nje netjes iedere 2 weken een nieuwe versie oplevert, maar deze versies worden\npas na vijf maanden ge\u00efnstalleerd, dan heb je daar niet veel directe invloed\nop. Dit is bijvoorbeeld afhankelijk van de contractvormen die je hanteert.\nVerplicht je de gebruikers om altijd bij te zijn met de software of ondersteun\nje de huidige versie en de drie versies ervoor ook. Of host je de software en\nbied je de software in een SaaS achtige constructie aan. Je kunt je gebruikers\nwel meenemen naar een dergelijke oplossing waarin je de gebruiker voor een\ngroot deel ontzorgt. <\/p>\n\n\n\n<p>Het is wel interessant om te kijken wat nu de waardes zijn\nvan de verschillende EBM Key Value Measures (KVM\u2019s). Dit zijn de waarden die je\ngebruikt om de KVA\u2019s te meten. Bepaal wat wenselijk is en ga dan meten wat de\nhuidige waarden zijn. Bepaal op basis daarvan welke wijzigingen je zou kunnen\ndoorvoeren om te verbeteren. <\/p>\n\n\n\n<p>In de EBM Guide staan verschillende voorbeelden van Key\nValue Measures die je kunt gebruiken. Je kunt kijken welke binnen jullie\norganisatie eenvoudig toe te passen zijn. Een aantal kan vrij snel:<\/p>\n\n\n\n<p><strong>Defect trends:<\/strong>\nhoeveel fouten komen er naar voren sinds de laatste meeting. Je meet hiervoor\niedere maand de status van de openstaande incidenten. Maar kijk daarbij ook hoe\nlang een incident in een bepaalde fase zit. Denk bij de fasen aan zaken als \u201canalyse\ndoor support\u201d, \u201cacceptatie door Product Owner\u201d, \u201cuitwerken door ontwikkelteam\u201d\nof \u201copnemen van wijziging in release\u201d. Kijk ook hoeveel van deze incidenten\ndaadwerkelijk bugs zijn of bijvoorbeeld inrichtingsproblemen of\ngebruikersfouten. <\/p>\n\n\n\n<p><strong>Installed version\nindex:<\/strong> welke versie van de software (inclusief patch nummer) staat bij\nde klant in productie ge\u00efnstalleerd? Als organisatie heb je niet direct invloed\nop de versie die ge\u00efnstalleerd wordt. Je kan echter wel onderzoeken waarom een\nklant bijvoorbeeld twee versies achter loopt en kijken wat je hieraan kunt\nveranderen.<\/p>\n\n\n\n<p><strong>Product incident\ntrends:<\/strong> hoe vaak wordt een team tijdens het werken onderbroken om een probleem\nop te lossen in een productie omgeving. Je kunt dit nog verder tastbaar maken\ndoor de aantallen groot op te hangen in de teamkamer. <\/p>\n\n\n\n<p>De overige KVM\u2019s zijn wij nog aan het bekijken en\nbeoordelen. We vragen ons daarbij af;<\/p>\n\n\n\n<ul><li>Kunnen we dit meten?<\/li><li>Hoe gaan we dit meten? Kan het meten\nbijvoorbeeld geautomatiseerd of moeten we handmatig gaan turven? Of op een vast\nmoment een rapportje draaien en de waarden overnemen in Excel? <\/li><li>Wat is een acceptabele waarde?<\/li><li>Hoeveel invloed kunnen we hier zelf op\nuitoefenen?<\/li><li>Is het verbeteren realistisch? Het kan zijn dat\nvoor het verbeteren van een KVM een bestaand proces volledig omgegooid moet\nworden. Dat hoeft niet altijd een probleem te zijn maar soms is er te veel\ninspanning \/ kosten nodig om een kleine verbetering te realiseren. De vraag is\nhoe belangrijk de betreffende KVM is.<\/li><\/ul>\n\n\n\n<p>Je kunt EBM ook gebruiken bij het budgetteren van je\norganisatie. Kijk bijvoorbeeld naar de \u201copbrengsten per medewerker\u201d. Wat zijn\nde opbrengsten van een team en hoe groot is het team? Je weet nu hoeveel een\nmedewerker opbrengt. Je kunt afspraken maken over wat de opbrengst per teamlid\nmoet zijn. Dit in tegenstelling tot wat de kosten van een team mogen zijn of\nwat het ontwikkelen van een feature mag kosten. Het is voor de PO een extra\nprikkel om hetgeen te leveren waar meer waarde in zit. Het ontwikkelteam heeft\neen extra prikkel om kwalitatief zo goed mogelijke software op te leveren. Als\ner veel fouten in zitten, dan zullen er veel bugs terug komen. Tijd die aan\nbugs besteed zijn, kan niet gebruikt worden om nieuwe features te ontwikkelen.\nGeen nieuwe features betekent geen waarde oplevering. Gevolg van het leveren\nvan veel waarde en minder bugs is ook hogere klant tevredenheid. Voorwaarde is\nwel dat je het team voldoende vrijheid geeft om zelf beslissingen te mogen\nmaken over zaken die invloed hebben op de opbrengst.<\/p>\n\n\n\n<p><strong>Conclusie<\/strong><\/p>\n\n\n\n<p>Ik adviseer om de EBM Guide door te lezen. Kijk naar de\nhuidige manier van meten. Waarop meet je nu binnen de organisatie om te kijken\nhoe en of je waarde genereert. Meet je nu op output of op outcome? Achterin de\nEBM Guide staan per KVA voorbeelden die je inspiratie kunnen geven.<\/p>\n\n\n\n<p><em>Bron: www.scrum.org\/resources\/evidence-based-management<\/em><\/p>\n\n\n\n<p><\/p>\n","protected":false},"excerpt":{"rendered":"<p>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; \u201cAls je het niet kunt meten, kun je het ook niet verbeteren\u201d.&nbsp; EBM gaat voor het meten uit &hellip; <\/p>\n<p class=\"link-more\"><a href=\"https:\/\/scrum-agile.nl\/?page_id=73\" class=\"more-link\"><span class=\"screen-reader-text\">&#8220;Evidence Based Managment (in de praktijk)&#8221;<\/span> verder lezen<\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"parent":0,"menu_order":0,"comment_status":"open","ping_status":"closed","template":"","meta":[],"_links":{"self":[{"href":"https:\/\/scrum-agile.nl\/index.php?rest_route=\/wp\/v2\/pages\/73"}],"collection":[{"href":"https:\/\/scrum-agile.nl\/index.php?rest_route=\/wp\/v2\/pages"}],"about":[{"href":"https:\/\/scrum-agile.nl\/index.php?rest_route=\/wp\/v2\/types\/page"}],"author":[{"embeddable":true,"href":"https:\/\/scrum-agile.nl\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/scrum-agile.nl\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=73"}],"version-history":[{"count":13,"href":"https:\/\/scrum-agile.nl\/index.php?rest_route=\/wp\/v2\/pages\/73\/revisions"}],"predecessor-version":[{"id":114,"href":"https:\/\/scrum-agile.nl\/index.php?rest_route=\/wp\/v2\/pages\/73\/revisions\/114"}],"wp:attachment":[{"href":"https:\/\/scrum-agile.nl\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=73"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}