Kies je voor de professional, of het team?

Rate this post

individual vs teamAls manager wil je dat je professionals een bijdrage leveren aan het bedrijfsresultaat. Dus maak je individuele afspraken, stimuleert ze bij het uitvoeren ervan, en beloont de resultaten. Maar wat doe je als je afdeling grotendeels bestaat uit teams? Je wilt dat je professionals zich ontwikkelen, tegelijk kijk je ook naar het belang van teams, hun resultaten, en de samenwerking van professionals. Soms heb je dan een dilemma: Kies je voor de individuele professional, of voor het team resultaat?

Lerende Organisatie

Professionaliteit zit in de medewerkers. De vaardigheden, ervaring, motivatie en inzet bepalen wat een professional bijdraagt voor een bedrijf. Dat de verschillen tussen een excellente en een “gemiddelde” professional groot kunnen zijn is bekend. Daarom vind ik het belangrijk dat professionals zich ontwikkeling, blijven leren, en continue verbeteren. En daarin gestimuleerd wordt, erop aangesproken, en ook beloont wordt voor het resultaat.

Empowered teamTegelijk geloof ik ook in samenwerken in teams. Een goed geolied team is veel meer dan de som van de individuele professionals. We zien het bij agile, waar teams zorgen voor continue leveringen van software. In projectteams, die op tijd en binnen budget een oplossingen leveren aan hun opdrachtgever. In klantteams, waarin professionals samen er voor zorgen dat een klant krijgt wat ie nodig heeft. Waardering voor het teamresultaat, en daarmee voor het team is essentieel om een goed samenhangend team te creëren, te behouden, en continue te verbeteren.

Het dilemma wat ik zie is hoe je als manager omgaat met het individueel belang en het teambelang. Kies je voor de professional, of voor het team? Beloon je iemand voor zijn of haar resultaten, of voor de bijdrage die ze geven in het team?

De systeemtester en het team

Testing do not disturbEen team waar ik mee samenwerkte had 1 zeer ervaren systeemtester. Hij was de enige die bepaalde testtaken kon doen, en dat beperkte vaak de voortgang. In het team was afgesproken om hem zo min mogelijk te storen in zijn werk, en werd het ook geaccepteerd dat hij de stand-up oversloeg als het even niet uit kwam. Desondanks lukte het vaak niet om alles getest te hebben aan het einde van de sprint, en men verwachte dat dit probleem groter zou worden naarmate het project vorderde. Immers, er kwam steeds meer testwerk, en minder programmeren.

In de planning game van de volgende sprint gaf een van de functietesters aan dat hij systeemtesten wilde leren. In eerste instantie dacht hij aan het volgen van een testtraining, tot dat een teamlid voorstelde om samen met de systeemtester te gaan pairen. Dat zou in de huidige sprint nog niets opleveren (integendeel, er kon dan minder getest worden), maar in de volgende sprints kon het systeemtesten steeds vaker ook door de functietester gedaan worden. De systeemtester stond open voor het idee, maar vroeg zich wel af wat de organisatie wil, en wat zijn manager ervan zou vinden? Hij zag niet direct het nut ervan voor hemzelf, “what’s in it for me”, maar wilde het team en de tester wel helpen. De lijnmanager, die bij de planning game aanwezig was, vond het een goed idee. Hij doorzag de situatie, en herkende het nut voor het team, en voor het project. De product owner was er in eerste instantie niet blij mee, immers het sprintdoel zou dan mogelijk niet gehaald kunnen worden. Maar hij liet zicht overtuigen door het team en de lijnmanager, en gaf hun de ruimte om het te doen.

Pair testing

In het begin was het best wel wennen voor de systeemtester. De eerste keren zat de functietester erbij en keek mee bij het testen, maar al snel gaf die aan dat hij het zelf wilde proberen. Al doende leerde de functietester meer over systeemtesten, tot dat hij stukjes kon gaan testen zonder dat de systeemtester erbij zat. Gelukkig, want hoe leuk ze het pairen beide vonden, het was best intensief en je moest het niet te lang doen!

