Over Agile voetbalteams en Champions League software

Waarom kan een topcoach een voetbalelftal vol met vedettes en talenten niet eenvoudig tot grote hoogte laten stijgen? Die vraag hield me bezig. Als trainer van een jeugdteam en als testmanager bij enkele Agile software ontwikkeltrajecten bemerkte ik verrassende overeenkomsten. Samen spelen, en dan bedoel ik écht samenspelen, blijkt niet zo eenvoudig. Een les voor iedereen die zegt dat ze ook Agile gaan doen met een beetje DevOps.

Bij het voetballen komt het succes als het team een eenheid wordt. Die eenheid is vaak gebaseerd op een gezonde dosis plezier, elkaar goed begrijpen en ingespeeld zijn op elkaar. Een ingespeeld team kent de tactiek, weet wat ze van elkaar kunnen verwachten en zo ben je de problemen (lees: de tegenstander) telkens net een stapje voor.
Ik vind het heel bijzonder om te zien dat bij de overgang naar Agile werken vergelijkbare processen in werking treden. Een organisatie of manager kan besluiten dat er Agile gewerkt gaat worden. Maar het volstaat niet om een aantal SCRUM-artefacten te implementeren. De meest cruciale succesfactor is de teamwording en de grondhouding van de teamleden. Als een team open en transparant gaat werken, elkaar op de sterke punten benut en zo volwassen wordt dat het autonoom de juiste beslissingen neemt, dan komen de succesmomenten in beeld. Gaat dat snel? Nee, dat heeft tijd nodig. Zeker als je met dezelfde mensen vanuit een andere werkwijze komt.
Funest voor je succes is de halfbakken omslag. Dan lijk je op het voetbalteam dat geen duidelijke tactiek heeft. Spelers lopen elkaar in de weg. Waar de een vooruit wil, gaat de ander verdedigen en je hoeft niet lang te wachten of het gemopper is langs de zijlijn te horen. Zo gaat het ook in een ontwikkelteam waar het vertrouwen ontbreekt. Gebrek aan vertrouwen in de nieuwe werkwijze of in elkaar. Een mislukte missie wordt dan een selffulfilling prophecy.

Agile of waterval? Wat is het meest succesvol? Dat maakt niet zoveel uit. In de lijn van dit verhaal zie ik de watervalmethode meer als een verdedigend concept. We houden eerst de nul vast. We gaan voor zekerheid. Dat past bij “in één keer goed”; we borgen de quality gates en laten ons niet verrassen. Bij Agile softwareontwikkeling kiezen we voor snelheid in combinatie met kwaliteit. Het lijkt op een aanvallende speelstijl. We spellen attractief, scoren veel, houden gebruikers continu tevreden. Af en toe slipt er wat door heen, maar dan zijn we in staat om snel opnieuw te scoren.
Maakt het niet zoveel uit? Nee, mits je maar met z’n allen het spel op dezelfde manier speelt. Wel kan het tactisch zijn om de speelwijze aan te passen aan de omstandigheden. Er zijn systemen waarbij een watervalmethode soms beter past evenals omstandigheden die zich uitermate goed lenen voor Agile ontwikkeling. Bedenk wel dat het continu switchen van speelstijl het overall resultaat geen goed zal doen. Dat geeft verwarring bij de spelers.
In de wereld van keuzes maken heeft Gartner ook de prachtige term ‘bimodal IT’ belegd. In dit model wordt verantwoord gekozen over de assen van ‘stability’ en ‘agility’. In dergelijke situaties vergt het nog meer van organisaties, teams en personen. Voorkom dat de spelers niet weten wat de te volgen tactiek is. Dat zaait verwarring, met alle gevolgen van dien. Weet welke tactiek je moet volgen en zorg dat je die beheerst.

En mijn team? Ach, we bungelen ergens in de krochten van het jeugdvoetbal. De haperende bondscoach is mijn vluchtroute op momenten dat ik als jeugdtrainer mindere resultaten moet verantwoorden. Maar ze hebben plezier en telkens als we merken dat we samen verder komen dan alleen, dan is onze missie geslaagd.

Vond je dit artikel interessant? Deel het op social media!