Scrum methode: waarom het werkt.​

Wat is Scrum?

Scrum is een methodiek die gebaseerd is op de Agile filosofie. Het is een raamwerk dat is gemaakt om de Agile filosofie handvatten te geven in de dagelijkse projectomgeving.

Agile manifesto

Wat volgt is een citaat uit het Agile manifesto, vertaald door Google, met hier en daar wat aanpassingen om het weer leesbaar te maken: “Marketing, management, externe klanten, interne klanten en ontwikkelaars willen geen lastige afwegingen maken, dus leggen ze irrationele eisen op door het opleggen van collectieve machtsstructuren. Dit is niet alleen een probleem in de software industrie, het geldt voor veel logge organisaties in uiteenlopende industrieën.

Om succesvol te zijn in de nieuwe economie en om een plek te bemachtigen in het tijdperk van e-business, e-commerce en het web, moeten bedrijven zich ontdoen van hun vaste structuur van overbodig werk creëren en geheimzinnige beleidsvoering. Deze vrijheid van de onbenulligheden van het bedrijfsleven trekt voorstanders van Agile methodologieën aan. De benaderingen van Agile schrikken corporate bureaucraten af – in ieder geval degene die procesmatig werken puur om procesmatig te werken, versus proberen het beste te doen voor de ‘klant’ en iets tijdig en tastbaar leveren ‘zoals beloofd’.

Samengevat
De Agile filosofie zegt in oorsprong dat individuen en interacties belangrijker zijn dan processen en tools, dat werkende software belangrijker is dan uitgebreide documentatie, dat samenwerking met de klant belangrijker is dan contractonderhandelingen en dat reageren op verandering belangrijker is dan het volgen van een plan.

Dus, onze overtuiging is duidelijk. Voordat we verder ingaan op Scrum maken we een vergelijking tussen één van de traditionele modellen; de watervalmethode en Agile.

Verschillende methodes

Waterval methode

Agile wordt vaak vergeleken met de ‘watervalmethode’. Bij gebruik van de watervalmethode wordt, voordat aan de ontwikkeling van het project begonnen mag worden, een projectplan opgesteld en goedgekeurd met daarin het volledige proces uitgedacht en gedocumenteerd.

Deze documentatie komt tijdens de realisatiefase wel aan bod, maar is dan niet van het hoogste belang. Verder komt tijdens de realisatiefase voor het grootste deel alleen het ontwikkeltraject ter sprake. Onder dit ontwikkeltraject valt de design-, codeer- en testfase. Wanneer alles is goedgekeurd wordt het project afgeleverd. Hierna wordt doorlopende support geleverd.

De watervalmethode kan een goede methode wanneer een proces gedigitaliseerd wordt dat al lang en breed bekend is. Bijvoorbeeld een deel van de klantenservice die wordt vervangen door een klantportaal, waarin klanten zelf antwoorden kunnen vinden over hun orders en facturen. 

Agile

Agile is een manier van ontwikkelen waarbij de klant na iedere sprint (een korte periode waarin een gelimiteerd aantal functionaliteiten worden gepland, ontwikkeld en getest) op de hoogte wordt gesteld van de huidige status. Dit schept een moment voor een demonstratie van de nieuwe functionaliteiten, waardoor de klant kan zien hoe het werkt. Het gebeurt vaak dat zodra de functionaliteit daadwerkelijk bestaat, de applicatie niet blijkt te werken zoals de klant het voor ogen had – of juist dat hoe hij het in zijn hoofd had, niet de optimale manier is.

Door na iedere sprint een feedback moment te hebben, kunnen deze punten snel geïdentificeerd worden en kan er een passende oplossing voor worden bedacht. In tegenstelling tot het tegenkomen van deze problemen aan het einde van het traject zoals bij gebruik van de watervalmethode.

Agile is een goede methode wanneer een nieuw online concept of business wordt ontwikkeld. Bijvoorbeeld in de vorm van een app of platform, waarbij de precieze invulling van functionaliteiten vooraf niet bekend is. Het zijn applicaties die gaandeweg door gebruikers en door middel van feedback doorontwikkeld worden.  

De Scrum methode

Schwabber en Sutherland, grondleggers van Scrum, zeggen: “Scrum is een raamwerk waarin mensen complexe problemen aan kunnen pakken, terwijl ze producten van de hoogst mogelijke waarde leveren”. Daarom hebben wij bij Scrumble voor Scrum gekozen als ontwikkelingsmethodiek. Scrum is gebaseerd op de empirische filosofie, die zegt dat “kennis voortkomt uit ervaring en beslissingen neemt op basis van wat bekend is.” De empirische controlepijlers voor processen zijn hieronder beschreven.

“Scrum is een raamwerk waarin mensen complexe problemen aan kunnen pakken, terwijl ze producten van de hoogst mogelijke waarde leveren”

De belangrijkste pijlers van het Scrum proces

Transparantie: transparantie betekent dat alle belanghebbenden betrokken zijn bij het proces, dat alle betrokkenen verondersteld worden te weten wat er gaande is en wat er gaat gebeuren.

