Kiest u scrum? Lees eerst de bijsluiter

Kiest u scrum? Lees eerst de bijsluiter

Scrum is een populair middel om softwareproducten te leveren. Maar pas op! Net als een medicijn heeft dit middel bijwerkingen en kun je maar beter de bijsluiter gelezen hebben.

Jan van Gulik en Jord van der Zwaag

Scrum (Schwaber et al., 2013, Van Solingen et al., 2013) is een raamwerk voor het iteratief en incrementeel opleveren van softwareproducten en andere producten. De methode kenmerkt zich door ‘agile’ waarden en principes, die zijn vastgelegd in het Agile Manifesto (zie www. agilemanifesto.org). De nadruk van agile ligt op samenwerking, werkende software en op meebewegen met veranderingen. Andere agile methodieken zijn Extreme Programming, DSDM en SMART. Scrum maakt de laatste jaren een sterke opmars en wordt volop gebruikt. In sommige organisaties is Scrum al tot in de haarvaten doorgevoerd. Andere organisaties willen Scrum wel invoeren, maar worstelen met de vraag of Scrum wel zo eenvoudig de plaats van hun gangbare methodieken kan vervangen. Bij weer andere bedrijven introduceert de (software) leverancier Scrum. Velen ervaren in meer of mindere mate een positieve verandering bij de toepassing van Scrum, maar weten niet zo goed welke elementen van Scrum werkelijk waarde leveren en welke niet. Bovendien verlopen lang niet alle Scrum-projecten vlekkeloos. Het loopt nogal eens stroef tussen opdrachtgever en leverancier(s): in de rolverdeling tussen Scrum-master en ‘product owner’, in de teams zelf en tussen de Scrum-teams en de rest van de organisatie. Wij hebben een kort onderzoek uitgevoerd om een aanzet te geven tot een Scrum-‘bijsluiter’ op basis van praktijkervaringen. Het betrof interviews en gesprekken met meer dan twintig senior managers bij softwarebedrijven (verdeeld over verschillende sectoren) waar Scrum al onderdeel is van het ‘operating model’ en bij bedrijven waar IT-systemen van groot belang zijn voor processen. Op basis van ons korte onderzoek hebben wij dit artikel opgezet, waarmee wij u willen helpen om de kans op succes in uw projecten te vergroten.

Bijsluiter

Een bijsluiter is een folder die bij een geneesmiddel wordt verstrekt. In deze folder staat informatie over het middel. De bijsluiter is wettelijk verplicht en wordt streng gecontroleerd, in Nederland door het College ter Beoordeling van Geneesmiddelen. Pas als de tekst volledig en helder is en gestaafd wordt door wetenschappelijk onderzoek mag een bijsluiter gedrukt en verspreid worden. De aanduiding ‘bijsluiter’ is ook in zwang geraakt voor andere teksten met een waarschuwend en voorlichtend karakter, bijvoorbeeld de financiële bijsluiter. In zijn afscheidsrede als hoogleraar aan de Vrije Universiteit (‘Structuurhygiëne geboden’) beval prof. dr. Keuning het gebruik van bijsluiters aan bij elk nieuw managementmodel of managementconcept (Keuning, 2008).Alle bijsluiters hebben de volgende indeling

1. Waarvoor wordt dit middel gebruikt?

2. Wanneer mag u dit middel niet gebruiken of moet u er extra voorzichtig mee zijn?

3. Hoe gebruikt u dit middel?

4. Mogelijke bijwerkingen

5. Hoe bewaart u dit middel?

6. Aanvullende Informatie

 

‘Business’-waarde leveren

