Inleiding

Een organisatieveranderingsproces is te omschrijven als het proces dat ervoor zorgt dat de organisatie van de oude naar de gewenste nieuwe toestand komt. Dit proces wordt in meerdere of mindere mate gestuurd, begeleid en gecontroleerd. Een sterke centrale sturing en controle zien we bij het ‘ontwerpmodel’ of blauwdrukmodel, aan de andere kant van het spectrum ligt het ‘ontwikkelmodel’. Beide modellen hebben natuurlijk hun specifieke voor- en nadelen. De hier beschreven aanpak ligt in sommige opzichten tussen beide modellen in, maar is geenszins een compromis.

In dit artikel wordt eerst een overzicht gegeven van de oorzaken van het mislukken van veel (de meeste!) organisatieveranderingen. Vervolgens wordt ingegaan op de kenmerken van de blauwdrukaanpak en de problemen die daarmee gepaard kunnen gaan. Daarna wordt een parallel getrokken tussen de blauwdrukaanpak en de watervalmethode in softwareontwikkeling. De watervalmethode is bij softwareontwikkeling inmiddels op grote schaal vervangen door Scrum, een agile aanpak met veel betere resultaten. In dezelfde gedachte wordt Scrum for Change als veranderingsaanpak geïntroduceerd, met een beschrijving van de voornaamste kenmerken. Deze kenmerken worden gerelateerd aan de faal- en succesfactoren die volgen uit onderzoeken naar mislukte veranderingstrajecten, waarbij zal blijken dat veel van de onderkende zwakheden van de blauwdrukaanpak zich niet voordoen bij Scrum for Change. Tot slot wordt ingegaan op de eigenschappen van de ondersteunende software, die de aanpak vrijwel onbeperkt schaalbaar maakt.

Verandermanagement

De wereld om ons heen verandert in een snel tempo, en om mee te blijven tellen moeten organisaties mee veranderen. Om succesvol te blijven is het nodig verandering te verankeren in de structuur van de organisatie. Veel organisaties ervaren echter dat veranderen moeilijk is en veel inspanning vraagt.

Een typisch verandermanagementproces kunnen we als volgt omschrijven. Op dit moment bevinden we ons in situatie A, na het veranderingsproces willen we situatie B bereikt hebben. Dit proces wordt in meerdere of mindere mate gestuurd, begeleid en gecontroleerd. Een sterke centrale sturing en controle zien we bij het ‘ontwerpmodel’ of blauwdrukmodel, waarbij vooraf het plan wordt vastgesteld en vervolgens voor uitvoering naar de rest van de organisatie wordt gebracht. Aan de andere kant van het spectrum ligt het ‘ontwikkelmodel’, waarbij er wel consensus is over de te bereiken eindtoestand, maar de weg ernaartoe wordt overgelaten aan de mensen binnen de organisatie en alles steunt op eigen verantwoordelijkheid en vertrouwen. Het zal niemand verbazen dat beide modellen hun specifieke voor- en nadelen met zich meebrengen. In de meeste grote organisaties wordt echter het ontwerpmodel gehanteerd.

De uitwerkingen van dit model variëren, maar in de meeste gevallen komt er een stuurgroep aan te pas met een veranderteam onder leiding van een stevige projectmanager. Deze hooggekwalificeerde denkers trekken zich terug en komen met een gedetailleerd plan, een budget en een planning. Volgens de gangbare projectmanagementstandaarden worden de belangrijkste mogelijke risico’s benoemd en mitigaties geformuleerd. Dit plan komt – na goedkeuring door de stuurgroep – terecht bij de mensen die het in de praktijk moeten gaan uitvoeren. Populaire misvattingen zijn dat meer gedetailleerde plannen beter zijn en dat meer erkende risico’s ons beter in staat stellen met onzekerheid om te gaan. Deze op het eerste gezicht toch zo logische opvattingen maken inderdaad deel uit van veel projectmanagementmethodieken, terwijl ze in feite een schijnzekerheid creëren.

