Een van de verschillen in mentaliteit dat vaak leidt tot problemen in samenwerkingsverbanden tussen culturen is kwaliteit versus snelheid. Naar mijn mening is dit een cultureel verschil dat aandacht moet krijgen in elke offshore samenwerking. Het kan zowel door nationaal cultuurverschil komen zowel als door een verschil in bedrijfscultuur.
Om het punt te illustreren, zal ik een voorbeeld geven. In een van onze projecten werkt een Indiase programmeur samen met een Nederlands software ontwikkelteam. Zowel de Scrum master als de product owner zitten in Nederland. Het team maakt gebruik van twee wekelijkse sprints en beslist over de user stories tijdens de sprint planning meeting voorafgaand aan de sprint (zij gebruiken ook planning poker).
De programmeur in India verbindt zich aan een bepaalde sprint. Zijn mentaliteit is gefocust op het leveren van alle user stories van die sprint binnen die sprint. Dit gebeurt vaak in projecten waar ik bij betrokken ben; op de een of andere manier behouden ontwikkelaars de mentaliteit van het halen van deadlines, terwijl Scrum verklaart dat een verzendbare levering tegen het einde van de sprint belangrijker is dan het afwerken van elke user story binnen de sprint. Omdat de ontwikkelaar (die in dit geval in zijn eentje op afstand werkt) zich verbindt aan de sprint, zou hij ook kunnen besluiten om een aantal user stories naar de volgende sprint of naar het product backlog te verplaatsen. Maar hij vindt het belangrijk om alles af te hebben. Het resultaat van vorige week was dat de user stories klaar waren, maar niet op de kwaliteit die de klant had verwacht.
Vanuit het perspectief van de programmeur, heeft hij heel hard gewerkt om aan de klant te laten zien dat hij resultaten kan leveren. Maar uiteindelijk krijgt hij een klant die niet volledig tevreden is.
In een ander project deed zich een gelijke situatie voor. De programmeur wilde de werkzaamheden afronden binnen de sprint. Vanwege de tijdsdruk koos ze ervoor om de oplossing volgens haar eigen inzicht te coderen. De klant begreep niet waarom ze voor deze oplossing had gekozen. Als de Scrum-master het zelf gedaan had, vertelde hij me, dan zou hij in eerste instantie meer tijd genomen hebben voor het begrijpen van het product en de business waar ze aan werkten (het is een recent opgestart project, waardoor de ontwikkelaar nog geen systeem-en domeinkennis heeft ). Eveneens zou hij meer tijd hebben besteed aan onderzoek op het internet voor een herbruikbare code of een handig framework (en hij voegde eraan toe dat de meeste Nederlandse programmeurs dit ook gedaan zouden hebben). Maar onze (Indiase) programmeur heeft dat niet gedaan.
Wat zijn de oorzaken van deze problemen in cross-culturele samenwerkingsverbanden? (Ik heb twee voorbeelden uit India genomen, maar ik zou er ook een uit Oekraïne kunnen beschrijven)
Ik geloof dat het geworteld zit in de mentaliteit van de programmeurs. Zij zien zichzelf als ‘coders’ en zijn trots op het voor elkaar krijgen van werk. Door deze mentaliteit hebben ze het gevoel dat ze geen tijd hebben om te onderzoeken, om met behulp van Google te zien hoe anderen soortgelijke problemen opgelost hebben. Omdat ze werk te doen hebben, steken ze geen tijd in het duidelijk krijgen van het product of het domein waar ze mee bezig zijn. Ze willen duidelijke taken krijgen en bezig gaan met het coderen. In India stimuleert het systeem dit ook naar mijn mening. De meeste bedrijven opereren in een sterke hiërarchie zoals wij die in Europa niet kennen. Er is een account manager die verantwoordelijk is voor relaties met klanten, een project manager voor de gehele project planning en communicatie, een teamleider die het werk onder de ontwikkelaars verdeelt en dan hebben we een programmeur zonder grote verantwoordelijkheden anders dan het produceren van code. Daarnaast is er trouwens ook nog een tester die de code zal testen.
De meeste Europese bedrijven hebben een tegenovergestelde mentaliteit, ze verkiezen kwaliteit boven snelheid. Ze hebben liever een programmeur die hen vertelt dat hij een user story niet af kan maken en die voorstelt om deze naar de volgende sprint op te schuiven omdat hij meer tijd nodig heeft voor onderzoek en om andere user stories te testen.
Ik zie een paar praktische manieren om dergelijke kwesties te voorkomen.
1. De ontwikkelaar consequent stimuleren om tijd te investeren in onderzoek. Hem consequent er aan te herinneren dat kwaliteit belangrijker is dan snelheid. Dit zal gunstig zijn op de lange termijn.
2. Plan productonderzoek, het testen en domeinonderzoek binnen de sprint. Maak er een aparte taak voor. Wijs een bepaald aantal uren toe aan de taak, zodat de ontwikkelaar weet dat het in orde is en dat er van hem verwacht word dat hij onderzoek doet en dat hij het werk zeer goed test voordat hij de code vastlegt.
3. Heb een duidelijke definitie van ‘gedaan’ (dus de ontwikkelaar zal altijd weten wat er van hem verwacht wordt) en voeg acceptatiecriteria toe voor de user stories.
4. Neem voldoende tijd in sprint planning sessies om oplossingen te bespreken, voordat de ontwikkelaar begint met het coderen. Stimuleer de ontwikkelaar om de voorgestelde oplossing uit te leggen, een schatting van de werklast te maken en overeenstemming te bereiken over die oplossing. Als hij het nog niet weet, voeg dan onderzoekstijd aan de user stories toe en laat hem de oplossing voor je beschrijven in de sprint voorafgaand aan de uitvoering.
5. Maak duidelijkheid over de hiërarchie binnen het Scrum-team. Ontwikkelaars, met name in India, zien de Scrum master vaak als een superieur (vooral als hij uit een ander land komt en werkzaam is bij de klant). Ze hebben geleerd dat het niet oké is om een superieur persoon te verbeteren, waar doo rze oplossingen misschien niet met je zullen delen en afzien van het stellen van vragen. Ze nemen aan dat hun meerdere het wel het beste zal weten en voor hen zal bepalen wat ze moeten doen. Blijf herhalen dat alle rollen gelijk zijn en beloon ideeën, suggesties en eigen initiatief.
Hugo, vanuit mijn Poolse perspectief herken ik heel veel in jouw artikel. Van harte ondersteun ik het kwaliteitsperspectief, maar ik merk dat klanten (zowel in Nederland, maar ook in bijvoorbeeld de VS) toch vooral gericht zijn op resultaat tegen de beste prijs. Hiermee leggen ze al of niet bewust heel veel druk op een team, terwijl dit feitelijk niet conform de Scrummethode is.
Mensen die dan meer hierarchisch denken, dat is namelijk ook van toepassing op Oost-Europeanen, zijn dan eerder geneigd om te proberen te voldoen aan de vraag. Dat komt overigens niet alleen voort uit onderdanigheid, maar ook vanuit hun trots.
Het blijft ook met een Agile aanpak zoals Scrum dus een uitdaging om de juiste balans te vinden tussen flexibiliteit leveren, tegen een acceptabele prijs met behoud van voldoende kwaliteit. Daar dient de opdrachtgever zich ook van bewust te zijn.
Als er ergens beknibbeld wordt, dan zal dat op andere plekken tot negatieve verschuivingen leiden. Dat is een oude projectmanagement wet die ook bij Scrum gewoon van toepassing blijft.
Het is een oude programmeurswet die stelt dat het management altijd wenst dat jij je aanpast aan hun ideeen. Maar je hoeft geen psychologie gestudeerd te hebben om te weten dat dit gedeeltelijk mogelijk is.
Het is slim om binnen het team zoveel mogelijk gebruik te maken van de sterke eigenschappen van iedereen om het maximale uit het team te halen. Dat geldt eveneens voor de methodiek die je gebruikt. Als die niet aansluit bij het team stem je het zo goed mogelijk op elkaar af. Want als Agile geen rekening houdt dat andere culturen meer hierarchisch denken dan voldoet het niet aan haar eigen doelstelling.
Een ander aspect wat de verschillen in manier van werken kan verklaren: eigen initiatief wordt niet in alle landen/culturen gewaardeerd!
Zeker in een land als India, waar je groepsleider misschien wel uit een hogere kaste komt dan jij, haal je het niet in je hoofd om hier tegenin te gaan of een andere manier van werken voor te stellen.
Als je gaat samenwerken met iemand, ongeacht of die nu in Nederland, Oekraïne of India werkt, heb je bepaalde verwachtingen van die persoon.
In Nederland hebben we doorgaans dezelfde normen, waarden en culturele achtergrond, waardoor we al snel een goed gevoel hebben wat we (al dan niet) kunnen verwachten.
Hoe groter deze verschillen, hoe groter de kans is dat de verwachting en de realiteit uit elkaar gaan lopen…..
Realiseer dat programmeren, ook coderen zoals Hugo het noemt een vorm van ontwerpen is en NIET van bouwen. Maak dat elk geval duidelijk aan je ontwikkelaars. Verder zijn daily standups en veelvuldig samenwerken (pair programming) ook een essentieel onderdeel van scrum. Pas aan het eind van de sprint achter problemen in code of functionaliteit komen zou dan niet meer mogelijk moeten zijn.