Agile Evidence-Based Management is een framework dat organisaties kunnen gebruiken om hen te helpen de waarde die zij ontlenen aan hun productlevering te meten, te managen en te verhogen.

EBM richt zich op het verbeteren van resultaten, het verminderen van risico’s, en het optimaliseren van investeringen. Het meten van waarde, voor de klant en stakeholders, om verbetering en flexibiliteit van de organisatie mogelijk te maken

Measuring Value to Enable Improvement and Agility.

De in dit artikel beschreven Evidence-Based Management is gebaseerd op de EBM-guide (link) die ontwikkeld en ondersteunt wordt door Ken Schwaber en scrum.org

In Agile organisaties past de traditionele EBM-methode minder goed, de cycli zijn namelijk wezenlijk anders. Een deel van de traditionele EBM-methode kan nog steeds gebruikt worden, maar deze biedt niet voldoende aansluiting met agile denkrichtingen.

Toch is het interessant en raadzaam om ook de traditionele benadering van EBM te lezen en deze te vergelijken met de agile EBM benadering. Het is belangrijk om in een EBM gesprek te weten welke keuzes men maakte in de traditionele benadering, want gegarandeerd zullen traditionele insteekjes in een agile EBM-gesprek naar voren komen.

Voor de traditionele benadering van EBM verwijs ik je naar het artikel: Wat is Evidence-Based Management?

EBM op agile wijze past veel beter in het huidige tijdsbeeld, de uitdaging is om deze goed te introduceren en verder uit te bouwen.

Waarom Agile Evidence-Based Management?

Agile organisaties passen frequente retrospectie toe, daarmee worden risico’s beperkt en neemt het vermogen om waarde te leveren toe. De adaptieve cultuur versnelt de mogelijkheden om kansen te benutten.

In tegenstelling tot de traditionele EBM-methode is Agile Evidence-Based Management een empirische methode, die i.c.m. agile principes en waarden het mogelijk maakt om succesvolle veranderstappen te maken.

Evidence-Based Management helpt agile organisaties met de juiste maatregelen te nemen door andere inzichten te bieden, zoals op de juiste plaatsen te investeren, slimmere beslissingen te nemen en risico’s te beperken door middel van een iteratieve en incrementele aanpak.

In dit artikel worden veel afbeeldingen gebruikt om het totaalplaatje sneller te kunnen overzien. 

De doelen van Agile EBM

Het doel van EBM is om in een onzekere wereld het vermogen om waarde te leveren te verbeteren door een agile verbeterpad te zoeken naar het strategisch doel. Het start veelal met een Experiment Loop.

De Experiment Loop

EBM hanteert een Experiment Loop, de meesten zullen deze herkennen als een vorm van de  PDCA-cycle. In de agile EBM theorie beschrijft men voor de zekerheid nog maar even dat het om kleine, meetbare stappen gaat. Door het vormen van een hypothese, het uitvoeren van een experiment, het inspecteren van het resultaat en het aanpassen van je doelen of aanpak omdat je hebt geleerd. Dit is voor elke agilist een vanzelfsprekendheid, voor de volledigheid wordt dit aan het einde van dit artikel verder beschreven.

Door deze Experiment Loop zal je elke keer stappen kunnen maken, je behaald tussenliggende doelen of past ze aan en vraagt je af of omstandigheden zijn gewijzigd waardoor je tactieken, doelen of zelfs het strategisch doel gewijzigd dient te worden.

Agile EBM hanteert 5 key elementen

EBM Helps Organizations Seek toward Their Goals in a Complex World Using Empiricism.

Een Strategic Goal, Intermediate Goals, Immediate Tactical Goals, a Current State en een Starting State (deze begrippen in het Engels, omdat je ze dient te kennen).

In het Nederlands: strategisch doel, tussenliggend doel, tactische doelen, huidige toestand en begintoestand. Zie onderstaande afbeelding:

Het doel van een organisatie kan vrij simpel geformuleerd worden: waarde leveren aan de klant en stakeholders. Dit is een mooie brug naar de 4 KVA’s van agile Evidence-Based Management. 

De 4 Key Value Areas van agile EBM (KVA)

Naast het gebruiken van hypothesen en experimenten om richting doelen te bewegen, voorziet EBM in een set perspectieven op waarde en de geschiktheid van de organisatie om waarde televeren. Deze perspectieven noemen we Key Value Areas (KVAs).

Om te bepalen welke waarde je levert hoeft er eigenlijk maar één hoofdvraag beantwoord te worden:

Welke activiteiten worden ontplooit om de waarde creatie (dus uitkomsten) voor klanten en stakeholders te verbeteren?

EBM hanteert om dit te kunnen beoordelen 4 Key Value Areas (KVA)! Dit zijn:

• Current Value – CV (Huidige Waarde). Meet de waarde die vandaag aan de klant of gebruiker wordt geleverd
• Unrealized Value – UV (Ongerealiseerde Waarde). Meet de waarde die zou kunnen worden gerealiseerd door aan alle potentiële behoeften van de klant of gebruiker te voldoen
• Ability to Innovate – A2I (Vermogen om te innoveren). Meet het vermogen om een nieuwe capaciteit te leveren die beter zou kunnen voldoen aan een behoefte van een klant of gebruiker.
• Time to Market – T2M Meet het vermogen om snel een nieuwe capaciteit, dienst of product te leveren

Deze 4 factoren verstrekken inzicht in de capaciteit van de organisatie om de volgende stappen voor verbetering te bepalen.

Hoe staan de 4 EBM KVA’s in verhouding tot elkaar?

Elke KVA focust op een eigen aspect van ofwel waarde, of de geschiktheid van de organisatie om waarde te leveren.

Het vandaag leveren van business waarde (Current Value) is belangrijk, maar organisaties moeten ook in staat zijn om te reageren op verandering (Time-to-Market), voortdurend blijven innoveren (Ability-to-Innovate) en richting hun lange termijn doelen (Unrealized Value) werken.

Hoe bereik je jouw strategisch doel?

Het makkelijkste is om dit in een aantal stappen op te splitsen:

1. Om naar het strategische doel te kunnen reizen dien je Current Value te begrijpen.
2. Vaak zal jouw primaire focus liggen op Unrealized Value (want daar ligt de waarde die je voor de klant zou kunnen brengen).
3. Dan zal je eerst je Current Value moeten bepalen van jouw product of dienst. (bij nieuw product of dienst is deze nog nul).
4. Om te kunnen verbeteren dien je ook begrip te krijgen van je Ability to Innovate (A2I) en te begrijpen wat je kan/moet doen aan je Time to Market (T2M)

Bovenstaande is geen rocket science, maar een logisch proces dat elk agile team kan doorlopen. Want je wilt weten waar je staat, voordat je ergens heen kan reizen. De reis is hoogstwaarschijnelijk geen rechte lijn naar het strategisch doel, maar een iteratief process waar continue gekeken wordt of de juiste waarde kan worden geleverd en of men zich nog steeds in de juiste richting begeeft.

Het juiste meten!

De 4 KVA’s geven dus richting aan datgene wat gemeten kan worden.

Een van de uitdagingen waar organisaties voor staan is het juiste meten. Wist je overigens dat regelmatig de verkeerde zaken worden gemeten of resultaten van een meting worden toegepast op zaken waarvoor de meting niet gebruikt kan worden? Is dit in jouw organisatie ook het geval?

Agile werken kenmerkt zich door een focus op waarde toevoeging voor de klanten en stakeholders. Dat betekent dat veel metingen zinvol zijn voor bepaalde doelen, maar zich helaas niet richten op het meten van uitkomsten voor klanten en stakeholders! En laten de uitkomsten nu eens de belangrijkste meting zijn.

Activiteiten, outputs en uitkomsten

Om meer inzicht te creëren stelt EBM dat er over het algemeen drie meet categorieën zijn: activiteiten, outputs en uitkomsten. Laten we die eens toelichten:

1. Activiteiten zijn dingen die mensen in de organisatie doen. Voorbeelden zijn werken en  meetings.
2. Outputs zijn dingen die de organisatie produceert. Voorbeelden zijn rapportages en productreviews. 
3. Uitkomsten zijn de wensen die een klant of gebruiker van een product ervaart, zoals een nieuwe of verbeterde mogelijkheid van het product of dienst. Voorbeelden: sneller reizen of meer kunnen sparen.