Waarom organisatieveranderingen mislukken

Vooraanstaande onderzoekers als J.P. Kotter hebben aangetoond dat 70 procent van de grote veranderprojecten mislukt ([Kott08]). Deze bevindingen werden ook onlangs nog bevestigd door een breed onderzoek ([Towe13]). Projecten mislukken door een tekort aan:

• motivatie;
• betrokkenheid;
• drijvende kracht;
• communicatie;
• inbedding in de organisatie.

Dit zijn allemaal factoren waar ruime hoeveelheden van nodig zijn om de weerstand tegen veranderingen te overwinnen. Hoewel het voor de hand liggende antwoord is om te zorgen dat de tekorten in de genoemde factoren niet zullen optreden (door bij wijze van spreken ‘harder te duwen’ en ‘luider te roepen’), wordt in dit artikel een andere benadering voorgesteld.

In de jaren dat ervaring is opgedaan met agile ontwikkeling van software voor het ondersteunen van veranderingen zijn veel overeenkomsten ontdekt tussen de modelgedreven veranderingen en traditionele (weinig succesvolle) watervalsoftwareontwikkeling. Dit heeft geleid tot een andere aanpak, een aanpak waarbij ‘hard duwen’ en ‘luid roepen’ niet meer de kritieke factoren zijn.

Blauwdruk voor problemen

Hoewel de blauwdruk de meest gebruikte methode is, is dit ook de kiem van veel problemen in de veranderingsprocessen. Zoals ieder plan dient ook de blauwdruk goed afgestemd te zijn op de omgeving. De blauwdruk voor verandering, zoals geïllustreerd in figuur 1, kampt echter met verschillende afstemmingsproblemen:

• Afstemmingsproblemen in de tijd: doordat het plan vaststaat en de omstandigheden veranderen, raakt het plan minder goed afgestemd op de omstandigheden naarmate de tijd verstrijkt.

• Afstemmingsproblemen in de context: doordat het plan is samengesteld door een selecte groep mensen, is het niet optimaal afgestemd op de werkelijke uitgangssituatie in de praktijk.

• Afstemmingsproblemen over de toegevoegde waarde voor de organisatie: omdat het plan is opgesteld op een relatieve afstand door een kleine groep mensen, zullen de percepties over de business value of toegevoegde waarde van de veranderacties sterk uiteenlopen binnen de organisatie.

En, misschien wel de belangrijkste:

• Afstemmingsproblemen in betrokkenheid en motivatie: de mensen die het plan moeten uitvoeren, zijn vaak onvoldoende betrokken geweest bij het opstellen van het plan en zullen zich minder gecommitteerd voelen aan de uitvoering ervan.

Figuur 1. Generieke opbouw van een blauwdruk-veranderingsproces.

De blauwdrukmethode in softwareontwikkeling

In softwareontwikkeling is het traditionele proces ook georganiseerd als een blauwdruk. Onder de naam ‘watervalmethode’ worden in de requirementsfase de functionele behoefte en de randvoorwaarden nauwkeurig en uitgebreid gespecificeerd. Op basis van deze blauwdruk wordt de software in een volgende fase door een ontwikkelteam ontwikkeld. Wanneer de ontwikkeling compleet is, wordt het product gepresenteerd en vervult het hopelijk de verwachtingen uit de requirementsfase. Meestal is dat echter niet het geval.

Agile ontwikkeling met Scrum

Scrum is een agile ontwikkelproces met een andere aanpak: door kleine ontwikkelstappen te creëren waarin het uitwerken van requirements wordt gecombineerd met de softwareontwikkeling, kan optimaal gebruik worden gemaakt van de expertise van de ontwikkelteams. Deze ontwikkelstappen worden sprints genoemd en hebben doorgaans een duur van maximaal enkele weken. Het resultaat is dat Scrum-teams sterk gemotiveerd zijn en meer opleveren van een product dat beter is afgestemd op de verwachtingen. Deze voordelen hebben inmiddels geresulteerd in een brede adoptie van Scrum bij alle grote softwareontwikkelaars.

