Scrum werkt, bijna altijd

Reading time: 8 minutes

Author:

Marc Rissewijck (marc.rissewijck@ict.nl) is Scrummaster en Scrumcoach bij ICT Embedded. Met ruim tien jaar ervaring in softwareontwikkeling, variërend van techniek, projectmanagement, training en consultancy, begeleidt hij nu de invoering van Agile en Scrum binnen ICT.

Scrum leeft en groeit. Waarom? Omdat het werkt. Soms werkt het ook minder. Dat hebben ze bij ICT Embedded inmiddels ervaren. Ook weten ze dat ze er nog niet zijn en het proces moeten blijven aanpassen, in de ware zin van het begrip Agile. Marc Rissewijck deelt enkele ervaringen en geleerde lessen. Geen rocket science, wel praktisch. Niet makkelijker, wel leuker.

Bij BenQ Mobile kwam ik voor het eerst in aanraking met de invoering van Scrum op grote schaal. Scrum-goeroe Ken Schwaber trainde me hierna tot Scrummaster en maakte me erg enthousiast over de methode. Kort daarna startte ICT een aantal relatief kleine maar innovatieve projecten. Het waren soms slechts ideeën die nog verder moesten worden uitgewerkt. Ze hadden gemeen dat ze snel moesten aantonen dat de bijbehorende investeringsvoorstellen levensvatbaar waren. Een lastige opgave, maar typisch geschikt voor Agile-projectmanagement om zonder overbodige overhead tot snel resultaat te komen, zelfs als er nauwelijks requirements zijn. We voerden de projecten daarom volgens Scrum uit.

Scrum is een lichtgewicht projectmanagementmethode en een typisch Agile-proces. Dit laatste betekent dat mensenwerk, samenwerking en omgang met wijzigingen altijd centraal staan om werkende software te realiseren. Ondergeschikt hieraan zijn zaken als processen en tools, documentatie, contracten en vasthouden aan het plan. Scrum geeft handen en voeten aan de projectmatige uitvoering door het zelforganiserende ontwikkelteam centraal te stellen en zelfs volledig verantwoordelijk te stellen voor alle maandelijkse softwarereleases. Dit gebeurt op basis van requirements die de opdrachtgever iedere maand zou kunnen veranderen. Deze persoon vertegenwoordigt de klant en andere belanghebbenden tezamen en bepaalt naast de requirements ook de prioriteiten. 

Dit alles lijkt misschien een vrijbrief om gezellig samen te hacken aan een stuk code maar dat is bij Scrum absoluut niet het geval. Integendeel, Scrum is een zeer gedisciplineerd proces met een aantal eenvoudige regels die echter erg strikt moeten worden gehandhaafd. Dit doet de Scrummaster. Hij is verder verantwoordelijk voor de productiviteit van het team door blokkerende issues op te pakken. Normaalgesproken is dit de taak van een projectleider.

Het Scrum-proces is simpel en gebaseerd op korte iteraties vaak van dertig dagen, zogenaamde sprints. Aan het begin van zo‘n sprint toont de opdrachtgever zijn productwensen en bepaalt het team welke ze hiervan aan het eind van de maand hebben omgezet in een werkend product. Ze maken een teamplanning en voeren deze simpelweg uit. Om de voortgang te bewaken is er iedere dag een kort overleg van ongeveer vijftien minuten. Tot het eind van de sprint wordt iedere verandering in bijvoorbeeld requirements of het team buiten de deur gehouden. Zo kunnen de ontwikkelaars ongestoord en gefocust aan de slag. Let wel, een sprint omvat zowel het ontwerp, het code kloppen als het testen.

Aan het eind van de maand toont het team de gerealiseerde functionaliteit aan de opdrachtgever en de belanghebbenden. Ze krijgen te zien wat af is en wat niet. Op basis hiervan kunnen ze bepalen wat ze voor de volgende sprint belangrijk vinden. Verder evalueert het team de afgelopen sprint om afspraken te maken ter verbetering van de volgende iteratieslag. De volgende sprint start meestal de dag nadat de vorige is afgelopen en zo begint alles van voren af aan.

