5 Vragen over de introductie van Scrum

Organisaties worden niet van de ene op de andere dag agile. Het is een ingrijpend veranderingsproces waarbij iedereen zijn of haar rol moet heroverwegen en aanpassen. En het begint ermee dat het management een aantal behoorlijk lastige vragen moet beantwoorden.

Gezien de uitdagingen waarmee moderne organisaties te maken hebben, is Agile bijzonder aantrekkelijk. Wie wil er nu niet vaker releases uitbrengen? Wie wil zich niet beter kunnen aanpassen aan een voortdurend veranderende zakelijke omgeving? Toch overwegen te veel leidinggevenden Scrum en starten ze een agile transformatie zonder goed te begrijpen welke impact Scrum kan hebben op hun organisatie, hun carrière en hun doelen.

Scrum is niet iets dat lichtvaardig in een organisatie geïntroduceerd zou moeten worden, en leidinggevenden zouden zichzelf een aantal lastige vragen moeten stellen. Scrum is niet alleen een zaak van de ontwikkelteams. Het kan niet beperkt blijven tot één enkel team. De invoering van Scrum is een systeembrede verandering binnen een organisatie en wordt regelmatig als moeilijk en ontwrichtend beschreven. Maar wat betekent dat eigenlijk? Wat zijn mogelijke gevolgen van Scrum?

Hier zijn vijf vragen die beantwoord zouden moeten worden om je goed voor te bereiden op een succesvolle en productieve invoering van Scrum.

1) Hoe reageer ik op veranderingen die mijn rol beïnvloeden?

Deze vraag moet door iedereen in een organisatie beantwoord worden en niet alleen door de teams die met Scrum gaan werken. Scrum heeft de meest directe invloed op de teams, maar daar houdt het niet op. Hoe zit het met de leidinggevenden? En hoe zullen zij reageren als hun leiderschapsrol daardoor beïnvloed wordt?

Voorbeeld: Scrum en het middenmanagement

Ik zat met mijn vriend John (naam gewijzigd) te ontbijten. John was een development manager bij een grote financiële dienstverlener, waar Scrum de afgelopen jaren was ingevoerd.

Hij maakte zich zorgen over hoe zijn rol in het bedrijf nu gezien zou worden. Ik vroeg hem waarom hij bezorgd was, en hij antwoordde: „In het begin ging alles goed. De teams maakten snel vooruitgang en een teamgebaseerde werkomgeving past beter bij de mensen dan een shared-services-model. Maar nu hebben we teams die hun problemen grotendeels zelf oplossen en zelf hun prestaties bewaken."

Hij wilde weten wat zijn rol was in deze nieuwe zelforganiserende omgeving.

De functie van middenmanagers in bedrijven die gebaseerd zijn op het „Scientific Management"-model (Taylorisme) draait voornamelijk om de prestaties en efficiëntie van de medewerkers. Het Taylorisme wordt een groot deel van de productiviteitsstijging van de 20e eeuw toegeschreven. Het is echter minder geschikt voor het creëren van moderne, kennisgebaseerde producten.

Hoe verandert de rol van het middenmanagement dus bij de invoering van Scrum?

Na een kort gesprek besloot John dat hij iets kon bijdragen door als mentor en communicator voor zijn teams te fungeren, hen te laten zien wat er vanuit het bedrijf nodig is, en door het bedrijf te laten zien dat zijn teams aan die behoeften kunnen voldoen.

2) Hoe ga je om met je topmensen als ze niet mee willen op deze reis?

Niet iedereen wil met Scrum werken. Veel mensen vinden Scrum prettig omdat het hen in staat stelt om een product te maken waarop ze directe invloed hebben, en dat kan heel goed voelen. Maar niet iedereen zal dat zo ervaren.

Voorbeeld: De gefrustreerde ster

Jack was de ster van zijn team en dat liet hij iedereen weten. Als het team een deadline naderde, werkte Jack vaak 80 uur per week zodat het team zijn doel haalde. Vaak was hij om 22:00 uur nog op kantoor en stuurde hij zelfs in het weekend e-mails naar de directie. Het management was dol op hem!

De kwaliteit van zijn werk was echter twijfelachtig. Hij produceerde veel code die niet werkte en aanzienlijke herbewerking vereiste. Na weer een doorgewerkte nacht op kantoor waren de andere teamleden dagenlang bezig om zijn code te debuggen en te integreren.

