Blog
Agile transformatie deel 3: zomaar een paar valkuilen
Geplaatst op 6/04/2018
Door: Nico van Mourik, Consultant bij ViQiT
In mijn eerste twee blogs over agile transformatie richtte ik me vooral op de zaken waar je op moet letten. Deze derde blog wil ik me vooral richten op een aantal valkuilen. Sommige ken ik helaas uit ervaring, anderen zag ik bij collega’s en klanten terugkomen. Bij lange na niet compleet natuurlijk, het lijkt me ook interessant om ervaringen van jou als lezer te horen, dus reageer vooral! Als het even kan ook met tips, ik leer graag van jullie!
Nummer 1: het IT-feestje
Jawel, pak de slingers en de feestmutsen er maar bij! Het agile werken is namelijk een IT-feestje. Tenminste, dat denken veel andere collega’s binnen de organisatie. Want waarom zou jij je als product specialist of marketeer moeten bezig houden met agile werken? Je bent namelijk al zo ontzettend flexibel bezig. Dat vraagt de markt namelijk al van je. Tsja, dat dan die agile IT’ers er zo lang over doen om het te maken, dat laat maar weer eens zien dat agile totaal niets toevoegt!
Één van de lastigste onderwerpen bij agile transformatie is het daadwerkelijk inrichten van een cross functioneel team. Zolang de ‘cross functies’ maar op IT vlak liggen, lukt het vaak wel (programmeur, tester, ontwerper, etc.). Lastiger wordt het als het daadwerkelijk om functies buiten de IT gaat. Om dit te laten werken is continue aandacht nodig. Niet alleen in het begin als het agile werken wordt geïntroduceerd, maar ook later, als je al een tijdje bezig bent met agile. In het begin kost het zoveel tijd, dat het je productiviteit ogenschijnlijk gaat schaden. Vaak trappen organisaties dan in de ‘vervolg valkuil’ om het cross-functionele team dan maar weer af te schaffen. Goede begeleiding en ietwat geduld helpen hierbij. Oh ja, ook de volledige steun van het senior management/directie helpt hierbij.
Nummer 2: de scrum master is ‘overhead’
Aaargh! De overhead discussie. Ofwel: het ouderwetse financiële stokpaardje: als je niet direct betrokken bent bij het ontwikkelen en leveren van producten ben je overbodig. Dat dit dan ook gelijk opgaat voor henzelf, dat zien ze voor het gemak maar even over het hoofd. De scrum master is absoluut geen overbodige luxe maar een absolute voorwaarde. Zij/hij zorgt er namelijk voor dat het team optimaal kan functioneren. Bijzonder is dat vaak bij organisaties waar het agile werken totaal niet functioneert, de scrum master meerdere teams moet bedienen, vaak nog naast het ‘eigenlijke, echte werk’ dat zij/hij nog moet doen.
De scrum master is altijd belangrijk, maar zeker als je in een transformatie traject zit. Als je bezig bent met je transformatie, is het voor de leden van het team vaak nog zoeken naar de juiste werkwijze. En dan niet op existentieel niveau! Van die fijne sessies waar goeroes vertellen over de geweldige dingen die agile werken brengt. Met ronkende voorbeelden van hippe bedrijven die het GEWELDIG doen en de markt opschudden. Nee, nee, nee. Wat de teamleden nodig hebben is een dagelijkse steun en toeverlaat die hen adviseert en helpt wanneer ze zich afvragen of deze user story nu wel of niet meegenomen kan worden in de sprint. Of hoe ze een inschatting moeten maken tijdens het planning poker. Of hoe … enfin, je begrijpt het wel denk ik. Kortom: ze hebben een scrum master nodig. En dit moet een zeer ervaren persoon zijn met de juiste kennis, ervaring en persoonlijkheid om de rol te kunnen vervullen. Niet een persoon die toevallig ‘over’ was bij de laatste reorganisatie!
Nummer 3: als we agile gaan, dan gaat ook alles agile!
In tegenstelling tot valkuil nummer 1, gaat de slinger hier de andere kant op. In plaats van te kijken waarom je agile zou willen werken, wordt alles en iedereen gedwongen om agile te gaan werken. Dit kan soms tot lachwekkende situaties leiden, maar vaker is het om te huilen. Want wat ga je doen als je verplicht agile moet gaan werken terwijl dit totaal niet bij het werk past dat je doet? Je houdt je netjes aan je ‘verplichte nummertjes’ en verder maak je het belachelijk wanneer je maar kan.
Dit is buitengewoon jammer. Want de teams die wel op een agile manier (meestal scrum) kunnen werken en daar veel profijt van hebben, die hebben namelijk die andere collega’s hard nodig om agile te kunnen werken. Soms direct, soms indirect. Zorg dan dat je bij die afdelingen of collega’s het begrip voor agile werken vergroot. Zorg dat zij inzien dat ook hun bijdrage daaraan, hoe klein ook, cruciaal is voor het slagen van de agile teams. Veel mensen willen echt wel helpen en zijn vaak niet zo cynisch dat het hen niets interesseert. Mocht dat laatste toch het geval zijn, dan is er heel wat meer aan de hand in je organisatie dan agile werken kan oplossen.
Nummer 4: agile transformatie is een makkie, vooral scrum!
“Wat kan er nu zo moeilijk zijn aan het invoeren van het agile proces invoeren conform scrum? Je leest de scrum guide en misschien nog een boekje erbij en dan gewoon doen”. Letterlijk opgetekend uit de mond van een directielid. Als je dit soort opmerkingen hoort ben je eerst even met stomheid geslagen. Dan ga je argumenteren. Als je later terugkijkt en probeert te begrijpen waar het vandaan komt, dan is het wel te verklaren. De scrum guide is 19 pagina’s en dat is inclusief voorblad, dankwoord, etc. Dan ontstaat al snel de indruk dat als dat alles is, je dit ook zo kunt implementeren.
Het verraderlijke is natuurlijk dat Scrum geen proces is. Het is een raamwerk waarmee je je proces kunt inrichten. Vandaar de beperkte omvang. Het verder inrichten is iets wat je als organisatie zelf moet doen. Dat betekent dus continue nadenken. Niet alleen tijdens de invoering ervan, maar echt continue. Het is veel makkelijker om een compleet uitgeschreven proces in te voeren dan een raamwerk. Of zo’n gedetailleerd proces uiteindelijk meer oplevert is een ander vraagstuk, maar het invoeren gaat eenvoudiger. Dit betekent dus dat je met de implementatie van het scrum raamwerk fulltime bezig moet zijn. Je moet vragen en problemen direct oplossen als je ze tegenkomt. Je moet correcties toepassen wanneer iets niet werkt. Dus makkelijk? Ik dacht het niet.
Nummer 5: de backlog is van iedereen!
Bij valkuil nummer 3 hadden we het erover: niet iedereen in de organisatie is onderdeel van een agile team, maar wel iedereen is er bij betrokken. Wanneer de betrokkenheid ‘doorslaat’ kun je een bijzonder fenomeen krijgen: de backlog als to-do lijstje.
Je ziet dan backlogs met honderden items erop. Volledig onbeheersbaar voor de product owner. Maar denk nu niet dat je die zomaar op kunt schonen! Er mag vaak helemaal niets vanaf want anders ‘verliezen we dit onderwerp uit het oog’. In veel gevallen is het dan ook nog zo dat iedereen zijn/haar hersenspinsels direct op de backlog mag gooien. Tsja, ga dan maar eens proberen je backlog te managen als product owner. Laten we eerst maar eens een paar dingen duidelijk maken:
- De backlog is geen to-do lijstje voor de totale organisatie.
- De backlog is niet van iedereen. De backlog is van de product owner.
Zo, nu dit duidelijk is, even een ander punt. Dit aspect van de backlog is namelijk meestal een resultaat van een onderliggend probleem. Namelijk dat de rol van de product owner niet functioneert. Om wat voor reden dan ook wordt de product owner gezien als het knechtje van de stakeholders. Of meestal van de belangrijkste stakeholder, die dan toevallig ook hiërarchisch zijn leidinggevende is. Dat is vragen om problemen. In het begin van de transformatie zie je vaak dat de product owner nog moet groeien in zijn/haar rol. Geef als organisatie hem/haar de kans om te realiseren!
Eerder verschenen blogs in deze serie:
http://viqit.nl/2017/12/22/transformatie-naar-succesvol-agile-werken-is-vooral-hard-werken/
http://viqit.nl/2018/03/09/agile-transformatie-help-beginnen-we/