Wat is Agile Scrum Methodologie?

Wat is Agile?

Als reactie op de klassieke waterval-ontwikkelmethode die ervaren werd als bureaucratisch, traag en bekropen heeft men in 2001 een nieuw manifest ontwikkeld. Het resultaat was het Agile Manifest:

1. Mensen en interactie zijn belangrijker dan processen en tools,
2. Werkende software is belangrijker dan uitgebreide documentatie,
3. Samenwerking is belangrijker dan contractonderhandelingen en
4. Reageren op veranderingen is belangrijker dan een plan volgen.

Waarom Agile?

Agile wordt vooral toegepast in situaties die heel herkenbaar zijn bij het ontwikkelen van software, namelijk:

• De vereisten of de details van de volledige scope van het project zijn nog niet geheel duidelijk.
• Bedrijfsprocessen veranderen snel of evolueren continue.
• Waarbij budgetten voor nieuwe ontwikkelingen pas vrijkomen na bewezen winst van voorgaande modules.
• Waarbij nieuwe functionaliteit live zetten belangrijker is dan het hebben van alle toeters en bellen.

Hoe past Scrum in het Agile ontwikkelingsverhaal?

Terwijl de Agile methodologie kan toegepast worden op product ontwikkeling en zich niet enkel beperkt tot software ontwikkeling, is Scrum speciaal ontwikkeld voor software ontwikkeling.

Scrum is een flexibele manier om softwareproducten te maken. Er wordt gewerkt in multidisciplinaire teams die in korte sprints, met een vaste lengte van 1 tot 4 weken, werkende software opleveren. Scrum is een term die afkomstig is uit de rugbysport. Bij een scrum probeert een team samen een doel te bereiken en de wedstrijd te winnen. Samenwerking is heel belangrijk en men moet snel kunnen inspelen op veranderende omstandigheden.

Hoe gaat Scrum in zijn werk?

Tijdens iedere sprint is het essentieel dat deze constant blijft, de vooropgestelde planning en prioriteiten gevolgd worden. Alles wat na de sprint gebeurd staat volledig ter discussie en alles wat ontstaat tijdens die 2 weken kan best wachten tot wanneer die sprint afgelopen is. Zijn dit waardevolle punten dan komen ze bovenaan de lijst voor de volgende sprint.

2 lijsten: Product backlog & Sprint backlog

Product backlog

De product backlog is een overzicht van de items die nog gedaan moeten worden. Dit wordt in andere software ontwikkelmethoden wel de requirements genoemd, de eisen en wensen. Het bestaat uit alles wat van belang is om mee te nemen in de sprint zoals eigenschappen, fouten uit vorige releases, niet functionele eisen zoals navigatie, kleur, “look and feel”, snelheidseisen etc. De product-owner is de eigenaar van deze lijst en bepaalt de volgorde. In principe staan de belangrijkste bovenaan, maar ook een andere volgorde is mogelijk. Hierbij spelen zaken als risico, waarde voor de organisatie, datum waarop iets nodig is, wettelijke eisen, etc. De zaken op de lijst zijn normaal gesproken in de vorm van een user story. Hierin staat WAT er gemaakt moet worden WAAROM en voor WIE. Iedereen kan er items aan toevoegen, maar de product-owner is en blijft verantwoordelijk. Er staan ook ruwe schattingen bij van de waarde voor de organisatie en van de ontwikkelkosten.

Sprint backlog

In de sprint backlog staat wat er deze sprint wordt gedaan. De sprint backlog wordt samengesteld uit de bovenste items van de product backlog. Het ontwikkelteam bepaalt wat ze kunnen doen gebaseerd op hun snelheid in de vorige sprints. Gebruikelijk is dat de items op de sprint backlog geschreven worden op post-its. Er zijn dan drie kolommen, “to do”, “in progress”, “done”. Soms met een vierde kolom “testing”. Zodoende is voor iedereen duidelijk hoe het ermee staat. Het ontwikkelteam bepaalt zelf wie wat doet, of eigenlijk kiezen de leden zelf wat ze (kunnen en willen) oppakken van de todo-lijst. Dit bevordert dat het team zich ermee verbonden voelt, dat ze zich er voor willen inzetten, dat het hun product wordt. Er kunnen na de start geen items meer toegevoegd worden aan de sprint, behalve door het ontwikkelteam zelf. Nadat de sprint klaar is wordt de product backlog nog eens tegen het licht gehouden en kunnen prioriteiten en dus de volgorde wijzigen.

