Agile werken -wat is dat?-

Wat is Agile werken?

Agile betekent letterlijk: behendig, lenig. In de IT staat het voor softwareontwikkeling in korte, overzichtelijke perioden van vaak niet meer dan een maand, soms zelfs hooguit een week. Deze perioden heten ‘iteraties’ of ‘Sprints’ .

Het voordeel van Agile werken is dat je na die kleine ‘iteraties’ direct feedback krijgt (Plan, Do, Check, Adjust) waardoor je echt kunt ontwikkelen wat de klant wil. Het is gedurende het hele ontwikkelproces voor iedereen transparant wat geleverd wordt door wie en heeft iedereen continu zicht op de voortgang waardoor je direct daarna weer kunt verbeteren.

Het doel van Agile werken is waarde te creëren met een snellere time2market met meer kwaliteit, meer engagement binnen de organisatie en een hogere productiviteit.

Het Agile manifesto gaat uit van waarde creatie door de volgende uitgangspunten te waarderen:

  • Individuen en interacties zijn belangrijker dan processen en tools
  • Werkende software is belangrijk dan uitgebreide documentatie
  • Klant samenwerking is belangrijker dat contract onderhandelingen
  • Reageren op wijzigingen is belangrijker dan het volgen van een plan

Of nader uitgewerkt:

  1. Onze hoogste prioriteit is om de klant tevreden te stellen door vroege en continue aflevering van waardevolle software
  2. Welkom veranderende eisen, zelfs laat in de ontwikkeling. Agile processen verwelkomen verandering vanwege concurrentievoordeel van de klanten
  3. Lever regelmatig werkende software, van een paar weken, met een voorkeur voor een kortere tijdschaal
  4. Mensen uit het bedrijfsleven en ontwikkelaars moeten dagelijks samen te werken gedurende het project
  5. Bouw je project rondom gemotiveerde individuen. Geef ze de omgeving en ondersteuning die ze nodig hebben en vertrouw hen om de klus te klaren
  6. De meest efficiënte en effectieve methode om informatie over te brengen binnen een development team is face-to-face gesprek
  7. Werkende software is de belangrijkste maatstaf voor de vooruitgang.
  8. Agile processen bevorderen van duurzame ontwikkeling. De sponsors, ontwikkelaars en gebruikers moeten in staat zijn om een constant te houdentempo voor onbepaalde tijd.
  9. Continue aandacht voor technische uitmuntendheid en een goed ontwerp verhoogt de wendbaarheid.
  10. Eenvoud; -the kunst van het maximaliseren van de hoeveelheid werk niet klaar- is essentieel.
  11. De beste architecturen, requirements en ontwerpen komen uit zelf- organiserende teams.
  12. Op gezette tijden reflecteert het team hoe ze effectiever worden, en past het gedrag dienovereenkomstig aan.

Onder Agile vallen een aantal frameworks, zoals SCRUM, Kanban, Extreme Programming (XP) en Lean. SCRUM is niet hetzelfde als Agile, maar is één van de manieren om het Agile gedachtegoed toe te passen. Elk framework heeft zijn eigen regels en richtlijnen om met het project om te gaan. Wat alle frameworks gemeen hebben, is dat er op een flexibele, overzichtelijke manier software ontwikkeld wordt.

Een van de belangrijke methoden van Agile werken is SCRUM en de basis hiervan wordt hier uitgelegd:

Scrum is een raamwerk voor het ontwikkelen en onderhouden van complexe (software) producten.

Scrum Overzicht

Scrum (n): een raamwerk waar binnen je de verschillende processen en technieken kunt inzetten.

Het Scrum raamwerk bestaat uit Scrum Teams en hun bijbehorende rollen, gebeurtenissen, artefacten en regels. Elk onderdeel binnen het raamwerk dient een specifiek doel en is essentieel voor het gebruik en succes van Scrum. De regels van Scrum verbinden de gebeurtenissen, rollen en artefacten met betrekking tot de interactie tussen hen.

Scrum Theorie

Scrum is gebaseerd op de theorie van empirische procesbesturing, ofwel het empirisme. Empirisme gaat er vanuit dat kennis ontstaat uit ervaring en het nemen van beslissingen op basis van wat bekend is. Scrum gebruikt een iteratieve, incrementele aanpak om voorspelbaarheid te optimaliseren en risico’s te beheersen.

Drie pijlers vormen het fundament van elke implementatie van empirische procesbesturing: transparantie, inspectie en aanpassing.

Transparantie