Succesfactoren van Scrum

Wat is nu de reden van het succes van Scrum? Het belangrijkste antwoord is motivatie. Doordat Scrum meer verantwoordelijkheid bij de ontwikkelteams legt, wordt voldaan aan drie belangrijke motiverende factoren: doel, autonomie (zingeving) en meesterschap ([Herz59], [RSA10], [Arie05]). Deze factoren zorgen in het algemeen voor een hoge motivatie bij professionals, die alles zullen doen om het project tot een succes te maken. Hierna wordt kort toegelicht hoe Scrum deze factoren inbouwt in het ontwikkelingsproces.

Doel

Een doel, het gevoel dat je werk zin heeft en een groter doel dient, is een belangrijke motivator. Het is immers essentieel om te weten waarom het de moeite waard is iets te doen, niet alleen voor je inzet maar ook om een beter begrip te hebben van de context. Een kenmerk van Scrum is het directe contact met de vertegenwoordiger van de klant en de eindgebruikers van het resultaat van het project. Dit contact stelt het team in staat bekend te raken met het doel, de context en de toegevoegde waarde van hun project. Bij softwareontwikkeling heeft deze vertegenwoordiger van de klant de naam product owner, in een veranderingsproces kunnen we spreken van een change owner. Een ander middel dat bijdraagt aan een dieper begrip van de doelen is de manier waarop specificaties worden beschreven in Scrum. Deze worden vastgelegd als korte ‘gebruikersverhalen’ waarin wordt beschreven wie (in welke rol) wat wil doen/bereiken en waarom hij/zij dat wil. Hieronder een voorbeeld van een dergelijke user story:

Ik, als bezitter van een bankrekening, wil geld op mijn rekening zetten, omdat ik wil sparen voor een nieuwe auto.

Samengevat: doelen op microniveau worden beschreven in user stories, terwijl het directe contact met de vertegenwoordiger van de klant, de change owner, zorgt voor begrip van de doelen op hogere niveaus.

Autonomie

Het zal weinig mensen verbazen dat professionals een hoge mate van autonomie nodig hebben om tevreden te zijn met hun werk. De meesten hebben jarenlange training achter de rug voor het analyseren en oplossen van problemen en het organiseren en plannen van projecten. Het heeft dan ook weinig zin om ze te beschouwen als machines die precies moeten doen wat ze voorgeschreven wordt. Omdat zij beter inzicht hebben in de lokale situatie en hun specifieke expertise beheersen, zijn zij juist in staat betere oplossingen te verzinnen dan wanneer deze van een afstand worden bepaald. Deze vrijheid is in Scrum aanwezig: de teamleden bepalen zelf hoe iets wordt opgelost en hoeveel tijd dat naar verwachting gaat kosten. Ook kiezen de teamleden zelf de taken die bij hen passen.

Meesterschap

Meesterschap, nauw verwant met het vorige punt, is het vermogen om ergens in te excelleren, een meester te worden in je vak. Een meester wordt beter en beter en is in staat zijn kennis expliciet te maken en anderen te helpen. Een deel van de meesterstatus vindt dan ook zijn oorsprong in het helpen van anderen. Om focus op de uitdaging te houden en het meesterschap te bevorderen worden randvoorwaardelijke zaken zo veel mogelijk buiten het werkproces gehouden. Daarvoor verantwoordelijk is de Scrum-master; deze faciliteert het proces en lost problemen op die de teamleden van het uitvoeren van hun taak afhouden. Het team komt iedere dag bijeen in een korte staande sessie waarin de ervaringen van gisteren, de taken van vandaag en de problemen worden besproken.

Wendbaarheid

Hiervoor werd een korte toelichting gegeven op de motivatieaspecten van Scrum. Scrum biedt echter nog een voordeel ten opzichte van de blauwdrukaanpak: wendbaarheid (agility). Wendbaarheid wordt bereikt door het veelvuldig herijken van prioriteiten en korte leveringscycli (sprints).

