Een boutje om een team te ontregelen?

Ik zat met trots naar de etappe-finish van de Volvo Ocean race te kijken. Twee Nederlandse teams strijdend om de winst. Hoewel ik zeker weet dat dit een faire strijd was, moest ik toch aan het trucje van ervaren wedstrijdzeilers denken.

Vaar je vlak voor de finish met een zeilschip in een nek-aan-nek race en wil je winnen, gooi (ongezien) een boutje hoog in het zeil van je concurrent. Zodra dat op het dek valt is de kans groot dat de ander van schrik (gaat de mast knappen?) zijn concentratie verliest en jij een beslissende voorsprong kunt pakken. Zou dat ontregeld worden nou ook bij Agile teams gebeuren?

Teams, de cruciale factor in Agile transformaties

In Agile transformaties staat het functioneren van zelforganiserende teams centraal. Bij aanvang promoten zij breed wat de voordelen van het Agile werken kunnen zijn. Later in het traject zijn zij de motor achter de transformatie door hun drive om te verbeteren en constante lobby om het Agile werken te verbreden. Uiteindelijk vormen deze teams de ruggengraat van de nieuwe organisaties. Het succes van teams is daarmee een cruciale factor en daardoor ook het grootste risico van een transformatie? Wat zijn de bedreigingen?

Het effect van een boutje

Als je op een zeilschip merkt dat er van boven een boutje valt, gebeurt er wat. Vaak zal er een moment van verwondering zijn en wordt er na kort overleg besloten om door te varen, wel met wat verlies van snelheid. Het kan ook zijn dat het team zich onveilig voelt en een veiligheidsinspectie wil uitvoeren, wat uiteraard voor echte vertraging zorgt. De concurrentie kijkt smalend toe en ziet het eigen gelijk bevestigd.

Worden Agile teams weleens ontregeld?

Tijdens transformaties gebeurt het dat teams ontregeld raken. Simpel lijkende beletsels lijken niet verholpen te worden, waardoor teams vertrouwen verliezen en men op de rem trapt. Of het team laat zich afleiden, presteert minder en ontstaat wantrouwen, omdat er minder waarde geleverd wordt dan beloofd. Nog vervelender wordt het als het team partij wordt in een discussie. Bijvoorbeeld wanneer zij fel reageren op de zoveelste control vraag, waardoor de discussie aanwakkert en het feitelijke doel uit het oog wordt verloren.

Welke boutjes ontregelen Agile teams?

In de praktijk zie ik vier belangrijke oorzaken waardoor teams ontregeld raken. Oorzaak één is het schuren tussen de Agile initiatieven en de omgeving waar nog niet Agile gewerkt wordt. En die omgeving veroorzaakt ook oorzaak twee, het sturen vanaf de zijlijn. Een interne oorzaak is de derde. Dat betreft het niet functioneren van het team zelf. En oorzaak vier is het onvoldoende effectief ondersteunen van de teams. Hieronder beschrijf ik ze alle vier en voorzie in pragmatische tips om ze weg te nemen.

Schuren tussen Agile en non Agile: gooi geen boutjes op je eigen boot

Vaak wordt het commitment van de organisatie of het management genoemd als faalfactor van een Agile transformatie. Ik denk dat hier vaak sprake is van “boutjes op je eigen boot gooien”. Dat het eigen gedrag leidt tot het gooien van boutjes op je eigen schip om er dan vervolgens ook nog van te schrikken. Een Agile transformatie heeft nou eenmaal een disruptief karakter en daarmee schuurt het met de huidige manier van werken. Dan weet je dat er weerstand komt. Je kunt dan, uit angst voor verstoringen, de “oude wereld” op afstand zetten, maar dat lokt alleen maar meer weerstand uit. Dit op afstand zetten, noem ik boutjes op je eigen dek gooien.

Mijn tip? Wees nog transparanter en verwelkom iedereen om zelf te zien wat er gebeurt. Wijs goedbedoelde verzoeken niet bot af, maar vertel wat jij als team kunt en wilt en waarom. Dit helpt om je daarnaast te kunnen concentreren op het leveren van waarde. Natuurlijk is het soms beter om iemand of een afdeling op afstand te houden. Zorg dat dit een bewust besluit is en schrik niet van de vormen van weerstand die afstand nemen oproept.

Zijsturing? Soms vallen er boutjes met een goede bedoeling

Met zijsturing bedoel ik, om buiten de product owner om, rechtstreeks scrum teams te benaderen en zo een tweede “opdrachtgever” voor het team te worden. Deze initiatieven zijn vaak het gevolg van een wettelijke deadline of een urgent lifecycle probleem met een hoge prioriteit, die moeilijk zijn te vertalen in termen van business waarde. Zijsturing is een vaak gekozen redmiddel. Voor veel teams is deze zijsturing lastig af te wijzen, terwijl de risico’s op verstoring van de nauwe samenwerking met de business groot is.

Mijn tip: Wees pragmatisch en realistisch. Het is geen situatie van een nek-aan-nek race die je moet winnen, omdat anders de wereld instort. Ja, soms komt er een “moetje”, die even via de zijsturing gaat. Okay, niet leuk en handig, maar gewoon de realiteit waar je gewoon het stempel “te verbeteren” op plakt.

Teamproblemen zorgen ervoor dat het lijkt of er cruciale boutjes op het dek vallen

“Als ze dit al toestaan, dan geloven ze er toch niet echt in ……”, of “vonden ze de opgeleverde oplossing alweer niet goed? Zulke klanten moeten nog heel veel leren voordat er eens wat eer te behalen is”. Ongetwijfeld ga je deze “wanhoopskreten” horen tijdens de transformatie en vaak is er op dat moment ook iets aan de hand waardoor je zou kunnen twijfelen of de transformatie wel succesvol kan worden. Als het team of een teamlid op indringende wijze naar elementen of personen buiten het team begint te wijzen vergelijk ik dat met “boutjes op je eigen boot” gooien.

Een simpele tip? Het vormen van zelforganiserende teams is echt niet eenvoudig en het is daarom logisch dat er regelmatig iemand aan de rem trekt. Bespreek met het team wat er misgaat en wat jullie daar morgen aan gaan doen. Spreek het betreffende teamlid hierna één op één en kijk waar zijn hulpvraag zit.

Facilitering niet effectief? Zorg dat er drive is om het schip goed te onderhouden

Ons grote struikelblok is fysieke ruimte, las ik laatst als reden dat teams ontregeld waren. Huh, dacht ik nog, als er toch iets makkelijk te regelen is, als we het serieus nemen, dan is het wel fysieke ruimte. Blijkbaar is dat niet altijd zo. Soms is de buy-in van het betrokken management niet groot genoeg om actie te ondernemen om dit soort problemen op te lossen. Iets wat nogal eens voorkomt als een transformatie is opgestart vanuit de IT-organisatie en de operationele organisatie nog niet echt meedoet.

Mijn tip: zie je dat het faciliterende management faalt in het regelen van belangrijke randvoorwaarden? Help ze dan door nog meer te focussen op de samenwerking met je klanten en de hier behaalde gezamenlijke resultaten. Hierdoor is een grotere buy-in makkelijker te realiseren en wordt het faciliteren effectiever.

Meer tips?

Wil jij minder kans lopen dat jouw Agile transformatie ontregeld wordt? Wil jij pragmatisch en realistisch transformeren of wil je geholpen worden bij je ontwikkelvraagstukken met bijvoorbeeld een kenniscafé of een proeverij? Neem contact op met onze consultants Jens Caljé of Hans Rozemuller of met Michel Munier van onze Academy.