Significante aspecten van het proces moeten zichtbaar zijn voor diegenen die verantwoordelijk zijn voor het resultaat. Transparantie vereist dat deze aspecten gedefinieerd zijn volgens een gezamenlijke standaard zodat waarnemers een gezamenlijk begrip hebben van wat er gezien wordt. Bijvoorbeeld:

  • Een gemeenschappelijke taal met betrekking tot het proces moet door alle deelnemers worden gedeeld; en,
  • Een gemeenschappelijke definitie van “Klaar” (“Definition of Done”)1 moet worden gedeeld door degenen die het werk uitvoeren en degenen die het werkende product accepteren.

Inspectie

Scrum gebruikers moeten frequent de Scrum artefacten en de voortgang ten opzichte van het doel inspecteren, om ongewenste variantie te kunnen detecteren. Hun inspecties mogen niet zo frequent zijn dat de inspecties in de weg gaan zitten van het werk. Inspecties zijn het meest nuttig wanneer ze zorgvuldig worden uitgevoerd door vaardige inspecteurs, daar waar het werk gedaan wordt.

Aanpassing

Als een inspecteur bepaalt dat één of meer aspecten van een proces buiten de acceptabele limieten vallen en dat het resulterende product onacceptabel zal zijn, zal het proces of het onderhanden werk aangepast moeten worden. Een aanpassing moet zo snel mogelijk uitgevoerd worden om verdere afwijkingen te minimaliseren.

Scrum schrijft vier formele gelegenheden voor ten behoeve van inspectie en aanpassing, zoals beschreven in het Scrum Gebeurtenissen gedeelte van dit document:

  • Sprint Planning
  • Dagelijkse Scrum
  • Sprint Review
  • Sprint Retrospective

Het Scrum Team

Het Scrum Team bestaat uit een Product Owner, het Ontwikkelteam en een Scrum Master. Scrum Teams zijn zelforganiserend en multidisciplinair. Zelforganiserende teams kiezen zelf hoe zij het beste hun werk kunnen uitvoeren, in plaats van dat dit verteld wordt door iemand van buiten het team. Multidisciplinaire teams hebben alle competenties die nodig zijn om het werk uit te voeren, zonder afhankelijk te zijn van anderen buiten het team. Het team model in Scrum is ontworpen voor optimale flexibiliteit, creativiteit en productiviteit.

Scrum teams leveren iteratief en incrementeel producten, waarbij gelegenheden voor feedback gemaximaliseerd worden. Incrementele leveringen van een “Klaar” (Done) product zorgen ervoor dat een potentieel bruikbare versie van het product altijd beschikbaar is.

De Product Owner

De Product Owner is verantwoordelijk voor het maximaliseren van de waarde van het product en de werkzaamheden van het Ontwikkelteam. Hoe dit precies gedaan wordt verschilt enorm per organisatie, Scrum Team en individu.

De Product Owner is de enige persoon die verantwoordelijk is voor het managen van de Product Backlog. Product Backlog management omvat o.a.:

  • Helder omschrijven van Product Backlog items;
  • Ordenen van Product Backlog items, om doelen en missie op de beste manier te behalen;
  • Optimaliseren van de waarde van het werk dat het Ontwikkelteam uitvoert;
  • Ervoor zorgen dat de Product Backlog zichtbaar, transparant en duidelijk is voor iedereen,en dat het laat zien waar het Scrum Team als volgende aan gaat werken; en
  • Ervoor zorgen dat het Ontwikkelteam de Product Backlog items begrijpt tot het niveau datnodig is.De Product Owner kan het bovenstaande werk zelf uitvoeren, of het door het Ontwikkelteam laten doen. In elk geval blijft de Product Owner verantwoordelijk.De Product Owner is één persoon, geen comité. De Product Owner kan de wensen van een comité vertegenwoordigen via de Product Backlog, maar iedereen die een verandering wil in prioriteit van een Backlog Item, moet de Product Owner aanspreken.Om te kunnen slagen als Product Owner, moet de gehele organisatie zijn of haar beslissingen respecteren. De beslissingen van de Product Owner zijn zichtbaar in de inhoud en ordening van de Product Backlog. Niemand mag het Ontwikkelteam aan een andere set van requirements laten werken het en het Ontwikkelteam is het niet toegestaan te acteren op basis van wat iemand anders zegt.

Het Ontwikkelteam

Het Ontwikkelteam bestaat uit professionals die het werk doen om een potentieel uitleverbaar Increment van het “Klaar” (Done) product op te leveren aan het einde van elke Sprint. Alleen leden van het Ontwikkelteam creëren het Increment.