Het is van groot belang om je te realiseren dat je alleen met uitkomsten waarde kan leveren! Waarbij de waarde overigens ook negatief kan zijn, bijvoorbeeld wanneer eerdere ervaringen hoger werden gewaardeerd.

Er is niets mis met het meten van en sturen op activiteiten en outputs, maar realiseer je terdege dat dit niet automatisch leidt tot een betere uitkomst voor de klant en stakeholders.

De uitdaging voor de meeste organisaties is dat het meten van activiteiten en outputs eenvoudig te doen is, maar het meten van uitkomsten als lastig ervaren wordt.

Toch zijn de uitkomsten voor de klant en stakeholders het doel waar een organisatie naar dient te streven. Want nog steeds geldt dat het voor de klant niet uit maakt hoe hard je werkt (activiteit) of hoe veel functionaliteit (output) je levert, de klant is op zoek naar een betere klantervaring (uitkomst). Dit betekent dus ook dat extra activiteiten en extra output niet per definitie de gewenste uitkomst voor de klant verbetert.

Wat is nu de kern van agile EBM?

Vanzelfsprekend zal een agile organisatie iteratieve ontwikkeling, continue integratie en testgestuurde ontwikkeling al lang hebben omarmt. Wat een organisatie dan goed kan gebruiken is een methode om resultaten en mogelijke maatregelen te begrijpen.

Dat begrijpen leer je door de 4 Key Value Areas toe te passen, de informatie die hieruit volgt gebruik je om geïnformeerde en op bewijs gebaseerde beslissingen te nemen voor organisatorisch leren en voortdurende verbetering. Daardoor ontstaat een continue verbeteringscultuur en hoogstwaarschijnlijk een concurrentievoordeel.

Derhalve komen we nog een keer terug op de 4 KVA’s met een toelichting en de bijbehorende vragen in onderstaande afbeelding.

Doelen 4 KVA’s

Een strategisch doel wordt ingevuld door te handelen vanuit een tevredenheidskloof en een kans voor een organisatie. Deze invulling komt tot stand door de Unrealized Value te verlagen, omdat de Current Value een hogere waarde krijgt door de iteratieve stappen naar het strategische doel.

In onderstaande afbeelding staat de hoofdvraag en de vragen die je op continue basis zou kunnen stellen tijdens de iteraties.

Current Value (CV)

Het doel van CV is om de waarde te begrijpen die een organisatie op dit moment levert aan klanten en stakeholders. Je mag alleen meewegen wat nu al bestaat, je mag niet de mogelijke toekomstwaarde meewegen.

Het inzetten van het kernbegrip Current Value helpt een organisatie om de waarde te begrijpen die hun klanten en/of gebruikers op dit moment ervaren.

Unrealized Value (UV)

Het doel van Unrealized Value is de waarde van een product of dienst te kunnen maximaliseren. Het is de potentiële waarde die in de toekomst behaald kan worden wanneer de organisatie de behoeftes vervult van potentiële klanten of gebruikers.

Het beschouwen van zowel CV als UV geeft organisaties een manier om huidige zowel als mogelijke toekomstige voordelen af te wegen. Wanneer klanten of stakeholders een verschil ervaren tussen de huidige ervaring en de gewenste ervaring, dan vertegenwoordigt het verschil hiertussen een kans. Unrealized Value meet deze kans!

Time-to-Market (T2M)

Het doel van T2M is het minimaliseren van de tijd die het de organisatie kost om waarde te leveren.

T2M is het vermogen van de organisatie om snel nieuwe mogelijkheden, diensten of producten te leveren te bepalen. De reden om naar T2M te kijken is actief bij te kunnen sturen om in de toekomst waarde te kunnen blijven leveren.

Wanneer T2M verbetert, verbetert ook de frequentie waarmee een organisatie haar CV mogelijk kan aanpassen.

Ability to Innovate (A2I)

Het doel van Ability to Innovate is het maximaliseren van het organisatievermogen om nieuwe mogelijkheden en innovatieve oplossingen te leveren. Waardoor men nog beter voldoet aan de klantbehoefte.

Ability to Innovate draagt zorg voor een effectieve manier van werken, zodat de  verrichtingen ook daadwerkelijk waarde leveren aan klanten of stakeholders.

Hypothesen, experimenten, features en requirements

EBM stelt dat elke feature en iedere requirement een hypothese over waarde is of dient te zijn.

Een van de doelen van een empirische aanpak is om deze hypothesen expliciet te maken en doelbewust experimenten te ontwerpen die de waarde van de features en requirements expliciet testen.

Het expliciet vormen van hypothesen voor verbetering, het doen van experimenten, het inspecteren van resultaten en het aanpassen van doelen gebaseerd op die resultaten, zijn impliciet onderdeel van een wendbare aanpak.

EBM vereist dat werk expliciet en transparant is, waardoor het toevoegt aan het organisatie verbeterproces.

Definities die hierbij van belang zijn:

• Features zijn “kenmerkende eigenschappen van een product”,
• Een requirement is wat iemand wenselijk vindt in een product.
• Een feature-beschrijving is een voorbeeld van een requirement.
• Overtuigingen over waarde zijn slechts aannames totdat deze zijn gevalideerd door klanten.
• een hypothese is een voorgestelde verklaring voor een bepaalde observatie, die nog niet bewezen of ontkracht is. (In de context van requirements)
• Een experiment is een test die is ontworpen om een bepaalde hypothese te bewijzen of verwerpen.

Key Value Measures

EBM schrijft geen Key Value Measures (KVMs) voor, want dat zal elk agile (leadership) team zelf moeten bepalen. In eerste instantie kan de agile EBM methode wat vaag lijken, want aan wat voor metingen kun je dan denken?

Onderstaand een overzicht van mogelijke metingen per KVA. Aan het team om de juiste te hanteren voor jouw specifieke doelen.  

In mijn optiek zeer verhelderend, ook al zul je een aantal metingen wellicht nog niet kennen of hanteren. Maar dat komt vanzelf op je pad, als je start met Agile Evidence-Based Management.

Hoe verder?

Net als het Scrum framework is de Evidence-Based Management framework niet een volledig voorschrijvend framework, het biedt uitdrukkelijk de mogelijkheid om op een agile wijze je keuzes te maken. Zolang het een empirische methode blijft EN alle elementen worden gebruikt.

In het begin van Scrum was er sprake van scepsis, het gedachtegoed was volledig anders dan voorgaande it-ontwikkelaars gewend waren. Inmiddels is Scrum een leidend framework, EBM zal dit hoogstwaarschijnlijk pad volgen. Waarom? Omdat agile EBM het missende stukje was om VALUE handvatten te geven.

Hoewel het mogelijk is om slechts delen te gebruiken van EBM is het resultaat dan geen EBM. Net als Scrum geen Scrum is als je het framework niet volledig inzet.

Tot slot

Mocht je informatie(delen) uit dit artikel willen gebruiken, verwijs dan naast agile4all.nl s.v.p. ook naar scrum.org en de EBM-guide.

Wil je nu uit nieuwsgierigheid lezen hoe de traditionele EBM eruit ziet? Lees dan: Wat is Evidence-Based Management?

Het bericht Wat is Agile Evidence-Based Management? verscheen eerst op agile4all.

LeSS is een agile framework voor het opschalen van agile ontwikkeling naar meerdere teams. LeSS is een afkorting van Large Scaled Scrum, een op Scrum gebaseerde Scalings framework.

Het doel van LeSS is om grootschalige ontwikkelprojecten succesvol te ondersteunen en tegelijkertijd dicht tegen en binnen het Scrum-framework te blijven. In eerste instantie vooral IT-gerichte productontwikkeling.

Zoals wellicht bekend is Scrum oorspronkelijk bedoeld voor één team. Binnen LeSS worden de Scrumprincipes en -regels geschikt gemaakt voor grootschalige projecten.

LeSS is ontwikkeld door Craig Larman en Bas Vodde. Vanaf 2005 hebben beide heren het LeSS scaling framework verder ontwikkeld.