Waarvoor wordt Scrum gebruikt? Scrum wordt veelal gebruikt voor softwareontwikkelprojecten, maar ook bij andere productontwikkeltrajecten en innovatietrajecten. Het doel is om in kort en afgebakend tijdsbestek tegen een vast budget zoveel mogelijk ‘business’-waarde te leveren in de vorm van werkende producten. Juist in projecten waarin het op te leveren eindproduct lastig vooraf is te definiëren, biedt Scrum uitkomst. Het Scrum-raamwerk biedt de gelegenheid om al doende te leren en het eindresultaat stukje bij beetje op te bouwen, uit losse deelproducten die op zichzelf ook waardevol zijn (figuur 1) . Scrum omarmt het feit dat gedurende het project veranderingen optreden, bijvoorbeeld bij projecten met gloednieuwe technologie die zich nog niet heeft bewezen of bij projecten in een markt die niemand echt goed overziet en waarin ontwikkelingen elkaar snel opvolgen.Denk bij ‘veranderingen’ aan veranderende inzichten en toegenomen kennis, een veranderende buitenwereld en veranderende wet- en regelgeving. Door de opzet van het Scrum-raamwerk, met zijn korte ontwikkelcycli (‘sprints’) van één tot vier weken en zijn continue focus op prioriteiten, kun je snel op deze veranderingen inspelen zonder dat je je eerdere plannen hoeft aan te passen. Het Scrum-raamwerk is een ‘maak’-methodiek, die vooral geschikt is om in korte cycli zeer gericht samen te werken aan het leveren van op zichzelf staande deelproducten die onderdeel zijn van het na te streven eindproduct. Met Scrum richt je je altijd op de belangrijkste en meest actuele zaken: de functies c.q. ‘deliverables’ die snel een werkend en waarde genererend product opleveren. Omdat je werkende deelresultaten oplevert, die op zichzelf al waarde hebben voor de gebruikers en omdat je je continu richt op het meest belangrijke, werk je voortdurend aan het tegengaan van verspilling van tijd, geld en motivatie.

Vaklieden

Hoe gebruikt u Scrum? De essentie van de toepassing van Scrum is dat vaklieden met complementaire competenties in een team bij elkaar worden gebracht, het liefst in één ruimte, waar zij met elkaar in korte oplevercycli aan oplossingen werken. Het team wordt gefaciliteerd door een Scrum-master, die ervoor zorgt dat de teamleden optimaal kunnen werken en zich aan de Scrum-regels houden. De ‘product owner’ vertegenwoordigt degene voor wie het product wordt gemaakt en hij of zij bepaalt hoe het product eruit ziet. Dat gebeurt in de vorm van ‘user stories’: voor iedereen eenvoudig te begrijpen eisen en wensen die in een vast verhaalformat beschreven zijn. Deze user stories komen op een lijst: de ‘product backlog’. De product owner prioriteert de user stories, op basis van toegevoegde waarde. De teamleden bepalen welke user stories zij kunnen uitvoeren in de eerstvolgende sprint. Deze komen dan op de ‘sprint backlog’ te staan. De sprintproducten worden inclusief documentatie en inclusief testen werkend opgeleverd. Aan het einde van elke sprint wordt het werkende product in een demonstratiesessie getoond aan de ‘product owner’ en aan eventuele andere stakeholders. Aan het slot van de sprintcyclus is er een evaluatie waarin de teamleden lessen trekken en afspraken maken over hoe ze deze in een volgende sprint in de praktijk brengen. Figuur 2 brengt het ‘gewicht’ van Scrum in beeld (Moussault et al., 2011). Op de verschillende aspecten van projectmanagement wordt de mate van ondersteuning door methodiekbeschrijving gescoord. Bij de score 0 wordt het aspect niet genoemd, bij de score 1 wordt het aspect wel genoemd maar niet uitgewerkt, bij de score 2 wordt het aspect nader uitgewerkt en bij score 3 wordt het aspect uitgewerkt in ondersteunende hulpmiddelen, zoals templates, checklisten, lijstjes, tips en technieken. Op geen enkele onderdeel scoort het Scrum-raamwerk een volledige uitwerking. Dus het raamwerk moet bij toepassing in de praktijk op basis van eigen inzichten worden ingevuld.

Niet of voorzichtig gebruiken

Wanneer mag u dit middel niet gebruiken of moet u er extra voorzichtig mee zijn? Het gaat om de volgende situaties:

Bij afhankelijkheid van leveranciers