Ontwikkelteams zijn zodanig gestructureerd en voorzien van bevoegdheden door de organisatie dat zij hun eigen werk kunnen organiseren en beheren. De resulterende synergie optimaliseert de algehele efficiëntie en effectiviteit van het team.

Ontwikkelteams hebben de volgende karakteristieken:

  • Ze zijn zelfsturend. Niemand (zelfs de Scrum Master niet) vertelt het Ontwikkelteam hoe zij de Product Backlog moeten omzetten in Incrementen van potentieel uitleverbare functionaliteit;
  • Ontwikkelteams zijn multidisciplinair, met alle benodigde vaardigheden om als team een product Increment te kunnen maken;
  • Scrum erkent geen titels voor Ontwikkelteamleden anders dan Ontwikkelaar, ongeacht het werk dat door de persoon wordt uitgevoerd; er zijn geen uitzonderingen op deze regel;
  • Ontwikkelteams omvatten geen subteams die toegewijd zijn aan een specifiek domein zoalstesten of business analyse; er zijn geen uitzonderingen op deze regel; en,
  • Individuele Ontwikkelteamleden kunnen specifieke vaardigheden of focusgebieden hebben,maar verantwoordelijkheid ligt bij het Ontwikkelteam als geheel.

De Scrum Master

De Scrum Master is ervoor verantwoordelijk dat Scrum wordt begrepen en goed wordt uitgevoerd. Scrum Masters doen dit door ervoor te zorgen dat het Scrum Team zich houdt aan de Scrum theorie, praktijk en regels.

De Scrum Master is een dienend leider voor het Scrum Team. De Scrum Master helpt diegenen buiten het Scrum Team te begrijpen welke van hun interacties met het Scrum Team behulpzaam

zijn en welke niet. De Scrum Master helpt iedereen deze interacties te veranderen om zo de waarde die door het Scrum Team wordt gecreëerd te maximaliseren.

Scrum Master diensten aan de Product Owner

De Scrum Master dient de Product Owner op een aantal manieren, waaronder:

  • Het vinden van technieken voor een effectief Product Backlog management;
  • Het Scrum Team de noodzaak laten inzien om duidelijke en beknopte Product Backlog itemste maken;
  • Inzicht verkrijgen in de product planning in een empirische omgeving;
  • Ervoor zorgdragen dat de Product Owner weet hoe de Product Backlog te ordenen zodat demaximale waarde verkregen kan worden;
  • Inzicht verkrijgen in en het beoefenen van agility; en,
  • Het faciliteren van Scrum gebeurtenissen wanneer gevraagd of nodig.Scrum Master diensten aan het Ontwikkelteam

De Scrum Master dient het Ontwikkelteam op een aantal manieren:

  • Coachen van het Ontwikkelteam op het vlak van zelforganisatie en multidisciplinair werken;
  • Het Ontwikkelteam helpen bij het maken van producten van hoge waarde;
  • Het verwijderen van belemmeringen (‘impediments’) in de voortgang van hetOntwikkelteam;
  • Het faciliteren van Scrum gebeurtenissen wanneer gevraagd of nodig; en,
  • Het coachen van het Ontwikkelteam in organisatorische omgevingen waarbinnen Scrum nogniet volledig is opgenomen en begrepen.

Scrum Gebeurtenissen

Binnen Scrum worden voorgeschreven gebeurtenissen gebruikt om regelmaat te creëren en om de behoefte aan overige, niet in Scrum gedefinieerde bijeenkomsten te minimaliseren. Scrum maakt gebruik van timeboxes bij gebeurtenissen, zodat elke gebeurtenis aan een maximale tijdsduur is gebonden. Als een Sprint eenmaal begonnen is, is de duur niet meer aanpasbaar en kan dus niet ingekort of verlengd worden. De andere gebeurtenissen mogen eindigen zodra het doel van de gebeurtenis is bereikt, zodat de juiste tijd wordt gespendeerd aan planning zonder waardevermindering (“waste”) van het planning proces.

Anders dan de Sprint zelf, die een container is voor alle andere gebeurtenissen, is elke gebeurtenis in Scrum een formele gelegenheid om iets te inspecteren en aan te passen. Deze gebeurtenissen zijn specifiek ontworpen om kritieke transparantie en inspectie mogelijk te maken. Het niet opnemen van één van de deze gebeurtenissen resulteert in een vermindering van transparantie en is een gemiste kans voor inspectie en aanpassing.