Als je nog niet bekend bent met Scrum, lees dan eerst het artikel: Scrum in 3 minuten

LeSS in vogelvlucht

Er zijn inmiddels vrij veel scalingsframeworks, LeSS is een van de eerdere scaling frameworks. Craig Larman en Bas Vodde hebben een manier bedacht om Scrum met meerdere teams tegelijkertijd toe te passen. Hun LeSS framework voegt een extra proces toe ten opzichte van Scrum voor één team.

Net als alle andere agile frameworks hanteert LeSS regels, gebaseerd op principes en het doen van experimenten. Ook definieert LeSS procesbeschrijvingen, definities, artifacts en rollen en nog een aantal andere zaken. De belangrijkste worden in dit artikel beschreven. 

Bij Scrum zijn de teams cross functioneel met weinig of geen specialisatie. Dit geldt ook voor LeSS, want alle teams werken aan hetzelfde. Waarbij elk team bestaat uit 7 plus of min 2 members. Elk team beschikt over een range aan vaardigheden, zoals domeinkennis, architectuur, design, testen en coderen. Gezamenlijk leveren ze een gemeenschappelijk increment op aan het einde van de Sprint.

Met LeSS toepassen wil je de schaal van ontwikkeling vergroten. In tegenstelling tot traditionele ontwikkelmethoden (project/programma) is het belangrijkste doel om dingen zo eenvoudig mogelijk op te lossen. Dus geen toename van allerlei functies door het toevoegen van een projectorganisatie of Integration teams of System Teams of een PMO. Dit zie je wel in meerdere andere scalingmethodieken. Voorbeelden hiervan zijn Nexus en Safe. In dit kader staat LeSS voor minder: minder kosten en minder complexiteit.

Rollen in LeSS

Binnen LeSS zien we de bekende individuele Scrum Teams. Meerdere Teams zijn echter nodig wanneer het te ontwikkelen product niet door één team afgehandeld kan worden. Vanzelfsprekend moet er dan gekeken worden welke teams welke werkzaamheden gaan vervullen.

Hierbij kan onderscheid gemaakt worden tussen cross functionele teams, Feature Teams en Component Teams. LeSS kiest voor Feature teams die de optimale klantwaarde leveren door de focus op specifieke klantdimensies. In een ander artikel zal het verschil tussen Component en Feature teams worden beschreven.

De Scrum Teams bestaan uit een Development Team, een Scrum Master en een gedeelde/gezamelijke Product Owner. De Scrum Teams werken volgens de Sprint Backlog, houden hun Daily Scrums en voeren geregeld Product Backlog Refinements uit. Binnen LeSS wordt dit aangeduid met One Team Scrum. Daartoe heeft LeSS een aantal events t.o.v. Scrum anders ingevuld.

LeSS heeft de rollen van Product Owner, Scrum Master en Team in tact gelaten, maar wel een rol toegevoegd: de Area Product Owner.

In LeSS is er geen manager-rol, maar managers kunnen aanwezig zijn. Dan is hun rol gericht op het leveren van waarde van het totale systeem en niet gericht op het specifieke product.

2 soorten LeSS

LeSS beschrijft dus hoe meerdere teams effectief aan dezelfde productontwikkeling werken. Toename van het aantal mensen is namelijk ook toename van de complexiteit.

Binnen Basis LeSS-framework komen we maximaal acht Scrum Teams tegen. Zijn meer dan acht teams noodzakelijk, dan wordt het LeSS Huge-framework gehanteerd.

Er zijn 2 soorten LeSS beschikbaar: Basic LeSS en LeSS Huge.

Basic LeSS:

Bij Basic LeSS komen we maximaal acht Scrum Teams tegen. Want Basic LeSS is voor 2 tot 8 teams die aan dezelfde productontwikkeling werken. Eigenlijk is Basic Less sterk vergelijkbaar met Scrum met 1 team. De uitbreiding zit in:

Een Scrum Master kan 1 tot en met 3 teams faciliteren. Een Scrum Master begeleidt en leert de teams hoe ze in LeSS moeten werken. Een Product Owner beheert de product backlog, de lijst met features.

Er is slechts:

• 1 Product Backlog
• 1 Definition of Done (DoD)
• één gemeenschappelijke Sprint
• 1 increment

Teams hebben direct contact met de klant, terwijl de Product Owner zich richt op het bepalen van de route, de prioriteiten en de langetermijnvisie van het product.

Wat is het verschil van Basic LeSS met Scrum?

Binnen LeSS is sprake van één Sprint waarin één Product Increment wordt opgeleverd. Dit betekent dat de Sprint Planning voor alle teams tegelijkertijd moet plaatsvinden. Ook de Sprint Review (demo) en Sprint Retrospective vinden met alle teams tegelijkertijd plaats. Het team bepaalt wanneer de Product Backlog Refinement plaatsvindt.

De sprintplanning is in 2 delen opgesplitst:

• Een sessie van Product Owner met een deel van de teamleden om te bepalen welke product backlog items worden opgenomen in de Sprint. Waarbij (een deel van) het werk wordt verdeeld over de teams.
• Een sessie met leden van alle teams, waar teams die tijdens de volgende sprint aan dezelfde taken werken, vragen hebben of opheldering nodig hebben van andere team(s). Deze sessie is kort na de sessie met de Product Owner of vindt parallel plaats.

LeSS Huge

Zijn meer dan acht teams noodzakelijk, dan wordt het LeSS Huge-framework gehanteerd. LeSS Huge is namelijk het framework voor meer dan 8 teams die aan dezelfde productontwikkeling werken. Volgens de LeSS methodiek ga je dus over van Basis naar Huge als je meer dan 8 Basic LeSS teams hebt.

In LeSS Huge zijn er dus meerdere Basic LeSS teams tegelijkertijd werkend aan dezelfde productontwikkeling. Er zijn meerdere Product Owners die Area Product Owners worden genoemd. Elk verantwoordelijk voor zijn ‘eigen’ Product Backlog. Maximaal 3 teams werken samen met 1 Area Product Owner. De Chief Product Owner zorgt voor de alignment tussen de Area Product Owners en overziet het totale product. 

• Area Product Owners zijn verantwoordelijk voor hun respectievelijke product backlog.
• Een Chief Product Owner leidt de Area Product Owners en richt zich op het gehele product.
• De Scrum Teams bestaan uit een Development Team, een Scrum Master en een gedeelde/gezamenlijke Product Owner.

Events

Net als in Scrum zijn er events, hiervan staat hieronder een samenvatting per event in LeSS.

Sprint

Er worden sprints gepland waarbij de teams in elke sprint een (deel)product maken dat opgeleverd kan worden. Deze sprints kunnen 1 tot 4 weken duren, maar na keuze van de lengte van de Sprint is de afgesproken periode een gegeven.

De ontwikkeling is iteratief en incrementeel. Binnen LeSS is sprake van één Sprint waarin één potentieel Product Increment wordt opgeleverd. Dit betekent dat de Sprint Planning voor alle teams tegelijkertijd moet plaatsvinden.

Sprint Planning

Er zijn twee planningsfasen in LeSS. Voor de planning in 2 fasen worden zoals gebruikelijk whiteboards of remote walls gehanteerd. De twee fasen van de Sprint Planning zijn:

Eerste fase

De eerste fase van de sprintplanning bestaat uit het selecteren van items uit de Product Backlog. Twee leden van elk team ontmoeten hun producteigenaar om de selectie te maken uit de items met hoge prioriteit van de backlog.

Tweede fase

In de tweede fase van de planning bespreekt het team de geselecteerde items.

Zodra teams de items uit de Product Backlog hebben gekozen, wordt de planning gedaan om de sprintdoelen te bereiken. Hierdoor ontstaat de Sprint Backlog.

De Scrum Teams werken vervolgens de Sprint Backlog, houden hun Daily Scrums en voeren geregeld Product Backlog Refinements uit.

Product Backlog Refinement

Het team bepaalt wanneer de Product Backlog Refinement plaatsvindt. Er kan ook een Product Backlog Refinement sessie worden gehouden. In deze Product Backlog Refinement sessie bespreken klant en de teams hoe het bestaande kan worden verbeterd en/of er nieuwe wensen moeten worden toegevoegd. Deze sessie is ook essentieel om te praten over het werk dat gedaan moet worden in de komende sprints.