Ze probeerden Jack uit te leggen dat zijn gedrag het hele team benadeelde – maar hij wilde niet luisteren en zei: „Bespreek dat maar met het management."

De situatie veranderde toen Scrum bij dit team werd ingevoerd. De voortgang en transparantie in het team werden elke dag tijdens de Daily Scrum besproken – de dagelijkse voortgang werd dus permanent door het team gemeten. Doordat het team zelf mocht beslissen hoeveel werk ze in een iteratie zouden afronden, konden ze gedurende het hele project in een duurzamer tempo werken.

Tijdens een Retrospective stelde het team het maken van niet volledig geteste code ter discussie, die het hele team tijd kostte.

Jack reageerde niet goed op de invoering van Scrum. De goede transparantie in de Daily Scrum maakte heel duidelijk dat Jack niet regelmatig code opleverde, maar het werk uitstelde tot de laatste dag van de Sprint. Toen het team suggesties deed om het probleem op te lossen, klaagde Jack over micromanagement.

Hij kon er niet mee omgaan om in een constant en duurzaam tempo te werken, en in plaats van zich te richten op de grootste waarde voor de klant, klaagde hij dat zijn werk „saai" of „geen uitdaging" was.

Toen het team zich tijdens een Retrospective ertoe verplichtte om de kwaliteit van de code te verbeteren door regelmatig te testen, dreigde Jack het team en zelfs het bedrijf te verlaten. Vijf Sprints na de invoering van Scrum verliet Jack het bedrijf vrijwillig. De prestaties van het team verbeterden gestaag en drie jaar later produceerden ze nog steeds een kwalitatief hoogwaardig product.

Bij de invoering van Agile moeten bedrijven zich afvragen wat er moet gebeuren als hun topmensen niet in een Scrum Team willen werken. Zou je ze laten gaan? Of moeten ze in het bedrijf blijven en mogelijk andere Scrum Teams verstoren? Als je bereid bent ze te laten gaan, hoe onderbouw je die beslissing dan?

3) Welke mechanismen ga je gebruiken om gedragsveranderingen teweeg te brengen?

Scrum vereist gedragsveranderingen; denk aan zelforganisatie, meer samenwerking en transparantie. Gedrag veranderen is extreem moeilijk, vooral voor langdurige medewerkers die getraind zijn om zich op een bepaalde manier te gedragen. Nu er verandering nodig is, hoe zorg je ervoor dat dit ook echt gebeurt?

Continue educatie speelt hierin een grote rol.

Als leidinggevende in het management kun je medewerkers ondersteunen met trainingen, coaching en conferenties en hen helpen om de moderne methoden van softwareontwikkeling te begrijpen en toe te passen. En door betrokkenheid bij de medewerkers te tonen, kan de moraal en tevredenheid van de werknemers en het bedrijf verbeteren.

Een wezenlijk deel van deze gedragsverandering heeft te maken met vertrouwen in het team. Als ik met iemand samenwerk en die persoon begrijpt mijn werk, is dat dan een risico voor mijn beoordeling? Is het een risico voor mijn baan? Hoe bouw je vertrouwen op als een van beide vragen met „ja" beantwoord kan worden?

Een gangbare aanpak is het veranderen van de verantwoordelijkheden en KPI's waarop medewerkers worden beoordeeld. Om samenwerkingsgedrag te stimuleren, wordt er meer gewicht gegeven aan teamwork dan aan individuele prestaties. Dit kan gedaan worden met teamgebaseerde of 360°-feedback.

Minder nadruk leggen op individuele prestaties stelt individuele verantwoordelijkheden ter discussie. Niemand wil verantwoordelijk zijn voor een specifiek gebied als hij beoordeeld wordt op de prestaties van het hele team. Daarom moeten leden van Scrum Teams uiteraard verantwoordelijkheid krijgen voor verschillende gebieden. Dat betekent dat ze in elke Sprint een deel van een potentieel leverbaar product moeten opleveren.

Dit lijkt misschien onbeduidend, maar het heeft grote gevolgen voor hoe een bedrijf opereert. Hoe beïnvloedt het je organisatiestructuur als teams verantwoordelijk zijn voor werk in meerdere verschillende vakgebieden?

4) Wat zal de supportafdeling vinden van de veranderingen die Scrum teweegbrengt?

Scrum wordt in de meeste gevallen door softwareontwikkelingsteams in een organisatie ingevoerd. Aan support- en architectuurteams wordt vooraf zelden gedacht. Dat komt doordat veel organisaties aannemen dat „Scrum iets is wat ontwikkelaars doen".