Inspectie: Scrum-artefacten moeten regelmatig worden geïnspecteerd om problemen proactief te detecteren.

Aanpassing: alle aspecten van het proces die afwijken van aanvaardbare limieten moeten zo snel mogelijk worden aangepast. Scrum schrijft vier formele evenementen voor inspectie en aanpassing voor: Sprint Planning, Daily Scrum, Sprint Review en Sprint Retrospective.

Hoe werkt Scrum?

Scrum wordt uitgevoerd door samen te werken met een klantvertegenwoordiger; een ‘Product Owner’. De Product Owner is, in tegenstelling tot traditionele projectbenaderingen, onderdeel van het Scrum-ontwikkelingsteam. Naast dat de Product Owner zijn of haar organisatie vertegenwoordigd, verdedigd hij of zij ook de belangen van de eindgebruiker.

Scrum is een iteratief proces; het werk wordt gedaan in ‘sprints’ die zich continu herhalen. Een sprint is een in principe een ‘blok’ werk. De omvang van een sprint wordt bepaald in de Sprint Planning aan het begin van iedere sprint. Tijdens de Sprint Planning wordt samen met de Product Owner bepaald welke features worden uitgewerkt. Elk van deze sprints heeft zijn deadline waarop de sprint wordt beoordeeld. Dit schept ruimte om kennis en vaardigheden te verbeteren en van feedback te leren.

Scrum terminologie

Om nog een stap verder te duiken en de terminologie juist te krijgen, verwijzen we naar bovenstaande afbeelding. Men gebruikt de term Product Backlog voor alle features die nodig zijn om het product te realiseren. In het ideale geval wordt alle gewenste functionaliteiten door de Product Owner omgezet in User Stories en voorafgaand aan het project in de Product Backlog geplaatst.

Epics en User Stories
De features worden over het algemeen onderverdeeld in Epics en User Stories, waarbij Epics de overkoepelende term is voor een groter geheel aan User Stories. User Stories helpen de focus te verschuiven van het schrijven over eisen naar doelen en redenen. Dit opent de mogelijkheid tot reflectie en helpt zo met het realiseren van doeltreffende resultaten. User Stories zijn korte, eenvoudige beschrijvingen van een feature die wordt verteld vanuit het perspectief van de persoon die de nieuwe mogelijkheid wenst, meestal de gebruiker van het systeem. Ze volgen een eenvoudige structuur: ‘als een wil ik zodat .’

“User Stories helpen de focus te verschuiven van het schrijven over eisen naar het aanduiden van doelen en redenen.”

 

Voorbeeld Epics en User stories
Een voorbeeld van de combinatie van Epic en User Stories voor Marktplaats zou kunnen zijn: Epic: ‘zoekfunctie’ User Story 1: ‘als een gebruiker wil ik kunnen zoeken in verschillende categorieën zodat ik alleen de juiste soort producten te zien krijg.’ User Story 2: ‘als een gebruiker wil ik zoekresultaten kunnen filteren op productkenmerken zodat ik sneller kan vinden waar ik naar op zoek ben.’

Sprint Planning en Daily Standups 
Tijdens de Sprint Planning worden User Stories uit de Product Backlog geselecteerd voor de Sprint Backlog. Deze worden vervolgens ingeschat om aan te werken tijdens de Sprint. Hierna volgt uitvoering van een sprint, waarbij het team begint aan de Sprint Backlog taken van de sprint, welke op hun beurt weer voortvloeien uit User Stories. Een ‘Daily Standup’ is een korte vergadering waarin het team de uitvoeringsfase kan sturen en iedereen op de hoogte kan houden van wat er gisteren is gedaan en wat waar de volgende dag aan gewerkt gaat worden.

Demo, Sprint Review en Retrospective
Tot slot wordt er aan het einde van de sprint een Demo gedaan, waarbij er de mogelijkheid is om de uitgewerkte User Stories te demonstreren en feedback te verzamelen (Sprint Review). Tijdens de Retrospective na iedere sprint wordt vervolgens gereflecteerd op de samenwerking tijdens de sprint, om zo een optimaal process te waarborgen.

Waarom wij kiezen voor Scrum

Het belangrijkste aan Scrum vinden wij de transparante samenwerking. Transparantie is aanwezig als het proces goed wordt gevolgd. Per sprint worden vooraf gedefinieerde features bepaald en continu inzichtelijk uitgewerkt. Je weet dus altijd waar we mee bezig zijn en hoe lang we met features bezig zijn.

Tevens vinden we het samenwerkingsaspect met een Product Owner fantastisch werken. Samenwerking betekent precies wat het woord zegt; jij komt in ons midden. Succesvolle software ontwikkel je namelijk samen. Jij bent tenslotte degene met het marktinzicht, toch? Door middel van juiste argumentatie besluiten we samen de richting voor de sprints. Gewoon doen wat er gevraagd wordt levert namelijk nooit het beste resultaat op.

Meer weten? Vincent helpt je graag verder.

Meer lezen over digitalisering en software ontwikkeling?

Hier vind je de meest recente artikelen.

12345