Voor coördinatie en afstemming tijdens de Sprint kan gebruikgemaakt worden van de Scrum of Scrums, bijwonen van Daily Scrums en multi team bijeenkomsten.

Dagelijkse Scrum

De Daily Standup wordt door elk team onafhankelijk gehouden. De inhoud van de Daily wordt in dit artikel niet verder beschreven, interessanter is hoe informatie ook op andere manieren gedeeld kan worden, naast de Sprint Review en Retrospectives.

Voor het delen van informatie kan een lid van het ene team in de Daily Scrum vergadering van een ander team plaatsnemen. Voor het delen en coördineren over meerdere teams kan ook binnen LeSS een Open Space sessie worden gehanteerd. Een Scrum of Scrum sessie met de Scrum Masters mag ook.

De te kiezen methode zal per organisatie kunnen verschillen, maar hoe dan ook: in LeSS komen de vertegenwoordigers van elk team regelmatig bijeen om de werkzaamheden te coördineren.

Sprint Review

De Sprint Review (demo) vindt met alle teams tegelijkertijd plaats. De teams sturen teamvertegenwoordigers. Tijdens de LeSS Sprint Review kijken de relevante klanten, de belanghebbenden, de gebruikers, de Scrum Teams en de Product Owner naar het complete, geïntegreerde product en besluiten ze hoe verder te gaan.

Met name bij Less Huge kan het voorkomen dat er zeer grote opleveringen plaatsvinden. Dan wordt er vaak een fysiek event van gemaakt waar gedemonstreerd kan worden. Een overleg over het opgeleverde vindt sowieso plaats.

Sprint Retrospective

Na de Sprint Review hebben alle Scrum Teams tegelijkertijd hun eigen Sprint Retrospective.

De teams hebben regelmatig een eigen terugblik op wat er gedaan wordt om continu te verbeteren.

Overall Retrospective

Daarna vindt binnen LeSS een nieuwe gebeurtenis plaats, de Overall Retrospective. De focus van de Overall Retrospective ligt op het verbeteren van het gehele systeem en niet op hoe goed de teams het doen.

De Overall Retrospective wordt bijgewoond door de Product Owners, Scrum Masters en vertegenwoordigers van elk team en wordt gehouden kort nadat een sprint is voltooid. Management kan aanwezig zijn, met name om belemmeringen die van invloed zijn op de levering van het product te begrijpen en daarop te kunnen acteren.

De inhoud van de Overall Retrospective is dat Product Owner, Scrum Masters en de teams kijken naar de volgende aspecten:

• Samenwerking tussen de teams en teamontwikkeling.
• Klantgerichtheid van de teams.
• Teams delen gebeurtenissen en/of ervaringen.
• Functioneren van de Product Owner.

Samenvatting

LeSS is een afkorting van Large Scaled Scrum. Een op Scrum gebaseerde scalings framework. Er zijn twee soorten: Basic LeSS en LeSS Huge. 

LeSS Huge is vergelijkbaar met Basic LeSS, door de omvang van de productontwikkeling en het aantal teams, zijn er bij LeSS Huges twee of meer Area Product Owners. De Area Product Owners en de ene overall Product Owner vormen het Product Owner team.

Elk ontwikkelingsgebied heeft idealiter vier tot acht teams. Basic LeSS hanteert twee tot acht teams. Aangezien het werk onder Less Huge meestal meerdere Area teams van vier tot acht teams is, is de basiswerking van teams onder Basic LeSS en LeSS Huge hetzelfde.

Er is ook een artikel Wat is Scrum Nexus Framework? Eveneens een op Scrum gebaseerde scaling methodiek.

Wil je weten welke uitdagingen je tegenkomt als je gaat scalen? Zie het artikel: 8 uitdagingen van het opschalen van agile.

Het bericht Wat is LeSS? Large Scaled Scrum! verscheen eerst op agile4all.

Nexus is een eenvoudige scaling methode van Scrum voor ca. 3 tot en met 9 teams. Het doel van Scrum Nexus is om de productiviteit te verhogen door onderlinge afhankelijkheden te verkleinen. Een Nexus focussed zich op goed samenwerken en bestaat uit een Nexus Integration Team en ca. 3 tot en met 9 teams.

Nexus is dus een eenvoudig scaling framework dat bestaat uit rollen, gebeurtenissen, artefacten en technieken die het gezamenlijk werk verbinden en verweven. Meerdere Teams werken aan één Product Backlog om een gezamenlijk Increment elke Sprint te kunnen opleveren om een gezamenlijk doel te bereiken.

Het Nexus framework kan je het beste beschouwen als een toevoeging, een soort overlay, op het bestaande Scrum framework. Veel zaken blijven dan ook ongewijzigd, zoals dat de teams gewoon via de reguliere scrum principes blijven werken. Op een aantal belangrijke aspecten wijkt het echter af. Het belangrijkste verschil is dat er veel meer aandacht word besteed aan afhankelijkheden en samenwerking tussen Scrum Teams.

Wat je vast ook al direct wilt weten is dat het Nexus scaling framework niet vraagt om een wijziging in de organisatiestructuur. Dit kan wel, maar is geen vereiste. Dit in tegenstelling tot andere scaling methodes, zoals bijvoorbeeld het SAFe framework.

Een volledig en uitgebreide beschrijving vindt je in de Nexus Guide. Dit artikel is een beschrijving van het Nexus Framework en een samenvatting van de belangrijkste veranderingen t.o.v. het Scrum Framework.

Ben je nog niet op de hoogte hoe het volledige Scrum framework in elkaar zit? Dan verwijs ik je naar het artikel Scrum framework.

Waarom Scrum Nexus?

Een van de bedenkers van Scrum (Ken Schwaber) heeft samen met scrum.org een methode bedacht om meerdere Scrum teams met elkaar beter te laten samen werken. De methode Scrum of Scrums werkt vanzelfsprekend ook, maar met Scrum Nexus is verdere opschaling mogelijk.

Opleveren van een geïntegreerd stuk werk is het bewezen succes van Nexus. Het is de verantwoordelijkheid van de Nexus integratieteam om alle Nexus teams de juiste tools, richtlijnen, support en/of al het andere wat de team nodig hebben om hun (software) integratie succesvol te laten zijn.

Dagelijks wordt de voortgang van meerdere teams besproken. De verkregen informatie is input voor de Scrum teams die ook dagelijks plannen.

Rollen in de Nexus

Nexus Integration Team

Laat ik beginnen met de kern van het Nexus framework. Het Nexus Integration Team bestaat uit:

• De Product Owner
• Scrum Master en
• één of meer Nexus Integration Teamleden

Het doel van het Integration Team is om al het werk te coördineren van alle Scrum teams. Het werk kan dan worden samengevoegd zonder conflicten. De noodzaak van een Integration Team wordt steeds groter naarmate er meer teams aan dezelfde Product Backlog werken

Product Owner in het Nexus Integration Team

De Product Owner is lid van het Nexus Integration Team en is verantwoordelijk voor het maximaliseren van de waarde van het geïntegreerde op te leveren werk (integrated increment) door het beheren van de Product Backlog.

Scrum Master in het Nexus Integration Team

Het Nexus framework (laten) begrijpen en juist (laten) uitvoeren. Overigens kan deze Scrum Master ook een rol hebben in één of meerdere teams in de Nexus.

Nexus Integration Teamleden

De Nexus Integration Teamleden dragen zorg voor de Definition of Done, begeleiden en coachen de Scrum teams in een Nexus. Zowel op praktijken en tools, maar ook met standaardontwikkeling, infrastructuur en architectuur. Als aan voorstaande voorwaarden is voldaan, mogen ze ook werken als teamleden in één of meer Nexus Scum Teams.

Artifacten voor het Nexus Framework

T.o.v. het standaard Scrum Framework zijn de volgende artifacten anders:

• één Nexus Product Backlog voor alle teams, met een Nexus Product Owner voor de prioritering.
• een ‘eigen’ Sprint Backlog voor elk Scrum team. Die een afgeleide is van de gekozen Stories van de Nexus Product Backlog.
• de Nexus Sprint Backlog is de samengevoegde individuele Sprint Backlog. Het is het totale plan voor de Sprint, die helpt om alle afhankelijkheden tussen Scrum teams inzichtelijk te maken.
• Daarnaast is een geïntegreerde Definition of Done: de Nexus Sprint Goal. Scrum Teams in de Nexus mogen een strengere definitie van DoD hanteren, maar zeker geen lichtere versie.

Refinement

Refinement is een bekende activiteit binnen het Scrum Framework. Voor de Nexus geldt dat naast dat er bepaald gaat worden welke items geleverd zullen worden, ook de afhankelijkheden moeten worden geïdentificeerd.

Nexus Sprint Planning

Het coördineren van alle activiteiten van alle Scrum teams in een Nexus voor de komende Sprint.

Het Nexus Sprint Goal

Het Nexus Sprint Goal komt voort uit de Sprint Planning.

Als het totale werk van de Nexus wordt begrepen, gaat de Nexus Sprint Planning verder. Men gaat verder met het uitvoeren van de eigen Sprint Planning door ieder Scrum Team.

Overige activiteiten

De overige activiteiten tijden de Nexus Sprint Planning lijken sprekend op een ‘gewone’ Sprint Planning. Hier is het vooral waakzaam blijven op nieuwe afhankelijkheden die zichtbaar worden en nog tijdens de Nexus Sprint Planning geminimaliseerd moeten worden.

Nexus Daily Scrum

In tegenstelling tot een ‘gewone’ Daily Scrum wordt er door vertegenwoordigers van de teams de status van het increment beoordeeld. De focus ligt op het bespreken en oplossen van integratie issues en team overstijgende afhankelijkheden.

Wat wel echt anders is t.o.v. Scrum dat er 3 nieuwe vragen zijn:

• Was het werk van de vorige dag succesvol geïntegreerd. Zo nee, waarom niet?
• Welke nieuwe afhankelijkheden zijn geïdentificeerd?
• Welke informatie moet gedeeld worden met de team in de Nexus?

Issues en werk worden daarop meegenomen naar de individuele teams.

Nexus Sprint Review

De Nexus Sprint Review vervangt de Sprint Reviews van individuele Scrum Teams. Stakeholders geven feedback op het volledige integrated increment. Niet al het werk wordt in detail getoond. Het resultaat van de Nexus Sprint Review is een gereviseerde Product Backlog.

Nexus Sprint Retrospective

De Nexus Sprint Retrospective vindt plaats na de Nexus Sprint Review en voor de volgende Nexus Sprint Planning.

De Nexus Sprint Retrospective is net als een ‘normale’ Retrospective bedoelt om als team het eigen handelen te bespreken, verbeter mogelijkheden te bespreken en deze mee te nemen naar de volgende Sprint. Het grote verschil bij Nexus is echter de omvang en er zijn andere vragen te stellen.

Nexus Sprint Retrospective bestaat uit 3 onderdelen:

1. Vertegenwoordigers uit heel de Nexus ontmoeten elkaar en identificeren issues die impact hadden op meer dan één team. Het doel is om gedeelde issues transparant te maken voor alle Scrum Teams.
2. Het houden van eigen Sprint Retrospectives door ieder Scrum Team. Issues uit het eerste deel van de Nexus Sprint Retrospective kunnen worden gebruikt als input voor discussies binnen hun teams. De individuele Scrum Teams zouden acties moeten formuleren om de issues te adresseren tijdens hun eigen Sprint Retrospectives.
3. Vertegenwoordigers van de Scrum Teams ontmoeten elkaar opnieuw en komen met elkaar overeen hoe geïdentificeerde acties zichtbaar gemaakt en gevolgd kunnen worden. Hierdoor is de Nexus als geheel in staat om zich aan te passen.

Zoals je zult begrijpen hebben veel problemen met scaling te maken, maar hier gaat het ook om de inhoud. Idealiter worden de volgende onderwerpen tijdens elke Retrospective behandeld:

• Is er werk niet gedaan? Heeft de Nexus technical debt gegenereerd?
  • technical debt: extra werk ontstaan door het implementeren van een kortetermijnoplossing in plaats van de beste oplossing.
• Zijn alle artefacten, en in het bijzonder code dagelijks succesvol geïntegreerd?
• Is de software succesvol gebouwd, getest en vaak genoeg uitgerold om onopgeloste afhankelijkheden te voorkomen?

Bespreek indien nodig voor elk van bovenstaande vragen:

• Waarom is dit gebeurd?
• Hoe maak je de technical debt ongedaan?
• Hoe voorkom je herhaling?

Uit bovenstaande blijkt duidelijk dat de scrum value transparantie een belangrijk aandeel heeft in het Nexus Framework.

Samenvatting

Nexus is een effectieve manier om Scrum op te schalen. Het is ontwikkeld door de founders van Scrum. Het introduceert een aantal nieuwe concepten waarmee teams geholpen worden om effectief te kunnen opschalen. Groeien met meerdere teams is mogelijk, maar toch zijn de voorschriften zo beperkt mogelijk gebleven. Net als Scrum.

‘Scrum is simple, but hard’

Bovenstaande is een vaak gehoorde uitdrukking. Het Scrum framework is relatief simpel, maar het echt goed toepassen is een uitdagende klus.

Net als Nexus. Het framework is verrassend simpel, maar het is een uitdaging om met meerdere teams een gezamenlijk increment op te leveren. Met een focus op continuous improvement, excellente vaardigheden en hard werken is het mogelijk.

Tot slot

Alleen als het Nexus raamwerk, met alle Nexus rollen, artefacten, gebeurtenissen en regels wordt gehanteerd is het volgens de bedenkers een Nexus.

Scrum.org heeft een Nexus examen beschikbaar. Bij het behalen van het examen ontvang je het certificaat: Scaled Professional Scrum (SPS). Ik heb dit certificaat behaald. Goed inzicht in de verschillen en overeenkomsten met het reguliere Scrum framework is verstandig! Naast feitelijke kennis over het Nexus framework.

Een ander scaling framework gebaseerd op Scrum is LeSS.

Het bericht Wat is Scrum Nexus? verscheen eerst op agile4all.

Planning Poker is een techniek, waarbij een inschatting van de benodigde Story Points voor de User Story plaatsvindt. Dit is nodig om te bepalen hoeveel werk de User Story vermoedelijk is, maar ook hoeveel en welke User Stories in de komende Sprint kunnen worden opgenomen. Er is namelijk een maximum aan het aantal Story Points die in een Sprint kan worden opgenomen, vanwege de beschikbare tijd voor de Sprint en de capaciteit van het Team.

Alle teamleden bepalen vooraf de mogelijke tijdsduur van een User Story. De techniek die men vaak gebruikt is het hanteren van Planning Poker kaarten.

Je moet deze techniek eigenlijk zien en leren toepassen. Toch zal ik trachten het te beschrijven.

Waarom Planning Poker kaarten?

Het team gebruikt Planning Poker kaarten om wederzijdse beïnvloeding te voorkomen. Als teamleden geen kaarten gebruiken en achtereenvolgens een tijdsduur schatting maken van een User Story gaat men elkaar wellicht volgen. Het team maakt dan geen gebruik van de volledige denkkracht en inzichten die een team heeft. Om dit te voorkomen geeft iedereen tegelijkertijd een schatting door het tonen van een kaart met een waarde.

In bovenstaande plaatje staan mogelijke waarden van een kaart. Het team spreekt vooraf met elkaar af welke waarden mogen worden gebruikt.

Er zijn een aantal stappen die je als team doorloopt:

• deelnemers krijgen een set kaarten met vooraf bepaalde waarden.
• De Product Owner leest een User Story voor. Er is daarna ruimte voor toelichting en een korte discussie.
• Elke deelnemer pakt een kaart met zijn/haar schatting van de tijdsduur.
• Alle deelnemers laten hun kaart tegelijkertijd zien.
• Daarna bespreekt met de verschillen. De hoogste versus de laagste kaart is zeker een eerste discussie waard.
• Er volgt een nieuwe ronde inschattingen, dit gaat door totdat er een gelijk beeld ontstaat.

Conclusie