Prioriteiten stellen

De trekker van de veranderingen (change owner) heeft als het goed is een duidelijk beeld van welke veranderingen nodig zijn en welk budget daarvoor beschikbaar is. Hij is dan ook in een goede positie om de toegevoegde waarde (voor de organisatie) van een bepaalde veranderstap (user story) te bepalen. Deze toegevoegde waarde wordt uitgedrukt in een cijfer van 0 tot 100 en kan worden gebruikt om de prioriteiten voor de lijst van user stories te bepalen. Het doel van het project is om zo veel mogelijk toegevoegde waarde te realiseren. Dit betekent dat stories met een hogere toegevoegde waarde eerst worden uitgevoerd.

Sprints met een vaste doorlooptijd en kwaliteit en flexibele scope

Een sprint duurt bij Scrum 2 tot 4 weken. Na iedere sprint wordt iets opgeleverd en gedemonstreerd, namelijk de realisatie van de user stories die aan de sprint zijn toegekend. Stories die niet ‘af’ zijn, worden niet opgeleverd. Dit betekent in de praktijk dat er altijd een resultaat wordt opgeleverd, op tijd, binnen het budget en met de afgesproken kwaliteit, waarin de stories met de meeste toegevoegde waarde zijn gerealiseerd. Het vereiste kwaliteitsniveau wordt afgesproken in de ‘Definition of Done’.

Deze werkwijze blijkt in de praktijk een kosteneffectieve methode te zijn om doelen te realiseren, terwijl tegelijkertijd wordt voorkomen dat excessieve kosten worden gemaakt om de laatste x procent van minder belangrijke zaken te realiseren.

Figuur 2. Wendbaarheid van een Scrum-aanpak vergeleken met de blauwdrukaanpak. Voor de start van iedere sprint is aanpassing van het plan mogelijk. [Klik op de afbeelding voor een grotere afbeelding]

Omarm de verandering

De flexibiliteit in scope die volgt uit Scrum heeft het voordeel dat het gemakkelijker wordt om in te spelen op voortschrijdend inzicht of veranderende omstandigheden. Na iedere sprint wordt een selectie van user stories verplaatst van de grote lijst die de veranderdoelstellingen beschrijft naar de volgende sprint. De change owner kan nieuwe stories toevoegen en die een waarde geven, zolang hij/zij zich maar realiseert dat daarmee stories met een lagere waarde ook lager op de ranglijst komen. De stories met de laagste waarden kunnen daardoor uiteindelijk buiten de boot vallen. Ook kan de change owner de waarde van de nog niet uitgevoerde stories aanpassen, zodat de prioriteiten opnieuw worden bepaald.

Motivatiefactoren in grootschalige processen

Scrum is in principe kleinschalig, gebaseerd op relatief kleine teams. Enthousiast over het succes van de Scrum-aanpak, hebben we onderzocht welke factoren nog meer invloed hebben op de motivatie en of we daarmee juist grootschalige processen kunnen beïnvloeden. De behoefte hiertoe ontstond tijdens een project om software te ontwikkelen voor de begeleiding van de Nederlandse gemeenten bij het implementeren van bouwstenen voor de e-overheid. Duidelijke aanwijzingen zijn te vinden in onderzoeken over motivatie en gaming: de betere spellen weten hun spelers als geen ander te motiveren om uitdaging na uitdaging aan te gaan. Na het bestuderen van verschillende publicaties op dit gebied ([Medi05], [Clar07], [Malo87], [Przy10]) kwamen we tot de volgende motivatiefactoren:

• Intrinsieke motivatie – de balans tussen intrinsieke motivatie en situationele interesse.
• Doelen – een richting en aanmoediging of prikkels om vol te houden, verwachtingen over de resultaten en de waarde die daaraan wordt toegekend.
• Autonomie – mensen hebben behoefte om de oorsprong voor hun acties te voelen, willen kunnen kiezen wanneer ze deelnemen en willen controle hebben over de duur en het tempo.
• (Het bouwen aan) zelfvertrouwen – gelegenheid tot zelfreflectie en uitdagingen op maat (niet te gemakkelijk maar ook niet te moeilijk).
• Uitdaging – genoeg uitdaging voor een vroege succesbeleving, een individuele balans tussen vaardigheden en uitdagingen, een geleidelijke toename in moeilijkheidsgraad.
• Feedback – weten wat je prestaties zijn terwijl je toewerkt naar je doel.
• Sociale waardering – door mensen die er voor jou toe doen.

Enkele elementen in deze lijst vertonen grote overlap met de Scrum-motivatiefactoren. De overige elementen zullen door de meeste gamers kunnen worden bevestigd, maar worden buiten de gamingindustrie nog maar mondjesmaat gebruikt. In eerste instantie is in het e-overheidproject vooral gebruikgemaakt van de doelen, feedback, het managen van de uitdaging door het aanbieden van coaching en de sociale factoren. Toch bleef de gedachte bestaan dat Scrum juist voor grote transformaties veel zou kunnen bieden. Grote organisaties moeten op een grotere schaal veranderen en staan bloot aan veel van de ‘blauwdruk’-gevaren. Voor een grote organisatie met veel businessunits, lokale vestigingen et cetera is de kloof tussen de plannenmakers en de uitvoerders immers breder, terwijl de contextuele verschillen groter zijn.

Scrum voor grootschalige veranderingstrajecten: KPMG Scrum for Change

Om de stap te maken van Scrum als basis voor grootschalig changemanagement is een aanpak nodig die wordt ondersteund door software. Hoewel Scrum in kleinschalige situaties ook goed werkt zonder software, is in grootschalige parallelle processen ondersteuning door software een absolute voorwaarde. De software draagt niet alleen bij aan kwaliteitsverhoging en versnelling van het proces, maar ondersteunt ook de andere motivatiefactoren. Methode en software samen vormen KPMG Scrum for Change.[KPMG Scrum for Change is een geregistreerd handelsmerk.]

Het KPMG Scrum for Change-framework beoogt de hiervoor benoemde motivatiefactoren op een praktische wijze te integreren in het veranderingsproces door de elementen van Scrum te combineren met de door de IT geboden mogelijkheden voor kennisdeling en socialmediafuncties.

• Intrinsieke motivatie en doelen. Deze factoren worden geadresseerd door niet alleen het doel van het veranderingstraject te benoemen, maar vooral door op lokale schaal subdoelen te benoemen (user stories) en de lokale ‘what’s in it for me?’-vragen te beantwoorden.
• Autonomie. De leden van de lokale Scrum-teams kiezen zelf de taken die ze willen uitvoeren en kunnen user stories toevoegen en wijzigen.
• (Het bouwen aan) zelfvertrouwen. De user stories zijn goed afgebakend en in enige dagen realiseerbaar. Iedere dag is er overleg en gelegenheid tot zelfreflectie in het Scrum-team, zodat ook problemen zich niet kunnen opstapelen.
• Uitdaging. Dit hangt samen met de autonomie: teamleden kunnen naar wens zwaardere of meer taken (user stories) kiezen en zelf user stories toevoegen.
• Feedback. Feedback wordt geboden op verschillende niveaus: tijdens de dagelijkse meeting, door de voortgang bij te houden en te tonen en door de sprint review en sprint retrospective.
• Sociale waardering. Hierbij gaat het om de waardering van teamleden voor elkaar wanneer zij zien dat waardevolle bijdragen worden geleverd aan het bereiken van het sprintdoel, die van de change owner maar ook die van andere teams wanneer zinvolle user stories en probleemoplossingen worden gepubliceerd en wanneer het team een ander team kan helpen.

Aanpak