De Sprint

Het hart van Scrum is een Sprint, een timebox van één maand of minder waarbinnen een “Klaar”, bruikbaar en potentieel uitleverbaar product Increment wordt gecreëerd. Sprints hebben idealiter een consistente lengte gedurende de ontwikkelinspanning. Een nieuwe Sprint start direct nadat de vorige Sprint is afgesloten.

Sprints bevatten en bestaan uit een Sprint Planningsbijeenkomst, Dagelijkse Scrums, het ontwikkelwerk, de Sprint Review en de Sprint Retrospective.

Gedurende de Sprint:

  • Worden geen veranderingen aangebracht die het Sprint Doel in gevaar kunnen brengen;
  • Verminderen kwaliteitsdoelstellingen niet; en,
  • Mag de scope worden verduidelijkt en heronderhandeld tussen Product Owner en Ontwikkelteam naarmate meer is geleerd. Elke Sprint mag worden beschouwd als een project met een horizon van niet meer dan één maand.

Sprints afbreken kost resources, want iedereen moet hergroeperen in een nieuwe Sprint Planning om een nieuwe Sprint te starten. Het Afbreken van een Sprint is vaak traumatisch voor het Scrum Team en komt zelden voor.

Sprint Planning

Het werk dat uitgevoerd moet worden tijdens een Sprint wordt gepland tijdens de Sprint Planning. Het maken van dit plan is een gezamenlijke inspanning van het gehele Scrum Team.

De Sprint Planningsbijeenkomst is een meeting binnen een timebox van acht uur voor een Sprint van één maand. Voor kortere Sprints is de bijeenkomst normaliter korter. De Scrum Master draagt er zorg voor dat deze gebeurtenis plaats vindt en dat de deelnemers het doel begrijpen. De Scrum Master leert het Scrum Team hoe ze het binnen de timebox kunnen afronden.

Sprint Planning beantwoordt de volgende vragen:

  • Wat kan worden geleverd in het resulterende Increment van de komende Sprint?
  • Hoe wordt het benodigde werk om dit Increment te leveren behaald? Onderwerp één: Wat kan worden gedaan deze Sprint? Onderwerp twee: Hoe wordt het gekozen werk gedaan?

Aan het einde van deze meeting heeft het team het werk voor de eerste dagen van de Sprint opgedeeld in eenheden, vaak van één dag of kleiner. Het Ontwikkelteam organiseert zichzelf om het werk in de Sprint Backlog gedaan te krijgen, zowel gedurende de Sprint Planning als gedurende de Sprint.

De Product Owner kan helpen om de geselecteerde Product Backlog items verder te verduidelijken en om afwegingen te maken. Indien het Ontwikkelteam bepaalt dat er te veel of te weinig werk is, mag het team over de Sprint Backlog items opnieuw onderhandelen met de Product Owner. Het Ontwikkelteam mag ook andere mensen uitnodigen om advies te leveren op technisch vlak of over het domein.

Sprint Doel

Het Sprint Doel is een doelstelling welke gesteld wordt voor de Sprint, welke kan worden behaald door het implementeren van de Product Backlog. Het geeft richting aan het Ontwikkelteam op het “waarom” het dit increment aan het bouwen is. Het wordt gecreëerd gedurende de Sprint Planning. Het Sprint Doel geeft het Ontwikkelteam de nodige flexibiliteit ten aanzien van de functionaliteit die geïmplementeerd wordt in de Sprint. De geselecteerde Product Backlog items leveren een samenhangende functie, wat het Sprint Doel kan zijn. Het Sprint Doel kan elke andere samenhang zijn die ervoor zorgt dat het Ontwikkelteam gaat samenwerken in plaats van aan verschillende initiatieven.

Tijdens het werken houdt het Ontwikkelteam het Sprint Doel in het oog. Functionaliteit en technologie worden geïmplementeerd om het Sprint Doel te bereiken. Indien het werk anders blijkt te zijn dan het Ontwikkelteam had verwacht, werken zij samen met de Product Owner om over de scope van de Sprint Backlog binnen deze Sprint te onderhandelen.

Dagelijkse Scrum

De Dagelijkse Scrum is een 15-minuten-timeboxed gebeurtenis voor het Ontwikkelteam om activiteiten te synchroniseren en een plan te maken voor de komende 24 uur. Dit wordt gedaan door het werk sinds de laatste Dagelijkse Scrum te inspecteren en te voorspellen welk werk gedaan kan worden tot de volgende Dagelijkse Scrum.