Feit is echter dat Scrum ook andere teams beïnvloedt. Hoe zullen supportteams bijvoorbeeld reageren als er wrijvingspunten ontstaan met de Scrum Teams? Hoe worden deze problemen dan opgelost?

Voorbeeld: Onenigheid tussen verschillende afdelingen

Sarah was een senior Java Messaging Service (JMS) architect en verantwoordelijk voor de bedrijfsvisie op een Enterprise Service Bus (ESB). Ze raakte steeds gefrustreerder omdat de Scrum Teams „de bedrijfsrichtlijnen negeerden door de ESB te omzeilen of nieuwe features toe te voegen die niet afgestemd waren op de bedrijfsstrategie".

Toen haar werd gevraagd waarom de teams zich zo gedroegen, zei ze dat de teams meer discipline nodig hadden en een betere training over de ESB-strategie. En toen voegde ze eraan toe: „Maar misschien voldoen wij ook niet aan hun eisen."

Na verder overleg besloot Sarah dat het waarschijnlijk het beste was om bij een Scrum Team aan te sluiten, om hun uitdagingen te begrijpen en hen te helpen de bedrijfsdoelen beter te begrijpen.

5) Wat is het bedrijf bereid uit te geven aan deze transformatie? En welke waarde wordt er voor die investering geleverd?

Weinig bedrijven hebben vooraf een duidelijk beeld van hoeveel ze ongeveer met Agile gaan verdienen. Er is weinig informatie beschikbaar over hoeveel omzet je kunt verwachten. Er zijn echter steeds meer bewijzen dat je met Scrum frequentere releases, betere productkwaliteit en directer contact met klanten kunt bereiken.

Een goede oplossing hiervoor is een vast jaarlijks budget voor permanente training en coaching van medewerkers. Dit wordt echter problematisch als de invoering van Scrum sneller gaat dan het budget toelaat. Het is ook moeilijk te rechtvaardigen als je niet duidelijk kunt zeggen hoeveel omzet ermee gegenereerd wordt.

Een betere oplossing zou het meten van een aantal belangrijke KPI's zijn, zoals:

• Omzet per medewerker
• Klanttevredenheid
• Medewerkerstevredenheid
  Als de leidinggevenden observeren of deze KPI's door Scrum verbeteren, kunnen ze zien hoe effectief de invoering van Scrum is en of er iets veranderd moet worden.

Er zijn echter een paar interessante dingen bij deze aanpak die het waard zijn om te benadrukken:

Ten eerste is deze methode onafhankelijk van het framework dat gebruikt wordt en zou het ook de prestaties van een bedrijf kunnen meten dat niet met Agile werkt. Ten tweede ontdek je misschien dat Scrum niet de beste aanpak voor jouw bedrijf is of dat er effectievere frameworks dan Scrum bestaan. Dat komt zelden voor, maar is natuurlijk mogelijk.

Precies deze meetaanpak heeft Ken Schwaber recentelijk opgepakt in zijn „Evidence-Based Management" (dt.: evidenzbasiertes Management). Het is nog te vroeg om te zeggen welke invloed deze aanpak op de softwareontwikkeling zal hebben, maar het is een zeer interessante oplossing en heeft het potentieel om bedrijven concrete bewijzen van hun verbetering te leveren.

De conclusie

Scrum invoeren is niet iets wat lichtvaardig gedaan moet worden. Er is zowel een risico voor de organisatie als voor de individuele personen. Als je de vragen begrijpt die mensen stellen, kun je hun motivatie, angsten en twijfels beter doorgronden. En met die kennis kun je een veel uitgebreidere aanpak vormen die ingaat op de behoeften van het bedrijf en de medewerkers.

„Het vermogen om logisch te denken is een van de dingen die ons menselijk maken. In een wereld van alomtegenwoordige informatie en geavanceerde analysetools is logica alleen echter niet voldoende. Wat succesvolle mensen zal onderscheiden, is hun vermogen om zich in te leven in hun medemensen, relaties op te bouwen en voor anderen te zorgen."
– Daniel H. Pink, bestsellerauteur van Drive

(Anmerkung: Dies ist ein Gastbeitrag von Scrum Trainer und Coach Kane Mar, dem Gründer von Scrumology.com und Scrum101.com.) Deze tekst is afkomstig uit de blog van Openview en werd door ons naar het Duits vertaald.