Hierna worden de stappen geschetst die deel uitmaken van de Scrum for Change-aanpak, beginnend vanuit een behoefte aan verandering in een grote organisatie. Allereerst wordt een initiatieteam geformeerd dat het veranderproces gaat voorbereiden. Dit team start een Scrum-traject met drie plateaus: voorbereiding, training en participatie. Pas in het participatieplateau vindt de opschaling naar de volle breedte van de organisatie plaats.

Voorbereiding

Het ontwikkelen van een visie en het bepalen van de geschikte wegen om de visie te communiceren liggen aan de basis van alle veranderprocessen. Deze taken worden in de eerste fase ter hand genomen. Er wordt een lijst van mijlpalen of tussenproducten opgesteld, gekoppeld aan een voorlopige globale planning. De deliverables omvatten:

• een heldere en krachtig geformuleerde visie;
• een communicatiestrategie;
• de totale baten en kortetermijnbaten;
• fasen met een thema of naam;
• de lengte van de sprints;
• het voorlopige aantal sprints;
• een lijst met aanbevolen user stories.

Naarmate er meer aanbevolen user stories worden opgesteld, wordt de centrale sturingscomponent sterker. Wanneer er echter te veel centraal gestuurd wordt, komen enkele belangrijke motiverende factoren in de knel en neemt de effectiviteit af. De aanbevolen user stories en de andere elementen worden ontwikkeld met het initiatieteam en verfijnd en uitgewerkt met minimaal één pilotteam uit een businessunit of een lokale eenheid.

Training

Tijdens het veranderproces is de change owner beschikbaar om het team te inspireren, vragen te beantwoorden en de resultaten te beoordelen. Afhankelijk van de breedte van de verandering (het aantal betrokken teams) en de diepte ervan (hoeveel vakgebieden betrokken zijn, hoeveel specialistische kennis benodigd is), moeten change owners, Scrum-masters en (specialistische) adviseurs worden getraind voor hun taken.

De change owners zijn de ambassadeurs van de verandering en communiceren de visie, de Scrum-masters ondersteunen het Scrum-proces en de specialisten bieden de teams ondersteuning op hun expertisegebied. Voor elk team is een change owner en een Scrum-master nodig. De specialisten verdelen hun tijd over de teams.

Figuur 3. Procesoverzicht met opschaling naar de gehele organisatie.

Participatie

Na de voorbereiding en de trainingsfase worden de lokale teams geïnstalleerd. Deze teams gaan de veranderingen lokaal vormgeven. De lokale teams worden samengesteld door de change owner en de Scrum-master. De eerste vervult de klantrol voor de veranderingen. De change owners zijn zich bewust van de veranderdoelen en kunnen toegevoegde waarde van de stories inschatten om de beschikbare middelen zo goed mogelijk te verdelen. Dit betekent ook dat zij verantwoording dragen voor het zo goed mogelijk aanwenden van het beschikbare budget. De Scrum-masters zorgen ervoor dat het Scrum-proces goed verloopt. Zij worden zo nodig bijgestaan door een specialist met Scrum-ervaring. Net als de andere specialisten is deze op organisatieniveau beschikbaar om de teams te helpen.

De verandervisie en de doelen worden in realiteit omgezet door de teams binnen de organisatie. Deze teams kunnen komen uit verschillende businessunits, bedrijfsafdelingen, lokale vestigingen, gemeenten of landenkantoren. Belangrijk is dat de teams lokaal zijn en een nauwe relatie hebben met de dagelijkse praktijk. In sommige gevallen kunnen lokale teams weer subteams installeren.

Scrum in de lokale teams

De omzetting van de visie naar daadwerkelijke veranderingen vindt plaats aan de hand van user stories. De user stories geven een duidelijk beeld van wat moet worden gerealiseerd, voor wie en waarom. Het plateau is verdeeld in korte sprints, elk met een set deliverables. De teams hebben een voorraad voorgedefinieerde user stories om uit te kiezen, maar kunnen ook zelf nieuwe stories toevoegen. Een team wordt samengesteld uit mensen met verschillende voor de verandering benodigde competenties en heeft de vrijheid om stories op zijn eigen wijze te realiseren. Aan het eind van de sprint worden de deliverables gedemonstreerd aan de change owner en deze beoordeelt of ze aan zijn verwachtingen voldoen.