Flexibiliteit

Omdat Scrum duidelijk een ander proces is dan de traditionele ICT-projectaanpak zoals Prince 2 hebben we bij onze Scrum-projecten dan ook een aantal in het oog springende facetten ervaren die tegelijkertijd ook wel open deuren zijn. Opvallend is vooral de grote gedrevenheid van het team, hoewel die in moeilijke situaties soms ook erg moest groeien. Hiermee samenhangend blijkt het teamwerk intenser en raken de mensen meer betrokken. Het werk is leuker. Dit, in combinatie met een scherpe focus op een steeds werkend resultaat, leidt duidelijk tot hoge productiviteit.

Maar er zijn nog meer voordelen. Zo begint de flexibiliteit al bij de inrichting van Scrum zelf. Voor een project kozen we bijvoorbeeld om niet volledig ’Scrum te gaan‘, maar op basis van de standaard aanpak een paar componenten van Scrum mee te nemen, zoals de dagelijks overleg en sprintgebaseerde opleveringen. Gaandeweg kwam hier teamplanning en eigen verantwoordelijkheid bij.

Bij andere projecten deden we Scrum volgens het boekje. Iedere Scrummaster en ieder team geeft hier echter weer zijn eigen draai aan. De steeds terugkerende sprintevaluatie geeft het team eigenlijk een permanente sturing. Zo kunnen teams zich voor een sprint opsplitsen of juist samenvoegen. Dit moet wel in het belang van het product en de opdrachtgever, en altijd zonder veel overhead.

Voor de productiviteit is het essentieel dat de productwensen tijdens een sprint niet wijzigen. De sprintduur mag dus nooit langer zijn dan de periode waarin de requirements bevroren kunnen blijven. Bij ICT-projecten betekent het dat de sprints meestal drie weken duren.

Verantwoordelijkheid

Aan de andere kant is flexibiliteit ver te zoeken als het gaat om de scheiding tussen verantwoordelijkheden. De opdrachtgever bepaalt wat er eerst moet, het team bedenkt zelf hoe dat te doen. De Scrummaster bewaakt dit vraag-en-antwoordspel strikt en zorgt voor een ongestoord en gefocust team. Deze strikte scheiding wordt gewaarborgd door de directe en open communicatie die in Scrum zit ingebouwd. Je spreekt elkaar direct aan op verantwoordelijkheid en bijdrage. Dit zorgt voor duidelijkheid en transparantie, terwijl het ook over lastige zaken gaat. Het beestje wordt bij zijn naam genoemd, wat soms best confronterend kan zijn. Neem een teamlid dat een ander lid aansprak: ’Je hebt de afgelopen drie dagen nu wel dit en dat uitgezocht, maar wat is eigenlijk jouw bijdrage voor de sprint behalve ons lastigvallen? Over een week is de sprintreview en moeten we al leveren.‘ Peer pressure in een omgeving waar dit kan maar het is wel even wennen, vooral als de teamleden uit een traditionele omgeving komen. Het is belangrijk dat de Scrummaster of de Scrumcoach hier aandacht voor heeft.

Een andere vorm van flexibiliteit, of beter creativiteit, kwam naar voren bij een team dat in hun sprint een userinterface op een display van gloednieuwe hardware moest tonen. Helaas bleek onze partner de displaydriver niet volgens afspraak te kunnen leveren. Wat nu? De Scrummaster belde de partner natuurlijk om de dag, maar het team keek nog even verder. Een teamlid kende nog wel een bedrijf waar een vergelijkbaar display was ontwikkeld. Hij maakte via een internetforum contact met de originele hardwareontwikkelaar. Deze bleek nog wat ruwe testcode te hebben. Zo kon het team bij de sprintreview toch een werkend display tonen.

Vrijheid, blijheid