Planning Poker is een handige techniek om de grootte van een User Story vast te stellen. Er zijn meer technieken om dit te doen, maar deze is wel de bekendste.

Het bericht Wat is Planning Poker? verscheen eerst op agile4all.

Inleiding

Wat is de rol van het Scrum Master als servant leader binnen agile werken?

In dit artikel zet ik de kern van de rol van de Scrum Master (SM) overzichtelijk neer. Overeenkomstig de rollen van het Development Team (DT) en Product Owner (PO).

In andere blogs zal ik dieper op de bijbehorende processen en structuren in gaan.

Verantwoordelijkheid

• Een Servant Leader die zorg draagt voor de juiste uitvoering van het Scrum proces.

Karakteristieken

• Coachen van het multidisciplinaire team op zelforganisatie.
• Coachen van de Product Owner en de organisatie voor het juiste gebruik van Scrum technieken.
• Adviseert over agile principes en scrum technieken.
• Verwijderen van belemmeringen (impediments), daar is de SM accountable voor.
• Het uitdagen van de effectiviteit van het team.
• Evalueert binnen teams, met Product Owner, andere Scrum Masters, stakeholders en tussen teams.
• Richt zich vooral op samenwerking in team EN dynamiek, houding en gedrag van het team.

Aandachtspunten:

• Een Scrum Master mag niet ingezet worden als (traditionele) projectleider, omdat hij/zij dan de agile rol niet kan vervullen!
• Een veelvoorkomend misverstand is dat de Scrum Master inhoudelijk verantwoordelijk is voor het project. Dat is dus niet juist. Overigens is dit met grote regelmaat één van de examenvragen, als (in)directe vraag wordt dit misverstand getest. Lees bovenstaande verantwoordelijkheid en karakteristieken dus goed door.
• Coaching is een taak van de Scrum Master, maar kan ook een full time job zijn. Dat is echter geen formele rol volgens de Scrum Guide.
• Stakeholder management gericht op agile principes.

Meer weten?

Welke services levert de Scrum Master?

De facilitator als probleemoplosser?

Het bericht Wat is de rol van de Scrum Master als servant leader? verscheen eerst op agile4all.

Wellicht de makkelijkste manier om een Retrospective te doen is de ‘Start, Stop en Go! methode’. Deze methode is een vrij zakelijke benadering om gedragsverandering tot stand te brengen.

Veranderingen in gedragscomponenten kunnen het hele team veel tijd opleveren, zoals bijvoorbeeld stoppen met te laat komen. Het hele team zit dan te wachten op degene die te laat komt. Vaak vragen gedrag gerelateerde items om extra aandacht en een andere Retrospective vorm, soms is er echter behoefte aan een recht-toe-recht-aan methode.

Start, Stop en Go!

In deze Retrospective is het primaire doel dat het team zich uitspreekt over wat zij willen opstarten, stoppen of mee doorgaan. Deze methode gaat voorbij aan de onderliggende gevoelens, maar zoekt naar gedragscomponenten en/of gedragingen die (niet) gewenst zijn. De issues die naar voren komen  worden daarna op een vrij zakelijke manier behandeld. Vaak zijn het juist de gevoelens die besproken dienen te worden, deze methode is vooral geschikt om snel teamafspraken te maken.

Start

Simpele vragen volstaan. Waarmee gaan we starten? Wat voegen we toe aan het proces? Dit kan natuurlijk van alles zijn. Het team brengt de punten in. Een paar voorbeelden: ‘eerder testen’ en ‘op tijd zijn voor de Daily.’

Stop

Waarmee gaan we stoppen? Deze vraag is direct gerelateerd aan tijdsverspilling en inefficiënt werken, maar ook aan tijd voor belangrijkere zaken vrij te maken. Voorbeelden van stoppen met activiteiten: ‘meer dan 15 minuten besteden aan de dagelijkse Stand Up of Backlog Refinement‘ terwijl je achterloopt’.

Go!

Waarmee je door wilt gaan noem ik ‘Go!’ Een verkorting van: Go with the flow. Doorgaan met waar je al voor gekozen hebt en als het goed is dagelijks mee bezig bent. Hier benadruk je naar elkaar wat je als team belangrijk vindt om vast te houden voor de komende sprints.

Het is de bedoeling dat hier alleen de punten worden vermeld die nog niet standaard zijn in het teamproces. Anders krijg je ellenlange lijsten. Als het team het punt heeft gerealiseerd, kan het weer van de lijst af. Er kunnen dus ook punten opstaan die bij ‘Start’ en ‘Stop’ ook vermeld staan.

Coach het team!

Voor het verkrijgen van voorstaande input is het verstandig om als Coach of Scrum Master steeds andere methodes te hanteren, zoals

• Roep maar!
• Achtereenvolgende beurten (bijv. 2x rondje langs de velden).
• Focus op 1 of 2 specifieke items.
• Richt je alleen op Stop items.
• Behandel alleen Start items.
• Bespreek de Go! items.
• Variaties of combinaties van bovenstaande.

Stop uiterlijk op het moment dat de creativiteit opdroogt, maar nog beter is om iets eerder te stoppen.  Een goede Agile werkwijze is overigens ook om te stoppen met bovenstaande methodes als er geen nieuwe inzichten meer worden ingebracht.

Stem

Als er genoeg items verkregen zijn, begint het stemmen over de items.

Ook dit kan op verschillende manieren:

• Elk teamlid mag 1 item uitkiezen.
• Elk teamlid heeft 3 stickertjes, mag die plakken zoals die wilt.
  • 1 item krijgt 3 stickers
  • 2 stickers op 1 item en één op een ander item
  • 3 aparte items krijgen allen één sticker.
• Het team mag handen opsteken voor een voorselectie (werkt snel bij veel ingebrachte items).
• Het team mag handen opsteken (werkt snel bij weinig ingebrachte items).

Welke methode je ook kiest, het doel moet zijn dat er maximaal drie belangrijke items overblijven! Besteedt niet teveel tijd aan de overige minder belangrijke items. Daar stemt het team over: hou je deze items vast op een lijst of verwijder je ze van de lijst?

Fijn, dan is er een lijst met aandachtspunten. Deze komen natuurlijk terug in de Stand Ups en vanzelfsprekend in de volgende Retrospective, sommige teams plaatsen deze punten op de Board.

De eerstvolgende Retrospective

Om een snelle start van de volgende Retrospective te verkrijgen vraagt de coach en/of Scrum Master aan het team om de afspraken of de ideeën van de vorige Retrospective op een Scrum Board of Flip Over te plaatsen.

Het gaat hier om alle ideeën die nog op de lijst staan. Zowel de 3 gekozen ideeën, als de overige niet gekozen, maar nog wel op de lijst staande items. Dit is voor het team een geheugensteuntje voor de nieuwe Retrospective.

Dan start deze nieuwe Retrospective opnieuw met een Start, Stop en Go!

Voor- en nadelen Start, Stop en Go!

Voordelen van Start, Stop en Go!

• Stuurt op gedragsverandering, totdat het een gewoonte is.
• Weinig emoties, het gaat niet over gevoelens van het team.
• Zeer actiegericht.
• Niet confronterend.
• Het werkt.

Nadeel van Start, Stop en Go!

• Gaat voorbij aan gevoelens, richt zich op de taak.
• De taakgerichtheid laat onderliggende zaken mogelijk sluimeren.

Samenvatting

Een Retrospective methode die zich richt op veranderen van gedrag zonder echt rekening te houden met gevoelens. Of dit past bij jou, je team en de organisatie zal elke keer anders beoordeeld worden. Deze methode werkt, is duidelijk en leidt vaak snel tot resultaat. Bepaal zelf de mogelijke toepasbaarheid.

Er is ook een artikel over het geven van feedback in een retrospective: ik-ik-jij Feedback methode

Het bericht Retrospective: Start, Stop en Go! verscheen eerst op agile4all.

Scrum

Is een ​​van de leidende agile-(software)ontwikkelingsprocessen. De Scrum methodologie is een agile methode om op een innovatieve wijze nieuwe producten en diensten te ontwikkelen.

Wist je dat?

Scrum een bewezen proces is voor het beheren van softwareprojecten. De Scrum methodologie is inmiddels erkend als een van de beste frameworks cq. raamwerken voor het verwerken van snel veranderende of evoluerende projecten, vooral voor projecten met technologische onzekerheden of -vereisten.

