Een nearshore-ontwikkelteam aansturen (zonder dat het een tweede baan wordt)

De meeste adviezen over hoe je een nearshore-ontwikkelteam aanstuurt lezen als een checklist van vergaderingen. Standups, retro's, een gedeelde Slack, een kickoffweek: allemaal waar, allemaal nodig, en allemaal naast de kern. Het moeilijke deel is niet de ceremonie. Het is dat "aansturen" stilletjes een tweede baan wordt voor iemand aan jouw kant die al een eerste had. Dit is wat een nearshore-team echt als één team laat voelen, en het stuk dat de meeste gidsen overslaan.

Begin met overlap, niet met tooling

Elke tool werkt als de mensen die hem gebruiken op hetzelfde moment wakker zijn. De grootste voorspeller of een verspreid ontwikkelteam dichtbij voelt, is de overlap in werkuren. Met volledige overlap op Midden-Europese tijd is een vraag die om 10:00 wordt gesteld om 10:05 beantwoord, dus de tooling is gewoon leidingwerk, geen omweg rond een tijdgat. Zit je team zes uur verderop, dan koopt geen enkele hoeveelheid Jira-hygiëne de dag terug die je bij elke verduidelijking verliest.

Behandel ze vanaf dag één als jouw team

De teams die worstelen, zijn de teams die de nearshore-developers stilletjes op afstand houden: een apart kanaal, een aparte standup, een aparte standaard. De teams die het laten werken doen het tegenovergestelde: dezelfde rituelen, dezelfde toegang, dezelfde lat. Frameworks als Scrum betalen zich pas uit als iedereen echt binnen hetzelfde proces zit, niet een parallel proces draait.

• Dezelfde standup, hetzelfde board, dezelfde definition of done.
• Directe toegang tot de mensen die het product bezitten, geen doorgeefluik via een coördinator.
• Feedback die beide kanten op stroomt, vroeg en vaak.

Maak van onboarding een echt moment

Kennisoverdracht is waar het momentum gewonnen of verloren wordt. Schrijf de dingen op die meestal in iemands hoofd zitten: architectuurbeslissingen, het "waarom" achter conventies, wie je waarvoor moet hebben. Koppel een nieuwe developer de eerste weken aan iemand aan jouw kant. Niets hiervan is exotisch; het is gewoon dezelfde onboarding die je een interne aanwinst zou geven, en dat is precies het punt.

Stuur op resultaten, niet op uren

Uren tellen is een teken dat je het werk niet vertrouwt. Spreek af hoe "klaar" eruitziet, en beoordeel daartegen. Goed agile projectmanagement is van nature resultaat-eerst: het geeft je frequente, zichtbare ijkpunten zodat je midden in de build bijstuurt in plaats van problemen bij oplevering te ontdekken.

Het deel dat de meeste adviezen overslaan: iemand moet de aansturing bezitten

Hier is de stille waarheid. Alle bovenstaande punten gaan uit van een capabele manager die dichtbij blijft, en bij de meeste nearshore-constructies is die manager jij. Het model van "we plaatsen iemand, succes ermee" geeft je een developer en geeft je stilletjes een managementbaan. Dat is de kostenpost die niemand offreert.

Het is ook precies waarom we ons model zo hebben gebouwd: het team wordt dagelijks vanuit Nederland aangestuurd, door oprichters die hun eigen teams uit dezelfde selectie aansturen. Jij bezit de roadmap; de aansturing van de mensen (de feedback, het behoud, de moeilijke gesprekken) is van ons. Een nearshore-ontwikkelteam aansturen werkt prachtig wanneer iemand wiens baan het daadwerkelijk is, het doet.

Wil je het team zonder de tweede baan, dan is dat het hele idee. Bekijk hoe het werkt voor opdrachtgevers.

Bronnen: Scrum.org, Atlassian: agile projectmanagement.