De Dagelijkse Scrum wordt elke dag gehouden op dezelfde tijd en plaats om complexiteit te reduceren. Gedurende de bijeenkomst licht elk Ontwikkelteamlid het volgende toe:

  • Wat heb ik gisteren gedaan dat het Ontwikkelteam heeft geholpen het Sprint Doel te bereiken?
  • Wat ga ik vandaag doen om het Ontwikkelteam te helpen het Sprint Doel te bereiken?
  • Zie ik enig obstakel die mij of het Ontwikkelteam in de weg staat het Sprint Doel tebereiken? Het Ontwikkelteam gebruikt de Dagelijkse Scrum om te voortgang ten opzichte van het Sprint Doel te beoordelen en om te beoordelen hoe de trend is van het gedane werk ten opzichte van de Sprint Backlog.

Sprint Review

Een Sprint Review wordt gehouden aan het einde van de Sprint om het Increment te inspecteren en indien nodig de Product Backlog aan te passen. Gedurende de Sprint Review bekijken het Scrum Team en de belanghebbenden samen wat er bereikt is gedurende de Sprint. Op basis hiervan en op basis van veranderingen in de Product Backlog, werken de aanwezigen samen aan de volgende stappen die genomen kunnen worden om waarde te optimaliseren. Dit is een informele bijeenkomst, geen status meeting, en de presentatie van het Increment heeft als doel feedback te verzamelen en samenwerking te bevorderen.

Dit is een vier-uur-timebox bijeenkomst voor Sprints van één maand. Over het algemeen wordt er minder tijd gepland voor kortere sprints. De Scrum Master draagt er zorg voor dat de gebeurtenis plaatsvindt en dat de aanwezigen het doel begrijpen. De Scrum Master leert iedereen om het binnen de timebox te houden.

De Sprint Review omvat de volgende elementen:

  • De aanwezigen zijn het Scrum Team en belangrijke belanghebbenden die worden uitgenodigd door de Product Owner.
  • De Product Owner identificeert welke Product Backlog items “Klaar” zijn en wat er niet “Klaar” is;
  • Het Ontwikkelteam bespreekt wat er goed ging gedurende de Sprint, welke problemen ze zijn tegengekomen en hoe deze problemen werden opgelost;
  • Het Ontwikkelteam demonstreert het werk dat “Klaar” is en beantwoordt vragen met betrekking tot het Increment;
  • De Product Owner bespreekt de Product Backlog zoals deze nu is. Hij of zij projecteert waarschijnlijke data van completering op basis van de voortgang tot nu toe (als nodig);
  • De gehele groep werkt samen aan wat er vervolgens gemaakt gaat worden, zodat de Sprint Review waardevolle input levert voor de komende Sprint Planningsbijeenkomst;
  • Een beoordeling van de markt of potentieel gebruik van het product kan beïnvloeden wat het meest waardevolle is om vervolgens te maken; en,
  • Een overzicht van de tijdlijn, budget, potentiele mogelijkheden, en markt voor de volgende verwachte ingebruikname van het product.Het resultaat van de Sprint Review is een herziene Product Backlog welke de waarschijnlijke Product Backlog items voor de volgende Sprint definieert. De Product Backlog kan ook over het geheel worden aangepast om nieuwe kansen te kunnen omarmen. 

Sprint Retrospective

De Sprint Retrospective is een kans voor het Scrum Team om zichzelf te inspecteren en een plan te maken om zichzelf gedurende de komende Sprint te verbeteren.

De Sprint Retrospective vindt plaats na de Sprint Review en vóór de volgende Sprint Planning. Dit is een drie-uur-timebox bijeenkomst voor Sprints van één maand. Over het algemeen wordt minder tijd gepland voor kortere sprints. De Scrum Master draagt er zorg voor dat de gebeurtenis plaatsvindt en dat de aanwezigen het doel begrijpen. De Scrum Master leert iedereen om het binnen de timebox te houden. De Scrum Master neemt deel als een gelijkwaardig teamlid aan de bijeenkomst vanuit zijn verantwoordelijkheid voor het Scrum proces.

Het doel van de Sprint Retrospective is om:

  • Te inspecteren hoe de laatste Sprint is gegaan met betrekking tot mensen, relaties, processen en tools;
  • Dingen die goed gingen en potentiële verbeteringen te identificeren en te ordenen; en,
  • Een plan te creëren om verbeteringen op de manier waarop het Scrum Team zijn werk doet te implementeren.