Veel organisaties, met name binnen de overheid, zijn gebonden aan aanbestedingsregels die een hoge mate van risicodeling vereisen en vastlegging vooraf van het op te leveren resultaat. Scrum laat juist die ‘vooraf-bepaalbaarheid’ los en door de aard van Scrum kunnen leveranciers niet anders bijdragen dan met het leveren van vaklieden voor de teams. De verantwoordelijkheden en risico’s liggen dan eenzijdig bij de opdrachtgever. Leveranciers zijn ook uit op waardecreatie, en als er onvoldoende tegenwicht is, zijn zij bewust of onbewust geneigd te kiezen voor zichzelf door zo lang mogelijk op uurbasis bezig te zijn. Niet alle organisaties zijn toegerust of ingericht om dat onder controle te houden, vaak omdat de deskundigheid of drive daarvoor ontbreekt. Bij opdrachten die onder het Europese aanbestedingsrecht vallen is het zelfs nog maar de vraag of projecten op deze wijze mogen worden aanbesteed, gezien de hoge mate van onzekerheid over het eindproduct [Leether, 2013]; alle aanbiedende partijen moeten tenslotte een gelijke kans krijgen om vooraf duidelijk te maken wat ze op welke wijze en tegen welke kosten kunnen leveren. Daarvoor bestaan wellicht manieren binnen het aanbestedingsrecht, maar die zijn complex en vereisen veel kennis van het inkooptraject om claims het hoofd te kunnen bieden.

Bij implementaties

Scrum richt zich op het leveren van een product en niet op de veranderingen die het product teweeg brengt. Bij ‘customer facing’-applicaties zal dit niet zo’n probleem zijn, omdat de veranderingen voornamelijk ervaren worden door (website-) bezoekers. Wanneer de Scrum-producten wezenlijke veranderingen in een organisatie veroorzaken, moet ook voor de implementatie zorggedragen worden. Over het algemeen is daar een andere groep medewerkers bij betrokken dan de ‘maak’-medewerkers in het Scrum-team. De aard van de implementatie-activiteiten ligt meer buiten dit team, in de vorm van trainingen, bijwerken van instructies, presentaties, workshops, et cetera. De activiteiten vereisen wel coördinatie in groepsverband en kunnen aan effectiviteit en efficiëntie winnen als ze regelmatig, net als in Scrum, gevisualiseerd (bijvoorbeeld met Kanban, een systeem om te signaleren) en doorgesproken worden.

Bij het invullen van lacunes

Zoals figuur 1 aangeeft is Scrum geen extensief uitgewerkte methodiek. Er zijn geen uitgewerkte templates, checklisten, lijstjes, tips en technieken. Dat betekent dat de uitwerking aan de teamleden zelf wordt overgelaten. Als die betrokkenen geen of onvoldoende kennis en ervaring meenemen moet dit proefondervindelijk uitgevonden worden, wat leidt tot efficiëntieverlies.Dit efficiëntieverlies wordt groter als verschillende teamleden zelf hun werkwijzen meenemen en er discussie ontstaat. Doordat Scrum de invulling van deze aspecten niet afdwingt, ontstaat er bij gebrek aan discipline en hygiëne bovendien een kans dat aspecten helemaal niet ingevuld worden, met een verhoogd faalrisico als gevolg.

Bij gebrek aan vaklieden

Om de kans van slagen van Scrum te vergroten zijn adequaat functionerende medewerkers in alle teamrollen noodzakelijk. De juiste vaklieden moeten in de juiste samenstelling toegewezen zijn. Scrum is geen alibi voor het ontbreken van de juiste vakmensen. Scrum reikt echter geen enkele aanwijzing aan over het samenstellen van een team (zie figuur 1). Die teamsamenstelling vergt inzicht, kunde en aandacht. Er worden twee prominente rollen benoemd, die van product owner en Scrum-master. Vanuit de traditionele methoden weten we dat het tot stand komen van een requirement vooraf moeilijk is, vanwege de feitelijke of ogenschijnlijke tegengestelde belangen van de vele stakeholders. Met het introduceren van Scrum zijn die stakeholders en de door hen gewenste invloed niet verdwenen. Hoe groter de organisatie, hoe meer stakeholders invloed willen hebben op het eindresultaat of het product. Als de product owner niet over de capaciteit, steun en tijd beschikt om de belangen van alle stakeholders te verzoenen, dan kan de druk op hem of haar te hoog worden – met een hoog afbreukrisico als gevolg. De Scrum-master speelt een belangrijke rol bij teamvorming en teamperformance. Daar is echter veel kennis en ervaring nodig en de rol van een teamleider is doorslaggevend [Hackman, 2002]. Hoewel de Scrum-master niet echt de rol van teamleider is toegeschreven, wordt dit in de praktijk wel van hem verwacht. Als de Scrum-master wel over het certificaat beschikt maar niet over de noodzakelijke kennis, ervaring en coachingvaardigheden, dan is het risico op ‘underperformance’ hoog.

Bij gebrek aan governance