Scrum wordt tegenwoordig steeds vaker ingezet voor reguliere product- en diensten ontwikkeling, waarbij softwareontwikkeling een minder belangrijke rol inneemt.

Wereldwijd gebruiken talloze organisaties het Scrum framework.

Wat is Scrum?

Maar wat is de Scrum-methode en hoe werkt het? De simpelste manier om dat uit te leggen is om eerst de focus te beschrijven.

Het doel van de Scrum methodologie is om het meest waardevolle product op te leveren binnen een korte vooraf bepaalde tijd en budget. Dit door het hanteren van een waarde gedreven aanpak. Het creëren van klantwaarde is daarbij belangrijker dan het voldoen aan een planning. De Scrum methode ondersteunt bij het opleveren van (een toevoeging op) het product. Een product dat binnen het benoemde tijdsbestek goedkoper en sneller kan worden ontwikkelt, van de vereiste kwaliteit is en voldoet aan de behoeften van de klant op dat moment.

Het is een eenvoudige methode die snel te leren is. Flexibel is, maar ook vraagt om discipline en snel bruikbaar resultaat levert. Het meest kenmerkende is dat er agile wordt gewerkt:

• zelfstandige multidisciplinaire teams,
• gebaseerd is op een goede samenwerking met de klant,
• gecombineerd met een intensieve communicatie, feedback en teamspirit.

Dat zijn ook meteen een aantal redenen waarom het Scrum proces veelal als effectief en prettig werken wordt ervaren.

Nieuw in de wereld van Scrum?

Als je nieuw bent in de wereld van Scrum, dan vindt je veel interessante artikelen op deze site. Op deze site staan tientallen artikelen over Scrum: deze site bied een reis van basics, via intermediate naar advanced.

Ben je op zoek naar een totaaloverzicht van de Scrum methode? Lees dan dit artikel:

Het Scrum Framework 

Het bericht Scrum in 3 minuten verscheen eerst op agile4all.

Velocity wordt berekend door aan het einde van de Sprint het opgeleverde werk in Story punten te bepalen. Dit doe je door van alle volledig opgeleverde User Stories het aantal Story punten op te tellen.

Velocity is een metric die gehanteerd wordt om de hoeveelheid werk die een team aan kan in één Sprint te kunnen bepalen. Velen zien Velocity als een van de belangrijkste metrics binnen Scrum. Zowel om de ontwikkeling van het team in opeenvolgende periodes te kunnen bepalen, maar ook omdat het zo een handig hulpmiddel is tijdens de Sprint Planning meeting.

Velocity is wellicht de bekendste Agile metric. Het is vermoedelijk ook de meest onjuist gebruikte en overgewaardeerde metric binnen Agile werken.

Hoe bereken je Velocity op de juiste manier?

Voor de duidelijkheid. Alleen Story points tellen die in de ‘Done’ kolom staan aan het eind van de betreffende Sprint, controleer nog wel even of ze voldoen aan de Definition of Done. Wat heel belangrijk is, is dat alleen volledig afgeronde Stories tellen. Dat je alleen punten telt als de Story in de afgelopen Sprint volledig is afgerond en zeker niet relateert aan wanneer deze is gestart. Vaak zullen de Stories op voorhand zo klein worden gemaakt dat ze in een Sprint afgerond kunnen worden, dat is altijd de beste keuze. Soms is dat echter niet mogelijk of niet gelukt. Dan val je terug op bovenstaande: alleen volledig afgeronde Stories tellen.

Even een voorbeeld. Stel een Story met 5 punten is gestart in Sprint 6 en deze was aan het einde van Sprint 6 voor 80% klaar. Dat zijn dus nul punten voor deze User Story in deze Sprint. Je mag absoluut geen deelpunten toekennen voor 80% klaar, je mag dus geen 4 punten toekennen in dit specifieke voorbeeld.

In Sprint 7 is de Story klaar. Dan tel je 5 punten, mits het opgeleverde werk voldoet aan de Definition of Done. Blijf hierin consistent, anders heb je niet veel aan deze metric.

Een andere fout die je niet mag maken is deze punten pas te tellen als het werk wordt opgeleverd aan de klant.  Want hier bestaat de mogelijkheid dat een Stakeholder en/of Product Owner besluit om het opgeleverde werk pas later aan de klant ter beschikking te stellen. Dit is vanzelfsprekend niet ideaal, want het creëert ‘waste’, maar daar gaat het nu tijdens deze uitleg even niet om. De punten worden toegekend als de Story ‘done’ is, omdat je wilt bijhouden hoeveel werk een team kan afronden binnen een gegeven periode tijd. Niet hoeveel of hoe vaak (software) wordt opgeleverd aan de klant.  

Waarom Velocity?

Een van de fijnste redenen om Velocity bij te houden is om teams met elkaar te kunnen vergelijken. Een team met een Velocity van 12 is minder goed dan een team met een Velocity van 10.

Ik hoop dat je erg geschrokken bent van bovenstaande stelling! Want dit is dit een denkrichting die heel vaak terugkomt. Dit is geen agile denkrichting, maar ‘ouderwets management denken’. Velocity mag nooit gebruikt worden om de ‘performance’ van een team te vergelijken.

Velocity is namelijk geen metric om effectiviteit, efficiency, competentie of whatever tussen teams of met anderen te vergelijken. Het is slechts een cijfer die weergeeft hoeveel vraagstukken binnen een bepaalde tijd worden omgezet in geteste software of product toevoegingen. Het mooiste is nog wel dat er honderden redenen kunnen zijn waarom een team een bepaalde Velocity heeft, maar dat het merendeel van deze redenen helemaal niets te maken hebben met bijvoorbeeld hoeveel ervaring er is in het team.

De risico’s van Velocity

Het eerste risico van Velocity is dit cijfer onjuist te gebruiken. Het cijfer verstrekt het team een benchmark om goed te kunnen plannen. Door een juiste inschatting te maken van hoeveel werk kan worden gedaan binnen een gegeven tijdsperiode. That is it! Maar lees het volgende eens….

Geen openheid of respect

Er gaan veel stemmen op om de velocity nooit aan buitenstaanders mede te delen, dus ook niet aan de manager. Helaas is dit niet open, maar dit gedrag is veelal gebaseerd op eerder getoond gedrag van belanghebbenden. Deze zien Velocity als een efficiency tool!

Als een buitenstaander het vraagt,vraag je minimaal waarom diegene het wilt weten, als het antwoord is: ‘om te vergelijken’ moet je dit eerst met het team overleggen. Als het antwoord is ‘omdat ik wil weten wanneer het werk klaar is’ dan is het open antwoord: wanneer je verwacht dat het klaar is. Ook hier geldt vanzelfsprekend dat alle Scrum Values volledig van toepassing zijn. Naast openheid is er ook respect nodig.

Kwaliteit en value?

Het tweede risico. Velocity zegt helemaal niets, nul, nada over kwaliteit of value (waarde). Kwaliteit en Value? Dat zijn toch twee hele belangrijke zaken en daar zegt het meest gebruikte metric van Scrum helemaal niets over. Velocity gaat namelijk eigenlijk alleen over hoeveel Story punten er van links naar rechts op het bord zijn gegaan.

Een goed gesprek behoort te gaan over klant verwachtingen en hoever de opgeleverde Story punten hieraan tegemoet komen. Is het leven van de afnemer echt beter geworden, of zijn we trots op onze nieuwe functionele of niet-functionele testen en benchmarks. Kortom, de klant interesseert het geen zier hoeveel Story Points er zijn gerealiseerd. Het gaat de klant om kwaliteit en waarde!

Dus wil jij een team beoordelen of vergelijken met behulp van het velocity cijfer? Dan beoordeel je ook de belangrijkste zaken niet.

Maar ken je deze risico’s van Velocity ook?

Alleen het team kan bepalen hoeveel Story Punten er worden gegeven aan een Story. Als Velocity een te belangrijke graadmeter is dan krijgt elke Story minimaal 100 Points! Nu zijn wij voortaan de beste! Kortom, er ontstaat iets wat je mag beschouwen als een ongewenste situatie. En dat ontstaat omdat een cijfer onjuist gebruikt wordt.

