In software ontwikkeling moet je snel kunnen inspelen op wijzigende wensen en veranderende omstandigheden. Een zorgverzekeraar, zoals DSW, heeft meerdere complexe IT-systemen. Denk bijvoorbeeld aan het digitaal indienen en uitbetalen van declaraties, het verwerken van aanmeldingen en het innen van premies. Al deze systemen moeten ontwikkeld en onderhouden worden en daarvoor maken we bij DSW gebruik van de Scrummethodiek: we werken in kleine multidisciplinaire teams aan stukjes software die we in sprints van twee weken opleveren. Hoe dit er precies uitziet, wat de voordelen hiervan zijn en wat deze werkwijze zo leuk maakt zal ik in deze blog proberen uit te leggen.

Scrum in een notendop

Multidisciplinair samenwerken

Op de ICT afdeling van DSW worden verschillende projecten uitgevoerd. Binnen deze projecten zijn er een of meerdere Scrumteams die werken aan de software van zo'n project. Zo heb je bijvoorbeeld binnen het Webproject een Scrumteam voor de persoonlijke omgeving (https://mijn.dsw.nl), een team voor de aanmeldingen (https://aanmelden.dsw.nl) en een team voor de publieke website (https://www.dsw.nl).

Een Scrumteam is een groep van collega’s met wie je nauw samenwerkt. Dit team bestaat uit een Product Owner, Scrum Master en een Ontwikkelteam. De Product Owner is, kort gezegd, de opdrachtgever en werkt veel samen met de Business Analisten. De Scrum Master begeleidt de scrumsessies en ondersteunt het Ontwikkelteam. Bij ons is de Scrum Master meestal een ontwikkelaar of designer die ook onderdeel is van het Ontwikkelteam. Onze Scrum Master weet dus goed hoe de applicatie in elkaar zit en kan het Ontwikkelteam hierdoor beter ondersteunen.

Het Ontwikkelteam voert het werk uit en is multidisciplinair. Dit team bevat dus junior/senior ontwikkelaars, designers én testers. Je bent als team samen verantwoordelijk voor het opgeleverde product en werkt dus vaak tegelijkertijd aan één stukje functionaliteit.

Digitale takenlijst

We werken met een digitale Product Backlog, een term die vaak binnen Scrum terugkomt. De Product Backlog is een geprioriteerde takenlijst waarop al het nog op te pakken werk staat. De Product Backlog Items (PBI’s) die hierop staan zijn kleine stukjes die onderdeel zijn van een groter project. Met Scrum lever je namelijk een groot project op in kleine behapbare brokken.

Aan deze kleine onderdelen kunnen we los van elkaar werken. Het voordeel hiervan is dat we de belangrijkste dingen eerst kunnen bouwen en de minder belangrijke zaken later. Onze Product Backlog staat in TFS, dit is handig want zo kan je digitaal de PBI’s benaderen en kan iedereen ze vanaf zijn/haar computer openen.

Potje pokeren?

Het ontwikkelteam schat zelf in hoe groot een PBI is. Dit doen we in een pokersessie. Iedereen krijgt een set kaarten die lijkt op de Fibonacci reeks. Met het schatten geldt namelijk: hoe groter het PBI, hoe minder nauwkeurig je hem kan schatten.

Tijdens de pokersessie legt de Product Owner of Business Analist de wensen voor het PBI uit. Daarna moet iedereen uit het Ontwikkelteam een kaart kiezen. Je kiest een kaart op basis van hoeveel ‘effort’ je denkt dat het PBI kost. Onze keuze laten we tegelijk aan elkaar zien. De verschillen in inschattingen bespreken we en het pokeren herhalen we totdat er consensus is bereikt. Op deze manier is iedereen betrokken bij de inschattingen en kan je elkaar niet van te voren beïnvloeden. Wanneer de PBI’s een schatting hebben kunnen ze worden ingepland in de sprint.

Pokerkaarten gebaseerd op de Fibonacci-reeks

Sprintend werken