Het Scrum-raamwerk zegt niets over de organisatie van de laag boven de product owner. Stel dat de product owner of de Scrum-master zijn rol onvoldoende invult, wie kan dan op welke wijze en op welk niveau escaleren? Methodieken als Prince 2 geven hier uitsluitsel over. Bij de inrichting van een Scrum-organisatie moet dus aanvullend aandacht worden besteed aan richtinggevende mechanismen. Een adequate governance is hier geboden, met duidelijkheid over bijvoorbeeld wie onder welke omstandigheden intervenieert.

Bij niet-complexe activiteiten

Scrum is ontstaan om complexe situaties en onvermijdelijke veranderingen tijdens het maakproces het hoofd te bieden. Het complete Scrum-raamwerk is niet zinvol bij routinematige en eenvoudige werkzaamheden die snel goed te specificeren en uit te voeren zijn. Voorbeelden hiervan zijn regulier databaseonderhoud, het aanmaken van nieuwe accounts, het toewijzen van rechten en werkzaamheden aan de IT-infrastructuur, zoals aansluitvervangingen, hardwarevervangingen of configuratie van apparatuur. Deze werkzaamheden kunnen wel aan effectiviteit en efficiënter winnen wanneer ze gevisualiseerd worden (bijvoorbeeld met Kanban) en wanneer ze vooraf besproken worden met andere deskundigen in bijvoorbeeld een ‘standup’-setting.

Mogelijke bijwerkingen

Wat zijn mogelijke bijwerkingen Scrum? We zetten ze voor u op een rij:

Verhoogd elan

Een mogelijke positieve bijwerking van Scrum is verhoogd elan bij de teamleden, dat ‘besmettend’ kan werken op de rest van de organisatie. In een Scrum wordt een setting gecreëerd waarin vakmensen met elkaar een optimale oplossing mogen ontwerpen en realiseren. Traditioneel werden dergelijke vakmensen individueel benaderd bij een probleem en gevraagd naar hun mening over een oplossing. Eigenlijk wisten ze dat ze te weinig informatie hadden voor het geven van een sluitende oplossing. Ook was er vaak te weinig tijd om een oplossing met andere specialisten integraal door te denken. Dat leidde tot suboptimale oplossingen gepaard gaande met frustraties. De Scrum-setting legitimeert het bijeenbrengen van vakmensen uit meerdere disciplines, waardoor deze met hun kennis direct van waarde kunnen zijn bij het realiseren van veel betere oplossingen. Dat motiveert en inspireert.

Actiereflex

Het Scrum-raamwerk is een maakmethodiek en gaat ervan uit dat er een gevulde product backlog is. De fase die moet leiden tot een gevulde product backlog is niet in het raamwerk beschreven. Het is dan ook niet aan te bevelen om Scrum te omarmen als er geen overeengekomen werkwijze is om tot een waardevolle product backlog te komen. Het weglaten van deze fase (waarin aandacht voor analyse, diagnose, haalbaarheid, richting, ontwerpcriteria, leiding en legitimering noodzakelijk is) leidt tot ondoordachte risico’s. De omarmde Scrum-methodiek verleidt in het geval van het ontbreken van een adequate voorbereidingsfase tot een disfunctionele actiereflex [S. ten Have et al., 2009].

Taalmisverstanden

Het invoeren en gebruiken van Scrum gaat gepaard met een nieuwe taal. Hoe ouder de organisatie, hoe meer een eigen taal onderdeel van de cultuur is geworden. Agile Scrum komt met nieuwe taal, met woorden ontleend aan andere methoden en zelfs aan sport, met een eigen betekenis, zoals Scrum-master, sprints, product, product owner, velocity. De kans is groot dat iedereen begint met een eigen interpretatie van de betekenis van de woorden. Software developers hebben de neiging ‘product’ te interpreteren als het softwareproduct dat ‘in productie’ moet worden gezet. Productmanagers zullen geneigd zijn te refereren aan de producten die ze in de markt trachten te zetten. En gebruikers zijn pas tevreden als het Scrum-resultaat inclusief de implementatie significante verbeteringen laat zien. De mogelijk bijwerking is een spraakverwarring, die leidt tot oeverloze gesprekken en waardeverlies.

Onbeheerste teamdynamiek

