Scrum / Agile

Scrum is een raamwerk voor het ontwikkelen en onderhouden van complexe producten. De definitie van Scrum bestaat uit de Scrum rollen, gebeurtenissen, lijsten en de regels die deze zaken samenbrengen. Ken Schwaber en Jeff Sutherland hebben Scrum ontwikkeld.

Ken Schwaber is geboren in 1945 USA en hij is afgestudeerd in 1967 aan de US Merchant Marine Academy. Hij is eigenaar van scrum.org en hij is mede-ondertekenaar van het Agile Manifesto wat de basis is voor het scrum raamwerk. Ken heeft het scrumboek “Software in Thirty Days” geschreven.

Jeff Sutherland is geboren in 1941 en hij is afgestudeerd aan de United  States Military Academy als Top Gun vliegtuig commandant. Hij heeft gevochten als piloot tijdens de Vietnam oorlog. Sutherlans is mede-ondertekenaar van het Agile Manifesto. Jeff heeft de Scrum strategie aangepast voor niet software industrieën zoals Financiën, Gezondheidszorg, Onderwijs en Telecom.

Definitie van Scrum
Een raamwerk waarbinnen mensen complexe, adaptieve problemen adresseren en tegelijkertijd op een productieve en creatieve wijze producten van de hoogst mogelijk waarde leveren.

Scrum is:

• Lichtgewicht
• Simpel om te begrijpen
• Moeilijk om te leren beheersen

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
• Aanpassing

Transparantie
• Een gemeenschappelijke taal met betrekking tot het proces moet door alle deelnemers worden gedeeld;
• Een gemeenschappelijke definitie van “Klaar” (Definition of Done) 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.

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:

• Sprint Planning (Max 2 x 4 = 8 uur)
• Dagelijkse Scrum (Max 15 min)
• Sprint Review (Max 4 uur)
• Sprint Retrospective(Max 3 uur)

Scrum Waarden CCFOR

• Inzet, (Commitment)
• Moed,  (Courage)
• Focus, (Focus)
• Openheid (Openness)
• Respect (Respect)

Het Scrum Team bestaat uit :

• Product Owner,
• Ontwikkelteam
• Scrum Master.

Scrum Teams zijn zelf-organiserend en multidisciplinair.

De Product Owner
De Product Owner is verantwoordelijk voor het maximaliseren van de waarde van het product en de werkzaamheden van het Ontwikkelteam. De Product Owner is de enige persoon die verantwoordelijk is voor het managen van de Product Backlog.

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

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.

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.

De Sprint
Het hart van Scrum is een Sprint, een timebox van één maand of minder waarbinnen een “Done”, bruikbaar en potentieel uitleverbaar product Increment wordt gecreëerd.

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.

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.

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?

Daily Scrum
De Daily 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.

• Wat heb ik gisteren gedaan
• Wat ga ik vandaag doen
• Waar ben ik tegenaan gelopen

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.

De presentatie van het Increment heeft als doel feedback te verzamelen en samenwerking te bevorderen. Het is een vier-uur-timebox bijeenkomst bij Sprints van één maand.

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.

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;
• Een plan te creëren om verbeteringen op de manier waarop het Scrum Team zijn werk doet te implementeren.

Scrum lijsten/ bestanden (Artefacten)
De lijsten van Scrum vertegenwoordigen werk of waarde die transparantie bieden en mogelijkheden tot inspectie en adaptie. De artefacten die Scrum definieert zijn specifiek ontworpen voor maximale transparantie van sleutelinformatie zodat iedereen hetzelfde begrip heeft van het artefact.

1. Product Backlog
2. Sprint Backlog

Product Backlog
De Product Backlog is een geordende lijst van alles dat mogelijk nodig is in het product, en is de enige bron van requirements voor elke wijziging die aan het product gemaakt moeten worden. De Product Owner is verantwoordelijk voor de Product Backlog, inclusief de inhoud, beschikbaarheid en ordening.

De Product Backlog somt alle kenmerken, functies, requirements, verbeteringen en foutherstel op die gezamenlijk de wijzigingen zijn die in toekomstige releases aan het product gemaakt moeten worden. Product Backlog items hebben als kenmerken een beschrijving, ordening, een schatting en een waarde.