Story points zeggen normaliter iets over moeilijkheidsgraad en complexiteit. Stel het team kiest om een item uit te werken met veel Story punten, want het andere team scoort vaker een hogere Velocity. Het team ‘scoort’ 35 punten voor iets wat de klant totaal niet interesseert. Het team geeft trots aan dat er een een top Velocity ‘score’ is neergezet! Maar liefst 35 punten i.v.m. de moeilijkheidsgraad en complexiteit! Veel meer dan het andere team.

Dat doet mij echter helemaal niets, ik denk namelijk dat jij ook veel liever 10 Story Points ziet die echte waarde leveren voor de klant.

Hoe gebruik je Velocity veilig?

Veel Scrum Masters kiezen er voor om een voortschrijdend gemiddelde te hanteren van de 3 achtereenvolgende sprints. Dit is wellicht het meest betrouwbare cijfer om de mogelijkheden voor de komende Sprint goed te beoordelen. De hoogte- en dieptepunten worden statistisch gezien enigszins afgevlakt.

Hou vooral in de gaten dat veranderingen in team, omgeving, Stakeholders, Product, Product Owner veel impact kunnen hebben op de Velocity. Het is dus raadzaam om de team Velocity slechts voor een paar Sprints te gebruiken. Dit doe je vooral als je een Burnup of Burndown Chart gebruikt. Dan visualiseer je de Velocity met de laatst bekende gemiddelde.

Een alternatief hiervoor is Story Throughput, deze gebruik je als Story Points alleen gebruikt worden om voorwaarts te plannen. Deze behandel ik later een keertje.

Het bericht Velocity verscheen eerst op agile4all.

De Sprint wordt afgesloten met een Sprint Retrospective. In dit event wordt de Sprint door het team geëvalueerd en worden verbeterpunten benoemd die worden meegenomen in de volgende Sprint. In de Sprint Retrospective gaat het over ‘continue verbeteren’. Hoe goed een team ook is, er zijn altijd verbeteringen mogelijk.

Team reflectie

De Sprint Retrospective is normaal gesproken het laatste event van de lopende Sprint. Het team reflecteert het teamproces, werkwijze en de onderlinge relaties. Los van de inhoud bespreekt het team hoe ze het hebben gedaan en wat ze zouden kunnen verbeteren.

Het hele team is aanwezig, dus ook Scrum Master en Product Owner. Vaak is een uur genoeg, maar als de vlam in de pan slaat door escalatie van een issue, kan het veel langer duren. Dit kan leiden tot (stevige) meningsverschillen, waar de Scrum Master of Agile Coach al zijn vaardigheden zal moeten inzetten om dit goed te begeleiden.

Waarom een Sprint Retrospective?

Om een Sprintdoel te bereiken werkt men samen. Samenwerken is niet altijd vanzelfsprekend. Samenwerken vraagt om Shared Values en wederzijds begrip voor verschillende meningen, opinies en achtergronden. Een Retrospective maakt ruimte om verbeterpunten (ook verschillen) bespreekbaar te maken en creëert van een groep individuen een hecht team.

Eenvoudige Retrospectives

De basis van elke Sprint Retrospective kent een hele simpele benadering. Het team moet instrumenten aangedragen krijgen om op een vrije en creatieve wijze over team samenwerking en de daarbij behorende verbeterpunten te kunnen praten.

Eerste Retrospectives

De eerste Sprint Retrospectives gingen uit van drie simpele vragen:

• Wat ging er goed?
• Ging er niet goed?
• Wat gaan we anders doen?

Deze vragen werden geïmporteerd uit het klassieke projectmanagement en leidden vaak tot proces gerichte oplossingen i.p.v. team verbeteringen. Op deze vragen kan je nog steeds terugvallen, met name als de verwachting bestaat dat processen verbetert kunnen worden. Er zijn een aantal nieuwe methodes waarvan ik de eenvoudigste Retrospective methode eerst behandel.

Eenvoudige Retrospective

De eenvoudigste Sprint Retrospective methode is dat elk teamlid aangeeft waarmee men moet:

• Starten om te gaan doen.
• Stoppen met te doen.
• Doorgaan met te doen.

De vorm varieert, maar deze methode levert concreet een ideeën lijst op. Zodra er een lijst is met brainstorm ideeën, stemt het team voor de belangrijkste items die meegenomen gaan worden in de komende Sprint. Je kan niet alle items meenemen, focus op één tot drie items. Deze plaatst men in de Sprint Backlog voor de komende Sprint.

Deze variant heb ik beschreven als de start, stop en go variant. (klik)

Retrospectives in 5 en 7 stappenplannen

Inmiddels zijn de Sprint Retrospectives gegroeid tot 5 en 7 stappen plannen.

Een grote gemene deler is beschreven door Esther Derby en Daine Larsen in het boek Agile Retrospectives uit 2006. Zij hanteren een 5 stappenplan.

5 stappenplan

• Set the stage. Zorg ervoor dat deelnemers in een de juiste stemming zijn zodra ze arriveren.
• Verzamel data. Help iedereen met het herinneren, creëer een gezamenlijk informatieplatform.
• Genereer inzichten. Waarom gebeuren de dingen zoals ze gebeurt zijn, herken patronen, zie het grote plaatje.
• Beslis wat te doen. Pak een paar issues om aan te werken en zorg voor concrete actieplannen en hoe je ze gaat opvolgen
• Sluit de Retrospective. Maak follow-up afspraken, waarderingen, zorg voor duidelijk einde en hoe de volgende retrospective verbetert kan worden.

Bovenstaande 5 stappenplan is een vaak gebruikte vorm.

6 en 7 stappenplan

Het 5 stappenplan is door Caroli en Caetano in 2015 in het boek Fun Retrospectives weer verder uitgewerkt. Hier gaat men uit van 6 stappen, Waarop Caroli  een 7 stappenplan heeft geïntroduceerd. Caroli gaat uit van Context, Prime Directive, Energizer, Check-in, Main Course, Filtering en de Check Out. Elke bedenker van een nieuwe Retrospective methode heeft een belangrijk inzicht ingebracht.

Wellicht de belangrijkste toevoeging van de nieuwere methodes de nadruk voor de vorm van de te voeren Sprint Retrospective. Een Scrum Master of Agile Coach kan veel bereiken met een Retrospective door te kiezen voor een goede vorm passend bij de situatie van het team. De vraag is: Welke behoefte heeft het team en welke Retrospective vorm heeft dan het meeste impact heeft op het team?

De eenvoudige Scrum Sprint Retrospective methode heeft zich inmiddels ontwikkelt tot een breed scala aan specifiek gerichte Retrospectives met verschillende doelen en gericht op de mate van volwassenheid van het team en/of specifieke issues.

Door de enorme toename aan Sprint Retrospectives worden er steeds meer varianten bedacht. Inmiddels zijn er tientallen, wellicht honderden varianten. De gereedschapskist van de Scrum Master of Agile Coach wordt niet alleen voller, maar ook wordt het gereedschap complexer. Een mooie uitdaging!

Tot slot!

Wat er in de Retrospective besproken is, blijft normaliter binnen het team.  De afgesproken actiepunten worden voor iedereen zichtbaar op het bord geplaatst en zijn dus voor iedereen open te lezen. Stakeholders en/of manager kan het team dus in gesprek gaan over de gemaakte afspraak.

Klik voor een voorbeeld van een retrospective.

Een retrospective over feedback? Lees dan het artikel ik-ik-jij feedback methode.

Het bericht Sprint Retrospective verscheen eerst op agile4all.

Voor de volledigheid een heel kort artikel over wat een Scrum Increment is.

Het Increment is de som van alle Product Backlog items voltooid in de huidige sprint en alle voorgaande Sprints en als geheel een (software) product vormt.

Waar moet een Increment aan voldoen?

Het is in bruikbare toestand aan het einde van de Sprint. De Product Owner zal vrijwel altijd deze in gebruik nemen, maar hij/zij is dit niet verplicht.

Voor het hoofdartikel van Scrum: Scrum Framework.

Het bericht Wat is een Scrum Increment? verscheen eerst op agile4all.