Alle berichten

Zes uitdagingen van veel verandering binnen teams

Vroeger bleven medewerkers langer bij hun werkgever dan tegenwoordig. Nu blijft personeel gemiddeld circa 3,75 jaar bij dezelfde werkgever. Dit kan frustrerend zijn voor scrumteams omdat juist de teams met developers, die goed op elkaar ingespeeld zijn, die weten hoe de techniek werkt én weten welke zaken waarde toevoegen aan het bedrijf, echt zelfsturend kunnen zijn.

Gelukkig zijn er uiteraard ook loyale werknemers, die juist langer blijven. Echter, als we uitgaan van een team van gemiddeld 6 personen zal je in 50% van alle gevallen, binnen 36 weken een vervanger moeten vinden. Sterker nog, de kans dat iemand binnen 3 maanden vertrekt, is circa 25%. HR en IT-managers zijn vaak bekend met deze uitdaging. Uiteraard ga je er in het aannamebeleid vanuit dat het goed gaat en dat de werknemer lang in dienst blijft. Het lastige is dat áls iemand vertrekt, er opeens een groot kennisgat kan ontstaan dat heel moeilijk is in te vullen.

Lees hieronder 6 redenen waarom dit een groot probleem kan vormen voor de continuïteit van het team, of zelfs van een bedrijf.

1. Teveel kennis die bij de persoon blijft

Het gevaar van een team dat alleen uit ervaren spelers bestaat, is dat het team ook beter afbakent wie wat doet. Dit is heel normaal, maar het betekent dat Pietje alles weet over onderwerp A en Jantje alles over onderwerp B. Omdat Pietje en Jantje er allebei altijd waren voor de afgelopen decennia, was het nooit nodig anderen erover te informeren of het goed op papier te zetten. Zodra Pietje of Jantje vertrekt, is ook een hoop kennis vertrokken. Dit omdat de kennis niet gekoppeld werd aan het team, maar aan de persoon.

2. Hoge kosten of lange wachttijd

Iedereen wil een plug and play-kandidaat hebben. Dit betekent dat de vervanger eigenlijk net zo goed moet zijn als de persoon die vertrokken is en meteen moet passen in het team. Deze eisen zijn vaak zo specifiek, dat extra hoge kosten betaald moeten worden of je langer dan gewenst moet wachten op een nieuw teamlid dat snel up and running is.

3. Gevaar op gezamenlijk vertrek

Stel dat je beste werknemer morgen opzegt. Dit is lastig, maar hopelijk overkomelijk. Stel nu alleen dat overmorgen je op één na beste werknemer opzegt. Dit lijkt onwaarschijnlijk, maar komt vaker voor dan je denkt. De werknemer is mogelijk met een reden vertrokken die andere werknemers aan het denken zet. De achtergebleven werknemers moeten opeens het werk overnemen dat de vertrokken werknemer altijd zo goed deed, terwijl het eigen werk soms al teveel is. Als de beste werknemer weggaat, moet je je afvragen of de op één na beste werknemer genoeg reden heeft om te blijven.

4. Geen ervaring met aannamebeleid

Het aannemen van nieuw personeel of het aanstellen van een nieuw teamlid, is een activiteit die goed uitgevoerd moet worden. Dit gaat verder dan alleen het uitschrijven van een vacature en het voeren van een intakegesprek. Het betekent dat je ook de nieuwe werknemer inwerkt, zorgt voor faciliteiten en dat het team zich aan elkaar kan aanpassen. Als er al een poos niets veranderd is, kan het fijn zijn dat je dit niet hebt hoeven doen. Als de draad echter weer opgepakt moet worden in een volledig nieuwe samenstelling, kan dit extra tijd en moeite kosten.

5. Fluctuerende velocity

Binnen de software-ontwikkeling is het van belang dat de oplevering of kwaliteit van oplevering geschied met een snelheid die constant is. De velocity van een scrumteam is gebaseerd op de snelheid waarmee het team zaken kan opleveren, én op de mate waarin het team kan inschatten hoeveel tijd iets kost. Bij een constante ‘aanvliegsnelheid’ kunnen stakeholders erop gaan vertrouwen dat hun software binnen een bepaalde tijd opgeleverd wordt. Dit geeft management ook weer de mogelijkheid om er eventueel op in te spelen. Bij onverwacht vertrek van een teamlid zal deze velocity zeer sterk fluctueren. Dit maakt het lastiger voor stakeholders om goed te plannen.

6. Scrum zoals bedoeld

Binnen de filosofie van scrum bestaat er binnen het team geen onderscheid. Scrum kent binnen het development team maar één rol en dat is die van developer. Dat betekent dat scrum conform de regels stelt dat iedereen elkaars werk moet kunnen overnemen en snel op moet kunnen pakken.

Dit is natuurlijk niet altijd helemaal vlekkeloos te regelen. Testen, businessanalyse, data-analyse en programmeren zijn namelijk echt verschillende disciplines. Toch moeten teamleden het werk ten dele kunnen controleren en in staat zijn basis-concepten over te nemen.

Teamleden die lange tijd dezelfde rol innemen, zullen bepaald werk echter volledig naar zich toe trekken. Andere teamleden zullen zich hier ook op instellen. Dit gaat eigenlijk tegen het principe in van scrum, omdat verantwoordelijkheid soms moeilijk te delen is.

Tot slot

Het opstellen van goed functionerende teams is een belangrijke taak. Het is hierbij van belang dat het team flexibel blijft, zodat vertrekkende leden makkelijk vervangen kunnen worden. Het is van belang om daar actief op in te spelen. Dit betekent: voer een beleid dat ervan uit gaat dat mensen niet voor eeuwig blijven in het team.

Wouter Mertens

Innovatiemanager - AP Support

Nieuws

Gerelateerd nieuws

Lees meer >