De change owners uit de lokale teams participeren in de centrale Scrum of Scrums, waar de lokale resultaten op concernniveau worden bijgehouden en geëvalueerd (zie figuur 3). De centrale voortgang is dus de resultante van de lokale voortgang. Ook op centraal niveau is het mogelijk nieuwe user stories te introduceren of andere prioriteiten te stellen. Deze kunnen bij de eerstvolgende lokale sprint worden opgepakt, in overleg met de change owners en de lokale teams. De Scrum of Scrums kan op deze wijze de scope beïnvloeden wanneer daartoe aanleiding is. Eventuele verschillen in voortgang kunnen – voor zover van belang – worden opgevangen door de user stories die ‘achterlopen’ een hogere prioriteit te geven. De IT-infrastructuur zorgt ervoor dat de goede voorbeelden en oplossingen worden gedeeld. Dit draagt bij aan het meesterschap van de voorlopers en stimuleert de voortgang bij de volgers.

Figuur 4. Activiteiten tijdens het voorbereidings- en het trainingsplateau.

Gestructureerde user stories

De users stories zijn essentieel in het proces en dienen precies geformuleerd en rijk aan contextuele informatie te zijn. Dit wordt doorgaans bereikt door het toepassen van een wie-wat-waarom-patroon zoals eerder besproken. Voor KPMG Scrum for Change hebben we een vijfstappenstructuur uitgewerkt die het mogelijk maakt user stories snel te vinden, te vergelijken en uit te wisselen. Dit maakt dat de parallelle teams eenvoudig stories kunnen uitwisselen en hergebruiken. De structuur voegt een context toe aan de handeling en splitst het ‘wat’ in een werkwoord en een lijdend voorwerp, zoals geïllustreerd in figuur 5.

Figuur 5. Voorbeeld van een gestructureerde user story.

Ondersteuning met IT

Het veranderproces voltrekt zich dus parallel op veel verschillende plaatsen. Om dit proces te ondersteunen en te monitoren en kennisuitwisseling te garanderen is IT-ondersteuning nodig. De teams worden ondersteund met een taakbord (Scrum board) met voortgangsindicators waar de teamleden de taken kunnen kiezen en van status kunnen veranderen. Daarnaast wordt een online sprint-planningtool geboden waarmee de teamleden, desgewenst vanaf verschillende locaties, samen de stories kunnen inschatten (sprint poker). De software faciliteert het bieden van hulp aan andere teams en de ‘beloning’ in onder andere de vorm van een ranking. De verschillende oplossingen voor het automatisch delen van (gestructureerde) user stories, kennis en oplossingen voor problemen zullen vooral bij grotere parallelle trajecten een significante versnelling mogelijk maken.

Figuur 6. Prototype web-based tooling ter ondersteuning van het Scrum for Change-proces.

Conclusie

Het KPMG Scrum for Change-framework maakt het mogelijk een breed scala van motivatiefactoren integraal in het veranderingsproces op te nemen. Zo ontstaat een resultaatgerichte schaalbare aanpak die het draagvlak voor en de betrokkenheid bij de veranderingen maximaliseert. Door de decentrale structuur en de Scrum-aanpak worden veel traditionele problemen bij veranderingsprocessen voorkomen. Zo kan beter worden ingespeeld op onzekerheid en veranderende omstandigheden en is de aanpassing aan de lokale situatie gegarandeerd. Hoewel de methode het accent legt op de lokale inspanningen die resulteren in de concernbrede verandering, zal de balans tussen centrale sturing en lokale invulling per organisatie en per proces verschillen. De aanpak zal de behoefte aan resources voor de bekende faalfactoren sterk doen afnemen omdat een alternatief geboden wordt dat de motivatie in het veld sterk vergroot.