De teamleden zagen hoe de twee testers samenwerkten, en informeerde incidenteel hoe het ging. Ook in de stand-up (waar beide testers elke keer bij waren) werd de voortgang besproken, en gekeken hoe het sprintdoel met het team bereikt kon worden. Tijdens de demo bleek dat de user stories van het agile team een hogere kwaliteit hadden, en ook in de volgende sprints werden er weinig fouten gevonden. De product owner roemde de beslissing van het team om te pairen en op die manier testervaring te vergroten in het team. Iedereen had er een goed gevoel bij, en in de retrospective werd afgesproken om vaker in het team te gaan pairen om daarmee van elkaar te leren, en de kwaliteit te verhogen.

De beloning

De manager vond in deze situatie het teambelang groter dan het individuele belang. Hij accepteerde het (tijdelijk) minder testen door de systeemtester omdat hij daarmee een nieuwe systeemtester kon opleiden. Hij zag het als een mogelijkheid om te veranderen door te leren, en zijn medewerkers te empoweren. In het beoordelingsgesprek met de systeemtester benadrukte hij hoe de systeemtester in staat was geweest om een collega te trainen en coachen. De manager beschouwde het als een nieuwe vaardigheid van de systeemtester, en beloonde hem daarvoor met een loonsverhoging. Hij gaf aan dat er binnen het bedrijf meer mogelijkheden waren om nog mensen te trainen, en op langere termijn zag hij kansen als afdelingshoofd van een testafdeling. Immers, het trainen en coachen was een leidinggevende vaardigheid, en daarmee was een nieuw carrierepad mogelijk geworden. Het goede voorbeeld deed volgen, in diverse teams waren er professionals die een deel van hun tijd besteedde om collega’s te trainen en coachen, zowel voor testen als voor programmeren. Daarmee was de verandering blijvend geborgd in de organisatie.

En de systeemtester? Die was blij dat hij zijn teamlid had kunnen helpen, en heeft dat daarna nog regelmatig in zijn eigen team en ook in andere teams gedaan. Hij gaf af en toe presentaties op conferenties en in vaknetwerken (zelf stak ie daar tijd in, zijn werkgever vergoedde de onkosten), en bleef op die manier ook op de hoogte van de nieuwste ontwikkelingen. Manager is ie niet geworden, zijn liefde voor het testvak en de waardering die hij ervoor kreeg waren voor hem veel belangrijker dat een carrière als manager.

Conclusie

In het bovenstaande geval koos de manager voor het team, en toonde agile leiderschap. Hij vond het belangrijker dat in het team ervaring opgebouwd werd met systeemtesten, boven een systeemtester die “productie levert”. Daarmee ontwikkelde de systeemtester wel nieuwe vaardigheden, waarvoor hij ook door zijn manager werd beloond.

Welke keuze maak jij, als het gaat om professionals, of het team? Maak je individuele afspraken met je professionals, en beloon je hun voor wat ze bereiken? Of stel je het team voorop, en beloon je iedereen als het team resultaten bereikt? Ik hoor graag hoe je met dit soort dilemma’s omgaat!

Ben Linders

I help organizations with effective software development and management practices. Active member of several networks on Agile, Lean and Quality, and a frequent speaker and writer.

This Post Has 4 Comments

  1. Jan Jaap Cannegieter

    Beste Ben,

    Leuk en ook herkenbaar verhaal. Mijn ervaring is dat pair testing, pair programming, pair requirements engineering tot de beste opleidingstechnieken behoort die er zijn. Natuurlijk moet ‘de leerling’ voldoende basiskennis hebben voordat pairing succesvol kan zijn.

    Overigens ken ik ook mooie voorbeelden van ervaren collega’s die pairen om te blijven leren. Zouden we vaker moeten doen hoor je dan vaak.

    1. Ben Linders

      Leuk om te lezen dat je pairing toepast. Ook mijn ervaringen daarmee zijn positief, hele effectieve manier om vaardigheden van een team te vergroten. Ik pair zelf ook regelmatig, wat de kwaliteit van de diensten die lever nog verder verbeterd.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.