Zelforganiserende teams met en Scrummasters zonder verantwoordelijkheid, kan dit wel goed gaan? Al bij de eerste sprintevaluatie bleek van wel. De Scrummaster die een ervaren projectleider was, had duidelijk het gevoel dat hij meer controle had over het project. Door de korte dagelijkse scrums zat hij dichter op de echte zaken die binnen het team speelden. Veel concreter en directer. Opkomende zaken werden automatisch door het team opgepakt. Paradoxaal genoeg gebeurde dit zonder dat hij erachteraan hoefde te gaan of te controleren. Als vrijheid echter toch te veel overgaat in blijheid en het team niet zelf ingrijpt, moet de Scrummaster dit doen, vooral als de productiviteit in het geding is. Hij houdt het team een heldere spiegel voor en wijst ze op hun verantwoordelijkheden.

Zowel de Scrummaster als het team hebben tijdens de projecten minder last van het ’projectleidergevoel‘. Beide groepen vinden dit erg prettig. De Scrummaster hoeft zich minder als traditionele projectleider te gedragen, dus minder planning, minder controle, minder verantwoordelijkheid. Het team ziet ook minder een projectleider: niet iemand die gedurende een sprint sturing en controle uitoefent of zich ertegenaan bemoeit. Dit is meestal ook niet wenselijk of noodzakelijk omdat het team zelf zijn verantwoordelijkheid beleeft en zich hiernaar gedraagt.

Voor dit lagere projectleidersgevoel komt meer teamgevoel terug, tenminste als het goed is. Dit is ook noodzakelijk omdat het team de absolute motor van het project is. Hoe minder teamgevoel, hoe minder verantwoordelijkheidsgevoel. Zo heb ik eens een team begeleid dat voornamelijk bestond uit mensen die voor 50 procent aan het project deelnamen. Ze zaten er half in en kwamen aanvankelijk niet op gang door gebrek aan organisatie en communicatie en dus ook zelfsturing.

Vergelijkbaar hiermee is dat het niet optimaal is voor hecht teamwerk om leden te spreiden over te veel kamers. En zeker niet over meerdere ontwikkelcentra in het land. Gelukkig komt dit in de sprintevaluaties naar boven en moet het team dit oppakken.

Om de teamverantwoordelijkheid waar te maken zijn pro-activiteit en flexibiliteit vereist van het team en van eigenlijk ieder teamlid. Aangezien iedereen hier anders mee omgaat en voor Scrum dit absoluut essentieel is, is het soms nodig hier expliciet aandacht op te vestigen.

Aan de andere kant, een gedreven en hecht team kan kleine wonderen verrichten. Het is erg productief als de centrale focus op een duidelijk sprintdoel is gezet. Alle teamactiviteiten worden hier dan direct of indirect op gericht.

Tijdens evaluaties geven teamleden vaak aan dat ze gedurende de sprint veel meer waren gefocust op hun werk, op de taken van die dag. Omdat het team zelf de taken bepaalde, leefde de planning in het team en voelde iedereen ook hoe de taken onderling samenhingen, ook wat betreft prioriteit. Zo zie ik regelmatig dat teamleden elkaars taken overnemen voor een beter resultaat. Echt teamwork dus. Al met al leidt deze gezamenlijke focus tot hoge productiviteit waarbij teams soms expliciet stelden dat de resultaten niet mogelijk zouden zijn in een normale projectvoering.

Doen

Ieder project is anders en dat maakt het ook leuk. Door het karakter van Scrum, zijn Scrum-projecten extra verschillend, wat het eigenlijk alleen maar leuker maakt. De ervaringen zijn gevarieerder en dat maakt het moeilijker om conclusies te trekken. Er is simpelweg meer mogelijk om de projectdoelen te halen.

Slechts enkele onderdelen van het Scrum-proces zijn nieuw. De echte kracht zit ‘m niet in een of twee van deze componenten, maar vooral in de combinatie. Het een versterkt het ander. Gezamenlijk leidt dit tot een krachtig draaiende motor die zichzelf continu aanpast om tot betere resultaten te komen. Mensenwerk, samenwerking en flexibiliteit staan hierbij centraal. Op deze manier hebben wij bij ICT zeer positieve ervaringen met Scrum. Gewoon doen, is mijn advies.