Je hoort buzzwords zoals ‘Scrum’, ‘Agile’ of ‘Product Owner’ vast wel eens langskomen op de werkvloer. De termen spelen naast dat ze hip klinken, een belangrijke rol in de manier waarop Opinity hun software bouwt en beheert. Waarom is Scrum zo populair en waarom gebruiken we geen andere projectmethoden? Als basis is het handig om te begrijpen wat Scrum precies is.

Wat is scrum?

Scrum is een software-ontwikkelmethode om op een efficiënte en flexibele manier software te bouwen. Waar Agile de overkoepelende mindset is, is Scrum de methode die uit Agile voortvloeit. Agile betekent letterlijk ‘behendig’ en daarmee wordt bedoeld dat er op een flexibele manier kan worden ingespeeld op veranderingen. Om die ‘behendigheid’ te kunnen garanderen houdt Scrum de periode tussen opleveringen kort. In een periode van één of twee weken levert het Scrum-team een (deel)product op. Op dit product kan gelijk feedback worden gegeven waar in de volgende periode weer rekening mee kan worden gehouden. Zo blijven de lijntjes kort en zijn er geen maanden radiostilte tussen de gebruikers en ontwikkelaars van het systeem. De iteraties worden ook wel ‘Sprints’ genoemd. Meestal duurt een Sprint één of twee weken.

Het Scrum-team

Om wat dieper in te gaan in Scrum, kijken we naar het team. Deze bestaat uit een Product Owner, Scrum Master en een zelfsturend ontwikkelteam. Het product en de complexiteit van het project bepalen uit wie dit ontwikkelteam bestaat. Dit zijn meestal ontwikkelaars, een architect en QA. De invulling hangt echt af van het product, dus er zou maar zo een Business Analyst bij kunnen zitten.

Product Owner

Het Scrum-team rapporteert aan de Product Owner. De PO doet wat de naam suggereert: hij beheert het product. Als hoofdtaken vallen hieronder het beheren van de Product Backlog en het optimaliseren van de waarde van het product. Ook communiceert de Product Owner met alle stakeholders. Dit zijn de Business Owners, financieel betrokkenen, maar ook de eindgebruikers. Eigenlijk is de Product Owner het bruggetje tussen de het Scrum Team (waar hij zelf onderdeel van is) en alle externe partijen.

Scrum Master

Om te zorgen dat alles soepel verloopt binnen het team, is er één heel belangrijk persoon: de Scrum Master. De Scrum Master beheert het Scrum-proces en zorgt ervoor dat het team zo efficiënt mogelijk te werk kan gaan. Is er hardware nodig? Reageert een koppelende partij al drie weken niet? Beheert de Product Owner de Product Backlog niet goed? De Scrum Master zorgt ervoor dat het zo snel mogelijk wordt opgelost! Ook plant de Scrum Master de benodigde meetings in.

Het ontwikkelteam

De ontwikkelaars bouwen het product. Ze bepalen zelf hoe ze van benodigde functionaliteiten van de Product Backlog tot een werkend product komen. Niemand, zelfs niet de Scrum Master (niet voor niets geen Scrum Manager), vertelt ze hoe ze dit moeten doen. Een ontwikkelteam is multidisciplinair en bevat qua mankracht alles om een Sprint te kunnen voltooien. Vanuit Scrum geldt geen hiërarchie binnen het ontwikkelteam en zijn er geen titels. In een ideale wereld is ieder lid van het team zo multidisciplinair opgesteld dat ze elk van de benodigde functionaliteit kunnen bouwen. Dit om eventuele afhankelijkheid van enkele personen te verminderen. Natuurlijk leven we niet in een ideale wereld en zijn mensen gespecialiseerd in bepaalde deeltaken. Maar dat staat los van het feit dat het gehele ontwikkelteam verantwoordelijk is voor het te bouwen product.

Product Backlog, Sprints en andere rituelen

Zoals genoemd in het vorige hoofdstuk, is de Product Owner verantwoordelijk voor de Product Backlog. De Product Backlog bestaat uit een lijstje met taken, ook wel Product Backlog Items genoemd, die niet afhankelijk zijn van elkaar. In een Product Backlog Item staat met een Use Case of User Story beschreven wat er moet worden gebouwd door het ontwikkelteam. De PBI bevat naast de functionele omschrijving een aantal acceptatiecriteria. Meestal worden deze acceptatiecriteria geschreven met een vooraf afgesproken syntax zoals: Given-When-Then. Bijvoorbeeld:

• Gegeven ik voldoende saldo heb op mijn bankrekening;
• Wanneer ik geld probeer over te schrijven naar een andere rekening; dan wil ik dat het geld wordt overgemaakt naar de andere rekening zonder foutmeldingen.

Als de Product Owner de acceptatiecriteria heeft opgesteld op deze manier, kan dit gemakkelijk worden opgenomen in (geautomatiseerde) tests die kunnen worden uitgevoerd door het ontwikkelteam. De Product Owner schrijft de criteria op basis van de eisen van alle stakeholders. Zo is er dus van tevoren duidelijk hoe het product er functioneel uitziet.

De Sprints van één of twee weken bestaan uit een aantal onderdelen. Een Sprint begint met een Sprint Planning. Hierin wordt de, door de Product Owner vooraf geprioriteerde, Product Backlog verfijnd door het ontwikkelteam en de Product Owner. Op basis van de complexiteit van de PBI’s, wordt er een Sprint gepland. Zo wordt er uit een gedeelte van de Product Backlog een Sprint Backlog gevormd. Deze Sprint Backlog staat qua inhoud vast tot het eerstvolgende oplevermoment aan het einde van de Sprint. Scrum is wel flexibel, maar het moet wel mogelijk zijn voor het ontwikkelteam om enigszins houvast te hebben aan het werk wat moet worden uitgevoerd. Daarom wordt er van de inhoud van de Sprint Backlog tijdens de Sprint niet afgeweken.

Als de Sprint is begonnen, gaan de ontwikkelaars aan het werk. De ontwikkelaars werken de Sprint Backlog ‘top-down’ af (ja, een hippe manier voor: van boven naar beneden). Elke dag op een vast moment – meestal ’s ochtends – hebben zij een Daily Scrum of een Daily Standup. Deze Standup is voornamelijk bedoeld voor het ontwikkelteam zodat ze kunnen afstemmen. De Scrum Master bewaakt de duur van de Standup op basis van de teamgrootte, meestal een kwartiertje. In de Standup noemt ieder teamlid wat hij gisteren heeft gedaan, wat hij vandaag gaat doen en of er nog blokkers zijn. Zo is het team altijd van elkaar op de hoogte. Omdat er dit soort meetings zijn, is het van belang dat het team niet te groot is. Een team van 4 à 5 man wordt gezien als ideaal.

Aan het einde van de Sprint is er een demo moment, ook wel de Sprint Review. Hierin laat het team zien wat ze hebben opgeleverd. In principe kan iedere stakeholder aansluiten en feedback geven op dit moment. Na de Sprint Review trekt het ontwikkelteam zich weer terug en houden zij een Sprint Retrospective. In deze Retrospective spreken ze naar elkaar uit wat beter kon, wat het team goed heeft gedaan en wat ze moeten blijven doen. Dit vaste moment van kritiek is essentieel voor het constant blijven verbeteren van het ontwikkelproces.

Nadat alle Scrum-rituelen zijn uitgevoerd, wordt er weer een nieuwe Sprint gestart. Dit betekent dus weer een Sprint Planning. De Product Owner zorgt dat de Product Backlog altijd up-to-date is, dus op basis van de Product Backlog kan er weer worden verfijnd en kan het team weer een nieuwe Sprint Backlog vullen. Tijdens deze planning kan het team gelijk de feedback meenemen van de Sprint Review en kunnen PBI’s daar eventueel op worden aangepast door de Product Owner.

Waarom geen waterval, waarom toch al die micromanagement?

Als je Scrum volgens het boekje (The Scrum Guide) volgt, zorgt dat juist voor veel duidelijkheid naar alle betrokkenen. Zo zijn er geen onrustige stakeholders die continu de ontwikkelaars bellen. Of bijvoorbeeld treurige gezichten aan het eind van een periode van zes maanden, omdat het gerealiseerde product totaal niet voldeed aan de eisen. Alle betrokkenen hebben de mogelijkheid om op een vastgestelde manier invloed uit te oefenen op het product. Veranderen de functionele specificaties na een maand? Dan schrappen we de Product Backlog en beginnen we opnieuw. Gelukkig weinig tijd verloren en héél snel weer met alle gezichten dezelfde kant op.