3 rollen: Product-Owner, Ontwikkelteam, Scrummaster

Product-owner

De Product-owner (product eigenaar) is de opdrachtgever / klant. Hij heeft het meeste belang bij het (software)product dat gemaakt wordt. Hij zorgt dat de rekening betaald wordt. Hij beheert ook de product backlog, hij bepaalt wat er moet gebeuren en in welke volgorde. In principe wordt begonnen met het belangrijkste, waar het meeste voordeel mee te behalen is, wat boven aan de product backlog staat.

Ontwikkelteam

Het ontwikkelteam is multidisciplinair samengesteld en is verantwoordelijk voor het afleveren van het (software)product aan het einde van elke sprint. Het team bestaat meestal uit 3 tot 9 personen. Het team organiseert zichzelf. Zij doen de analyse, ontwerp, ontwikkeling, test en documentatie en zorgen dat er aan het eind van de sprint een kant en klaar product is, dat in principe in productie genomen kan worden.

Scrum master

De scrum master begeleidt / helpt het team door te zorgen dat het juiste scrum proces gevolgd wordt. Hij verzorgt ook eventuele trainingen. De scrum master regelt alle vergaderingen. Hij regelt de voorzieningen zoals een werkruimte, hardware en software. De scrum master zorgt ervoor dat het team niet lastig gevallen wordt door derden die met extra eisen tussendoor komen of die bijvoorbeeld tijdelijk mensen nodig hebben uit het team.

4 Meetings: Sprint Planning, daily Scrum, sprint review, sprint retrospective

Sprint Planning

Aan het begin van de sprint is er een sprint planning overleg. In principe worden de bovenste, belangrijkste user-stories van de product backlog in de sprint opgenomen. Het is cruciaal dat het ontwikkelingsteam de user-stories kiest die worden opgenomen, omdat zij degene zijn die zich engageren om de onderliggende taken uit te voeren. Daarom bepalen ook zij hoeveel werk kan worden opgenomen in de betreffende sprint en zijn tevens verantwoordelijk voor de inschatting van de hoeveelheid werk per user-story.

Daily scrum

Elke dag is er de “Daily scrum” of “Stand-up”. Deze vergadering heeft de volgende richtlijnen:

• Alle leden van het ontwikkelteam hebben zich voor de vergadering voorbereid.
• De vergadering start precies op tijd, ook als niet iedereen aanwezig is.
• De vergadering is elke dag op precies dezelfde tijd en plaats, meestal 9:00 uur in de projectkamer.
• De vergadering duurt maximaal 15 minuten.
• Bezoekers zijn welkom maar normaal gesproken spreken alleen de leden van het ontwikkelteam, de scrummaster en product-owner.
• Men houdt een rondje waarbij elk teamlid drie vragen beantwoordt:
  • Wat heb je gedaan?
  • Wat ga je doen?
  • Zie je ook problemen/uitdagingen, heb je hulp nodig, zijn er dingen die voor andere teamleden van belang zijn?

Sprint review

Na elke sprint wordt er een sprint review meeting gehouden, hierbij toont het team wat zij verwezenlijkt hebben tijdens de sprint. Normaal gezien gaat dit gepaard met een demo van de nieuwe functionaliteiten. Hierbij worden alle punten nog eens afgetoetst met wat vooropgesteld werd tijdens de sprint planning. Deelnemers van zo’n sprint review zijn de product owner, ontwikkelteam, de scrum master en management.

Sprint retrospective

Het maakt niet uit hoe goed je Scrum team is, er is altijd ruimte voor verbetering. Daarom dat er na de sprint review nog eens samengezeten wordt met het team waarbij de Scrum master aan elk lid vraagt wat het team zou moeten doen, stoppen met doen of blijven verder doen.