Een van de uitgangspunten van Scrum is dat veel verantwoordelijkheid bij het team wordt gelegd. Een mogelijke bijwerking daarvan is dat teams te veel autonomie krijgen en deze, wellicht onbewust, gebruiken om een te laag tempo aan te houden. Volgens Scrum hoeven ze tenslotte geen garanties te geven dat alle of de meeste user stories opgeleverd worden. De punten waarmee de zwaarte van hun taken aangegeven wordt, bepalen de teamleden zelf en zijn daarmee subjectief en niet te benchmarken aan andere teams. Hoe verder de teams met hun systeem afstaan van de feitelijke waardecreatie van hun activiteiten, hoe groter de verleiding wordt om de veiligheid van voorzichtigheid te kiezen en risico’s te vermijden. Het risico op een te hoog tempo aanhouden is net zo goed aanwezig, waardoor er roofbouw wordt gepleegd op het uithoudingsvermogen van de teamleden.

Bewaren en onderhouden

Hoe bewaart en onderhoudt u Scrum? De ontwikkelingen van de Scrum-methodiek zijn te volgen via internet op www.scrum.org: bijhouden verdient aanbeveling. Het is wel zaak dat de ‘best practices’ op de projectmanagementaspecten uniform gehouden worden als u werkt met meerdere Scrum-teams. Dat voorkomt dat nieuwe teamleden (al dan niet van leveranciers afkomstig) hun eigen interpretaties meenemen en voor spraakverwarring zorgen.

Hoge verwachtingen

De meeste managers die we gesproken hebben, hebben hoge verwachtingen van Scrum. Mogelijk terecht. We zien tegelijkertijd dat Scrum aan het klimmen is op de ‘Peak of inflated expectations’ op de ‘hype cycle’ van Gartner – mede door radiocommercials en een overdaad aan trainingsaanbod. (De hype cycle brengt in kaart hoe een nieuwe technologie de hele cyclus doorloopt van belofte tot geaccepteerd product. Daarbij is er halverwege het traject altijd sprake van een tijdelijke, maar soms forse, terugval; figuur 3 ). Scrum is niet de ‘silver bullet’, niet de Haarlemmerolie voor alle projecten. Succes is evenmin gegarandeerd. Het vereist vakmanschap om te herkennen welk project of welke verandering op welke wijze het meest doeltreffend en doelmatig aangepakt moet worden. Daarvoor zijn een adequate analyse en diagnose en keuze uit meerdere aanpakken onontbeerlijk. Met de overwegingen in de bijsluiter hopen we een bijdrage te leveren aan de ontwikkeling dat Scrum na de ‘peak’ niet terecht komt in Gartners ‘trough of disillusionment’ (letterlijk: de trog van teleurstelling) en daar blijft hangen.

Jan van Gulik MMC is zelfstandig verander- en programmamanager. Hij is lid van kennisgroep Interim- en projectmanagement van Augustusconnect. E-mail: jhvgulik@nosco.nl

Jord van der Zwaag is zelfstandig project- en programmamanager. Hij is lid van kennisgroep Interim- en projectmanagement van Augustusconnect. E-mail: info@zwaag.nu

 

Literatuur Schwaber et al., 2013] Ken Schwaber en Jeff Sutherland (2013), De Scrum Guide op www.scrum.orgVan Solingen et al., 2013]

Rini van Solingen en Eelco Rustenburg, De Kracht van Scrum (2013), Amsterdam, Pearson Benelux. Keuning, 2008] Doede Keuning (2008), Structuur Hygiëne geboden, Amsterdam, Pearson Education Benelux.Moussault et al., 2011]

Ariane Moussault, Edwin Baardman, Fritjof Brave (2011), Wegwijzer voor methoden bij projectmanagement, Zaltbommel, van Haren Publishing.

Leether, 2013] Ruud Leether, Flexibel Contracteren: Kans of Hype?, Automatiserings Gids 20, 7 nov 2013, pp. 26-26. Hackman, 2002]

J.R. Hackman (2002), Leading teams: Setting the stage for great performances, Boston, Harvard Business School Press. S. ten Have et al., 2009]

S. ten Have, W. ten Have, B. Jansen (2009), Systematisch en methodisch organisaties veranderen, Holland Management Review (127), pp. 15-27.

Tag

Onderwerp



Niet gevonden? Vraag het de redactie!

Heeft u het antwoord op uw vraag niet gevonden, of bent u op zoek naar specifieke informatie? Laat het ons weten! Dan zorgen we ervoor dat deze content zo snel mogelijk wordt toegevoegd, of persoonlijk aan u wordt geleverd!

Stel uw vraag