Om flexibel om te gaan met veranderingen, plannen we bij DSW het werk voor het Ontwikkelteam slechts twee weken vooruit. Deze periode van twee weken heet een sprint. Samen met je scrumteam bepaal je tijdens de sprintplanning wat je voor de komende twee weken gaat oppakken. De hoeveelheid werk die op een sprint komt moet haalbaar zijn voor je team, maar het moet natuurlijk wel uitdagend blijven. We kijken hierbij naar de ‘verbrande’ pokerpunten van de vorige sprints om de werksnelheid van het team te bepalen.

Binnen deze planning spreek je ook met je team af wat het doel van de sprint gaat worden en hoe je dit doel gaat bereiken. Daarna ga je met je team er alles aan doen om dit doel binnen de twee weken te halen. Het leuke hiervan is dat je dus samen de verantwoordelijkheid draagt voor het eindresultaat.

Staand overleggen

Elke ochtend hebben we een stand-up met het scrumteam bij het scrumbord. Voor elk team hangt er een scrumbord aan de muur. Dit zijn borden waarop alle PBI’s van de sprint staan. Op deze borden wordt de voortgang en prioriteit van een PBI aangegeven. De PBI’s die binnen het sprintdoel vallen hangen bovenaan en hebben de meeste prioriteit.

Tijdens de stand-up bespreken we met het team wat er gisteren is gedaan om het sprintdoel te halen, wat we vandaag gaan doen om het sprintdoel te halen, en of er eventueel problemen zijn om dit sprintdoel te bereiken. Dit is het moment waar je samen met je team kan bespreken of je extra hulp nodig hebt of dat je iemand anders kan helpen.

Naast een scrumbord hebben we ook een digitaal scrumbord. Hierop staan alle taken tot in detail uitgewerkt. Het team kan zo precies zien wie aan welk taakje werkt.

Aan het einde van een sprint is, als het goed is, het sprintdoel behaald. Tijdens de sprintreview laten we aan de stakeholders/opdrachtgevers zien wat er nieuw is gebouwd. Dit is ook gelijk het ideale moment om feedback te verzamelen. Deze feedback gebruiken we om het product te optimaliseren.

Terugkijken en tweaken

We hebben na elke sprint een retrospective met het scrumteam. Hierin organiseert de Scrum Master oefeningen om samen met het team te evalueren wat er afgelopen sprint goed ging en wat er eventueel beter kan. We kijken hoe we efficiënter en plezieriger kunnen werken. Want naast efficiëntie moet Scrum ook leuk zijn! Deze verbeteringen implementeren we in de toekomstige sprints.

De oefeningen kunnen gaan van een rondje “wat ging goed – wat ging niet goed” tot een oefening waarbij iedereen via post-it’s input levert. Een voorbeeld van zo’n oefening staat hieronder:

Een oefening voor de retrospective: Three little pigs

Tot slot

We hebben gemerkt dat veel ontwikkelaars, designers en testers deze manier van werken erg leuk vinden. Ik ben zelf Scrum Master geworden toen we Scrum op de hele afdeling gingen doorvoeren en inmiddels is te zien hoe Scrum de samenwerking en snelheid bevordert. In plaats van afzonderlijke teams voor designers, ontwikkelaars en testers, is dit nu gemixt! Hierdoor hoef ik, als ontwikkelaar, niet met mijn taak te wachten totdat de designer klaar is met het design, want we werken hier gewoon samen aan. Als we klaar zijn met ons werk kan onze tester gelijk kijken of het er goed uitziet en of het goed werkt. De doorlooptijd is dus veel korter en je hebt veel sneller feedback.

Ook de Scrumsessies zijn vaak nuttig. Het samen terugblikken op de afgelopen sprint geeft nieuwe inzichten. En omdat we samen de PBI’s inschatten en bepalen wat we gaan oppakken in de komende sprint, heb je een realistische planning en weet iedereen wat voor werk er de komende sprint klaarligt voor het team.

Meer weten over Scrum? Lees bijvoorbeeld eens de Scrum Guide.