De werkwijze van Development: van wens tot oplossing met Scrum

De werkwijze van Development: van wens tot oplossing met Scrum

Ben je op zoek naar iets nieuws en vind je het belangrijk om in een omgeving te werken waarin samenwerking en ontwikkeling centraal staat, zoek dan niet verder. Mogelijk zegt de term Scrum je al iets en mogelijk klinkt het nog als een ver-van-mijn-bed-show. Het is het hippe broertje van de Waterval methode, waarbij eerst alle informatie verzameld en geanalyseerd wordt, dan een design gemaakt wordt die uiteindelijk door jou als developer wordt verwezenlijkt. Echter, niets is zo veranderlijk als de werkelijkheid, zeker in de telecom. Als Development afdeling hebben we de sprong in het diepe gewaagd en voor Scrum gekozen om het beste uit onszelf en onze stakeholders te kunnen halen. Wat Scrum is en wat de werkwijze is waar jij mogelijk in terecht kan komen lees je hieronder.

Van toen tot nu

Lang, lang geleden liep het storm op de Development afdeling. Voor elke vraag en elk probleem kon een collega aan je bureau gaan staan. Hoewel face-to-face contact en snel afstemmen heel waardevol kan zijn, brengt het ook gevaren met zich mee. Je legt je werk neer, stort je vol overgave in het oplossen van de bug om vervolgens weer terug te switchen naar waar je gebleven was. Het was rommelig en in een alsmaar groeiende organisatie voor developers niet langer houdbaar om van de hak op de tak te blijven springen. Kortom, er moest iets veranderen en met de keuze voor Scrum is de weg ingeslagen om meer structuur en samenwerking te brengen. In de komende paragrafen zien we hoe we de vruchten plukken van dit nieuwe proces.

De wens in kaart brengen

Allereerst moest er een manier komen om laagdrempelig wensen of problemen aan te kaarten. Met JIRA is er software gekomen waarbij collega’s op werk of vanuit huis relatief eenvoudig een ticket in kunnen dienen. Deze tickets komen bij ons binnen als verbeteringen en vervolgens gaat een van onze Product Owners (Martijn, Ruben of Kim) met stakeholders om tafel zitten om de wens - of dat nu een bug of een nieuwe feature is - duidelijk in kaart te brengen, zodat developers er mee uit de voeten kunnen.

De Product Owner

De Product Owner staat middenin de organisatie. Niet alleen zorgt hij of zij er voor dat de wens vanuit de stakeholder duidelijk uitgewerkt is, maar ook wordt de prioriteit ten opzichte van andere punten bepaald. Dat is een belangrijke en soms ook lastige taak, omdat de Product Owner steeds de afweging moet maken hoe en wanneer alle waardevolle wensen vanuit de organisatie het beste opgepakt moeten worden. Na uitwerking komt een JIRA-story in de Product Backlog van een van de teams terecht waarbij de Product Owner prioriteit heeft aangebracht. Tijdens de Sprint Planning worden de punten toegelicht zodat developers er mee aan de slag kunnen gaan.

De Sprint Planning

Als de wensen vanuit de organisatie bekend, geprioriteerd en toegelicht zijn is het de beurt aan de developers om te bepalen hoe de wens technisch in vervulling kan worden gebracht. Dit is onderdeel van de Sprint Planning, waarbij wordt bepaald hoeveel werk opgeleverd kan worden in een periode van 2 weken, de Sprint. Voor elke JIRA-story wordt geschat hoeveel werk het ongeveer kost om de bug op te lossen of de feature op te leveren. Het kan zijn dat we stakeholders ook een uitnodiging sturen als er nog extra uitleg nodig is voor de ingediende punten. Tot slot wordt een doel opgesteld, waarin geformuleerd wordt wat we over 2 weken bereikt hopen te hebben.

De Sprint

De Sprint is een periode van 2 weken waarin de uitgedachte JIRA-stories daadwerkelijk tot leven worden gebracht in onze codebase. Gedurende deze periode wordt elke dag een Daily Standup van maximaal 15 minuten gehouden waarin developers elkaar op de hoogte stellen van hun voortgang en bepalen of het beoogde doel van de Sprint nog haalbaar is. Het kan ook voorkomen dat we stakeholders vragen stellen over de precieze functionaliteit die gevraagd wordt in een JIRA-story of om in de testomgeving te controleren of alles werkt. Als het helemaal duidelijk is en jij de code van de zo vurig gewenste feature hebt geschreven is het tijd om deze te laten testen in een testomgeving. Natuurlijk werkt jouw code gelijk als een zonnetje en kan je in samenspraak met de Product Owner de feature live zetten zodat iedereen de vruchten van je werk kan plukken.

De Sprint Review

De Sprint Review is een moment waarop het Scrum Team aan stakeholders demonstreren wat we in de afgelopen 2 weken aan werk opgeleverd hebben. Dit is ook het moment waarop vragen gesteld kunnen worden over de opgeleverde features en een moment om vooruit te blikken op wat er de komende 2 weken nog komen gaat. Op deze manier is iedereen op de hoogte van wat er gedaan is en welke richting we op bewegen.

De Sprint Retrospective

Niet elke Sprint verloopt vlekkeloos. Soms komen er urgente zaken tussen, zijn punten complexer dan gedacht of ligt er een andere oorzaak aan ten grondslag dat de zon achter de horizon verdwijnt. Soms is het overmacht, maar soms ook niet. Het geeft niet dat er wel eens iets mis kan gaan, maar het geeft wel als er geen lering uit getrokken wordt. De Sprint Retrospective is het uitgelezen moment om met het Scrum Team terug te blikken op de afgelopen 2 weken om te kijken hoe de volgende Sprint (nog) beter kan dan de voorgaande. In een vertrouwde omgeving kritisch naar jezelf en anderen durven kijken is belangrijk. En zeg nu zelf, is het niet enorm motiverend als je merkt dat jij en je collega’s door deze momenten van reflectie steeds weer stappen vooruit zetten?

De Scrum Master

De Product Owner en developers zijn al aan bod gekomen, maar ook de Scrum Master is onderdeel van het Scrum Team. Het is aan hem of haar om er voor te zorgen dat voor iedereen duidelijk is uit welke onderdelen Scrum bestaat en te coachen of faciliteren bij de toepassing ervan waar nodig. Als je bij ons komt te werken, weet dan dat je voor vragen m.b.t. Scrum altijd bij mij of de andere Scrum Masters aan kan kloppen.

TLDR

De organisatie dient punten in via JIRA en de Product Owner werkt dit met de betrokken stakeholders uit en plaatst het op basis van prioriteit in de Backlog van een van de teams. Tijdens de Sprint Planning wordt afgesproken aan welke punten de komende 2 weken wordt gewerkt en wat het beoogde doel is. Dagelijks komen developers kort samen om de tussenstand te bespreken en aan het einde van de sprint wordt de opgeleverde code gedemonstreerd aan geïnteresseerden en stakeholders. Tot slot wordt er in de Sprint Retrospective teruggeblikt op de afgelopen Sprint en worden verbeteringen doorgevoerd om de daaropvolgende sprint jezelf en collega’s nog gelukkiger te maken.

Geschreven door:

Peter

Developer

"Altijd in beweging met Mobiel.nl"

Geplaatst: 30-08-2019