Wat ik het afgelopen jaar als Scrum Master heb geleerd

Sinds februari werk ik met een nieuw vast team en zijn we erg bewust bezig geweest met het toepassen van de Scrum-methode. Graag deel ik met je wat ik hiervan heb geleerd, wat is opgevallen en waar we als team zeker mee doorgaan.

Scrum is wennen

De regels van Scrum zijn duidelijk, maar het goed toepassen van die regels is een flinke uitdaging. We hebben te maken met mensen, teams en organisaties die vóór Scrum op een andere manier werkten en projecten deden.

Het moeilijkste is dat er anders gedacht moet worden bij deze manier van werken. Het gevoel van zekerheid is verdwenen en het gevoel dat alles van tevoren duidelijk is, is er niet meer. Klanten hebben met Scrum veel meer invloed tijdens de uitvoering van het project. Hierdoor lijkt er minder zekerheid vooraf te zijn. Lijkt, want de zekerheid bij traditionele projectmethoden is slechts schijn. Juist tijdens een project loop je tegen allerlei zaken aan, waar van tevoren geen rekening mee was gehouden.

Dat is waarom we volgens Scrum werken. We maken gebruik van de onzekerheid en onduidelijkheid die er altijd is en dat doen we transparant. We maken klanten deel van alle beslissingen die onderweg genomen moeten worden. We geven de mogelijkheid om dingen sneller te doen als het eigenlijk niet zo veel waarde heeft. Of juist iets meer tijd nemen voor functionaliteit die essentieel is voor de klant.

Klanten beginnen vaak na een week het hele proces meegemaakt te hebben de voordelen ervan echt te zien. Het is daarbij belangrijk om ze genoeg te helpen; uit te leggen hoe het werkt en waarom het proces zo werkt.

Hoe strakker je het aanhoud, hoe beter het gaat

Zoals gezegd: Scrum is wennen. Het is lastig om niet naar oude werkpatronen terug te grijpen. Soms voelen de vaste meetings van Scrum als extra werk of is het vervelend dat je niet alvast vooruit mag werken om zo – gevoelsmatig – meer gedaan te krijgen. Maar steeds als we onze eigen (Scrum) regels overtreden lopen we tegen de lamp.

Meetings overslaan zorgt voor onvoldoende duidelijkheid op het juiste moment (just-in-time planning) wat ervoor zorgt dat het werk langer duurt. Voordat we beginnen aan een 'project' is zo goed als niks besloten of uitgedacht, er zijn alleen wensen. Pas tijdens de meetings binnen Scrum wordt bepaald wat we gaan maken; wat de beste oplossing voor het probleem is.

Door vooruit te werken zijn aan het eind van een sprint wellicht twee dingen niet af in plaats van één wel. Iedere sprint kan voorlopig de laatste zijn, daarom is het extra belangrijk om onderdelen af te ronden ten opzichte van vooruit werken.

Als het Scrumbord niet bijgehouden wordt is niet goed te zien hoe het staat met de voortgang en dus ook niet wat we kunnen verwachten dat af is aan het eind van de sprint. Het bord is belangrijk om verwachtingen bij te kunnen stellen.

In het oog houden wat de wens is, niet de oplossing

Onze ervaring is dat klanten denken vanuit hun huidige systeem. Op het moment kunnen ze daar iets bereiken door stappen in dat systeem te volgen. Of dat ze op basis van wat ze nu weten een bepaalde oplossing voor ogen hebben. Als ze ons dan vragen precies dat te maken, verliezen we een mogelijke verbeterstap. Wij weten namelijk wat de technische mogelijkheden zijn.

Daarom is het iedere keer weer belangrijk om scherp te zijn op de wens; wat willen ze uiteindelijk bereiken. Vragen waar de waarde voor hen zit in wat we gaan bouwen. Dan kunnen we zorgen dat we hun probleem oplossen met de inhoudelijke kennis van de klant en de technische kennis van ons.

Eerst Scrum Master

Bij Procurios hebben alle Scrum Masters een dubbelrol. Ze zijn Scrum Master en Ontwikkelaar of (zoals in mijn geval) Interaction Designer. De Scrum Master rol moet altijd eerst komen. Als het team problemen heeft die opgelost moeten worden moet dit altijd voor gaan. Ook meetings, het bijstaan van de PO en zorgen dat iedereen zich aan Scrum kan houden moeten voor gaan op ontwikkel- of ontwerp-werk. Alleen zo kan het team soepel draaien en een sprint succesvol afgerond worden.

Timeboxen is key

Eigenlijk alles binnen Scrum is 'getimeboxed' (onderdelen hebben een vaste tijd die niet overschreden dient te worden). Dat zorgt ervoor dat er altijd voldoende druk en focus is om het beste uit dat onderdeel van Scrum te halen. Deze tijden zijn allemaal relatief tot een dag of de lengte van een Sprint en staan dus altijd in verhouding tot de hoeveelheid werk die gedaan kan worden. Zo wordt er nooit te veel tijd besteed aan overleg en kunnen we snel dingen bouwen om ze daarna te valideren.

Ik heb dus een aantal waardevolle inzichten opgedaan in het afgelopen jaar. Ik hoop dat dit je een kijkje heeft gegeven in ons dagelijks werk en dat het wellicht wat uitlegt over Scrum en waarom wij zo werken.