Product Backlog Refinement
Product Backlog verfijning (“Refinement”) is het toevoegen van detail, schattingen en volgorde aan de items op de Product Backlog. Dit is een doorlopend proces waarbij de Product Owner en het Ontwikkelteam samenwerken aan de details van de Product Backlog items. Gedurende Product Backlog Refinement worden items beoordeeld en bijgewerkt. Refinement neemt gewoonlijk niet meer dan 10% van de capaciteit van het Ontwikkelteam in beslag. Echter, Product Backlog Items kunnen op elk moment worden bijgewerkt door de Product Owner en naar de Product Owner‘s eigen beoordeling.

Release Burn Down (niet officieel)
Op elk moment in de tijd kan het totale werk, dat nog nodig is om een doel te bereiken, worden opgeteld. De Product Owner houdt de totale resterende hoeveelheid werk bij, op zijn minst elke Sprint Review.

Sprint Backlog
De Sprint Backlog is de verzameling Product Backlog items geselecteerd voor de Sprint inclusief het plan voor opleveren van het product Increment en voor realisatie van het Sprint Doel. De Sprint Backlog is een voorspelling door het Ontwikkelteam over de functionaliteit die aanwezig zal zijn in het volgende Increment en het werk dat nodig is om die functionaliteit te leveren in een “Done” Increment.

Sprint Burn Down (niet officieel)
Op elk moment in de Sprint kan de totaal resterende hoeveelheid werk voor de Sprint Backlog items worden opgeteld. Het Ontwikkelteam houdt dit totaal minstens voor elke Dagelijkse Scrum bij om de waarschijnlijkheid van het halen van het Sprintdoel te projecteren. Door het bijhouden van de resterende hoeveelheid werk gedurende de Sprint kan het Ontwikkelteam haar voortgang bewaken.

Increment
Het Increment is het totaal van alle Product Backlog items voltooid tijdens een Sprint en de opgeleverde waarde van de Incrementen van alle voorgaande Sprints. Aan het eind van een Sprint moet het nieuwe Increment “Done” zijn, wat betekent dat het in bruikbare toestand is en voldoet aan de Definitie van “Done” gebruikt door het Scrum Team. Het moet in bruikbare conditie zijn ongeacht of de Product Owner daadwerkelijk besluit het in gebruik te nemen.

Definition of "Done"
Indien een Product Backlog item wordt omschreven als “Done (Klaar)”, moet iedereen begrijpen wat “Done” betekent. Hoewel dit significant verschilt per Scrum Team, moeten de teamleden een gezamenlijk begrip hebben wat het betekent om het werk af te hebben, om transparantie te kunnen garanderen. Deze “Definition of Done” voor het Scrum Team wordt gebruikt om te controleren wanneer het werk voor een product Increment klaar is.

Manifest voor Agile Software Development
De vier waarden van Agile:

Individuen en interacties boven processen en tools
Werkende software boven uitgebreide documentatie
Klantensamenwerking boven contractonderhandelingen
Reageren op verandering boven het volgen van een plan

Hoewel er waarde is in de items aan de rechterkant, waarderen we de items aan de linkerkant meer.

12 Principes achter het Agile Manifest

1. Onze hoogste prioriteit is om de klant tevreden te stellen door vroege en continue levering van waardevolle software.

2. Verwelkom veranderende eisen, zelfs laat in ontwikkeling. Agile processen benutten veranderingen voor het concurrentievoordeel van de klant.

3. Lever vaak werkende software op, van een paar weken tot een paar maanden, met een voorkeur voor het kortere tijdsschema.

4. Mensen uit het bedrijfsleven en ontwikkelaars moeten tijdens het project dagelijks samenwerken.

5. Bouw projecten rond gemotiveerde individuen. Geef ze de omgeving en ondersteuning die ze nodig hebben en vertrouw erop dat ze de klus voor elkaar krijgen.

6. De meest efficiënte en effectieve methode voor het overbrengen van informatie naar en binnen een ontwikkelteam is een face-to-face gesprek.

7. Werkende software is de primaire maatstaf voor vooruitgang.

8. Agile processen bevorderen duurzame ontwikkeling. De sponsors, ontwikkelaars en gebruikers moeten een constant tempo onbeperkt kunnen handhaven.

9. Continue aandacht voor technische uitmuntendheid en een goed ontwerp verbeteren de wendbaarheid.

10. Eenvoud - de kunst van het maximaliseren van de hoeveelheid werk die niet is gedaan - is essentieel.

11. De beste architecturen, vereisten en ontwerpen komen voort uit zelforganiserende teams.

12. Op regelmatige tijdstippen reflecteert het team hoe het effectiever kan worden, stemt het vervolgens af en past het zijn gedrag daarop aan.