Quality versus speedKwaliteit versus snelheidKvalitet kontra snabbhetQualität versus Geschwindigkeit

One of the mindset differences that often lead to issues in cooperations across cultures is quality versus speed. I believe this is a cultural difference that needs to receive attention in any offshore collaboration. It can result both from a country’s cultural perspective as well as a company culture.

To illustrate the point, I will share an example. In one of our projects, an Indian programmer cooperates with a Dutch software development team. The scrum master is in the Netherlands and the product owner as well. The team uses two weekly sprints and decides on the user stories to be completed in the sprint planning meeting preceding the sprint (they use planning poker as well). 

Een van de verschillen in mentaliteitdat 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 ontwikkel team. Zowel de scrum master als de product owner zijn in Nederland. Het team maakt gebruik van twee wekelijkse sprints en beslist over de user storiestijdens de sprint planning meeting voorafgaand aan de sprint (zij gebruiken ookplanning poker).

De programmeur in India verbindt zich aaneen ​​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 betrokkenben; 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 werkte (het is een recent opgestart project, waardoor de ontwikkelaar nog geen systeem-en domeinkennisheeft ). Eveneens zou hij meer tijd hebben besteed aan onderzoek op het internet voor een herbruikbare code of een handigframework (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ïnekunnenbeschrijven)

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 mentaliteithebben 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 doenhebben, 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 ander user stories te testen.

Ik zie een paar praktische manieren om dergelijke kwesties te voorkomen.

1. De eerste is om de ontwikkelaar consequent te stimuleren om tijd te investeren in onderzoek. Om 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 een er 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 methet 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 danonderzoekstijd aan de user storiestoe en laat hem de oplossing voor u 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, waardoorze oplossingen misschien niet met u 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.

En av skillnaderna på tankesätten som ofta leder till problem i samarbeten mellan olika kulturer är kvaliteten kontra snabbheten. Jag tror att detta är en kulturell skillnad som behöver uppmärksamhet i alla offshore-samarbeten. Det kan vara ett resultat av ett visst lands kulturella perspektiv likväl av en viss företagskultur.

För att illustrera den här poängen ska jag dela med mig av ett exempel. I ett av våra projekt samarbetar en indisk programmerare med ett holländskt mjukvaruutvecklingsteam. Scrum-mastern finns i Nederländerna och produktägaren likaså. Teamet använder sig av två sprinter veckovis och beslutar vilka user stories som ska slutföras på sprintplaneringsmötet före sprinten.

 Programmeraren i Indien följer en speciell sprint. Hans tankesätt är att leverera alla user stories från den sprinten inom en given sprint. Det här händer ofta i projekt där jag är involverad; på något sätt har utvecklarna tankesättet att de måste hålla en deadline, men scrum menar att en sändbar leverans vid slutet av sprinten är viktigare än att göra klart varenda user story i sprinten. Eftersom utvecklaren (som i detta fall jobbar ensam på distans) följer sprinten, skulle han också kunna flytta några user stories till nästa sprint eller till produktens eftersläpning. Men han är ivrig att slutföra allt. Resultatet den sista veckan blev att alla user stories var klara men inte med den kvaliteten som kunden hade förväntat sig.

 Från programmerarens perspektiv har han jobbat väldigt hårt för att visa kunden att han kan uppnå resultat. Men i slutänden får han en kund som inte är fullt så nöjd.

I ett annat projekt hände en liknande sak. Programmeraren ville få arbetet gjort inom sprinten. P.g.a. tidspress valde hon att koda lösningen enligt hennes egen uppfattning. Kunden förstod inte varför hon valt denna lösning. Scrum-mastern berättar att om han hade gjort det själv, skulle han först ha tagit sig mer tid till att förstå produkten och verksamheten som hon jobbade inom (det är ett projekt som nyss startats upp så utvecklare har inte all kunskap inom systemet och domänen än). Utöver det skulle han ha tagit sig mer tid att forska på internet efter användbar kod eller ett hjälpsamt ramverk (och han la till att de flesta holländska programmerarna också skulle ha gjort så). Men vår indiska programmerare gjorde inte det.

 Vad orsakar att dessa problem uppstår i samarbeten mellan olika kulturer? (Jag har använt två exempel från Indien men jag skulle lika gärna kunna beskriva något från Ukraina).

Jag tror att källan till detta ligger i programmerarnas olika tankesätt. De ser sig själva som ”kodare” och är stolta när de har avklarat ett jobb. P.g.a. detta tankesätt känner de att de inte kan spendera tid med att efterforska, spendera tid med att använda Google för att se hur andra har löst liknande problem. P.g.a. att de har jobb att göra, investerar de inte tid i att djupdyka i produkten eller domänen som de jobbar med. De vill ha tydliga uppgifter och vill bara börja jobba med kodningen. Jag tror att detta system även stimuleras i Indien. De flesta företag är uppbyggda med en stark hierarki som är okänd för Européer. Det finns en account manager som är ansvarig för klientrelationerna, en projektledare som ansvarar för projektets planering och kommunikation och en team ledning som distribuerar arbetet till utvecklarna och så har vi en programmerare utan större ansvar än att koda. Utöver detta har vi en testare som testar koden.

De flesta européiska företag har ett motsatt tankesätt, de föredrar kvalitet före snabbhet, de föredrar en programmerare som berättaratt han inte kan slutföra en user story och istället föreslår att flytta den till nästa sprint för att han behöver mer tid att efterforska och testa en annan user story.

Jag ser ett fåtal praktiska sätt att motverka detta från att hända:

1.    Det första är att konsekvent stimulera utvecklaren att investera tid på efterforskning, att påminna honom om att kvalitet är viktigare än snabbhet. Detta har en långsiktig fördelaktig påverkan.

 2.     Planera för efterforskning, testning och domänutredning inom sprinten. Skapa en separat uppgift för detta, tilldela ett visst antal timmar på denna uppgift så att utvecklaren vet att det är okej och förväntat att göra efterforskning, för att testa arbetet väl innan kodningen sker.

3.    Ha en klar definition av “färdig” (så att utvecklaren alltid vet vad som förväntas av honom) och lägg till ett acceptanskriterium till de user stories som finns.

 4.     Ta tillräckligt med tid på sprintplaneringen till att diskutera lösningar, innan utvecklaren börjar koda. Stimulera utvecklaren att förklara förslaget till lösningen, beräkna arbetsmängden och nå en överenskommelse på det förslaget. Om han inte vet än, lägg till efterforskningstid till user storyn och låt honom förklara lösningen för dig under sprinten före genomförandet.

5.     Skapa en klarhet av hierarkin inom scrum-teamet. Utvecklare, särskilt i Indien, ser ofta scrum-mastern (särskilt om han är från ett annat land och jobbar på kundens företag) som en överordnad person. De har lärt sig att det inte är okej att rätta en överordnad överlag, så de kan hålla tillbaka med att dela sina lösningar och låta bli att ställa frågor. De antar att den överordnade alltid vet bäst och kommer att föreskriva vad som ska göras. Fortsätt repetera att alla roller är på samma nivå och belöna idéer, förslag och eget initiativ.

Die Unterschiede in der Denkweise, die oft zu Problemen in Kooperation zwischen verschiedenen Kulturen führen, sind oft zu dem Thema Qualtität versus Geschwindigkeit. Ich glaube, das ist ein kultureller Unterschied, der in jeder Offshore-Zusammenarbeit Aufmerksamkeit empfangen muss. Die Perspektive kann sowohl von der Unternehmenskultur stammen als auch von der Kultur des eigenen Landes.

Um den Punkt deutlich zu machen, werde ich ein Beispiel aufzeigen. In einem unserer Projekte arbeit ein indischer Programmierer mit einem holländischen Softwareentwicklungsteam. Der Scrum-Master ist in den Niederlanden und auch der Produkteigentümer. Das Team nutzt zwei wöchentliche Sprints und entscheidet über die User Storys, die vor dem Sprint abgeschlossen werden, im Sprintplanungsmeeting. (Sie benutzen auch Planning Poker)

The programmer in India commits to a certain sprint. His mindset is on delivering all user stories from that sprint within the given sprint. This happens often in projects that I am involved with; somehow developers keep the mindset of having to make a deadline, but scrum declares a shippable delivery by the end of the sprint more important than finishing every user story in the sprint. Because the developer (in this case working on his own remotely) commits to the sprint, he could as well move some of the user stories to the next sprint or the product backlog. But he is keen on finishing all. The result last week was that the user stories were finished but not at the quality level expected by the customer.

From the programmer’s perspective, he has been working very hard to show the customer that he can achieve results. But in the end he gets a customer that is not fully satisfied.

In another project, a related thing happened. The programmer wanted to get the work done within the sprint. Because of time pressure, she chose to code the solution according to her own insight. The customer didn’t understand why she chose this solution. Had the scrum master done it himself, he told me, he would at first have spent more time understanding the product and the business she was working on (it is a recently started project so the developer does not have all the system and domain knowledge yet). On top of that he would have spent more time researching on the Internet for re usable code or a useful framework (and he added that most Dutch programmers would have done this as well). But our (Indian) programmer didn’t do that.

What causes these issues to appear in cross cultural cooperations? (I have used two examples from India but I could as well describe one from Ukraine).

I believe the root is in the mindset of the programmers. They see themselves as ‘coders’ and pride themselves in getting work done. Because of this mindset, they feel that they cannot spend time on researching, on spending time using Google to see how others solved similar issues. Because they have work to do, they don’t invest their time in diving deeper into the product or domain they are working on. They want to get clear tasks and get going with the coding. I believe that in India, the system stimulates this too. Most companies operate in strong hierarchy that is unknown to Europeans. There is an account manager responsible for client relations, a project manager for the overall project planning and communication, a team lead that distributes the work to the developers and then we have a programmer without big responsibilities other than producing code. On top of this, the tester will test the code by the way.

Most European companies have the opposite mindset, they prefer quality over speed, they prefer a programmer telling them he can’t finish a user story and proposes to move that to the next sprint because he needs more time to research and test another user story.

I see a few practical ways to change such issues from happening.

1. The first is to consistently stimulate the developer to invest time on research, to remind him consistently that quality is more important than speed. This will have a long term beneficial impact.

2. Plan for research, testing, domain investigation within the sprint. Create a separate task for this, assign a certain amount of hours to the task, so the developer knows it is ok and expected to do research, to test work very well before committing code.

3. Have a clear definition of done (so the developer will always know what is expected of him) and add acceptance criteria to the user stories.

4. Take enough time in sprint planning sessions to discuss solutions, before the developer starts the coding. Stimulate the developer to explain the proposed solution, estimate the workload and reach agreement on that solution. If he doesn’t know yet, add research time to the user story and let him describe the solution to you during the sprint before implementing.

5. Create clarity on the hierarchy within the scrum team. Developers, especially in India, often see the scrum master (especially if he is from another country and working in the customers company) as a superior. They have learned that it is not ok to correct a superior in general, so they might hold back in sharing solutions with you and asking questions. They assume the superior knows best and will prescribe what to do. Keep repeating that the roles are all on the same level and reward ideas, suggestions and own initiative.

Der Programmierer in Indien verpflichtet sich zu einem bestimmten Sprint. Seine Denkart ist auf die Bereitstellung aller User Storys des Sprints innerhalb des vorgegebenen Sprints ausgerichtet. Es geschieht oft in Projekten, dass ich mit involviert bin. Irgendwie halten Entwickler daran fest eine Frist einzugehen. Aber Scrum erklärt, dass eine lieferbare Abgabe am Ende des Sprints wichtiger ist als jede User Story im Sprint zu beenden. Da der Entwickler  der in diesem Fall alleine aus der Ferne arbeitet ) sich zu dem Sprint verpflichtet hat, kann er auch einige der User Storys zu dem nächsten Sprint verschieben oder zu dem nächsten Backlog. Jedoch hat er Lust alles zu beenden. Das Ergebnis letzte Woche war, dass alle User Storys beendet waren, jedoch nicht auf dem Qualitätsniveau wie es der Kunde erwartet hatte.

Aus Sicht des Programmierers hat er sehr hart gearbeitet, um dem Kunden zu zeigen, dass er Ergebnisse erzielen kann. Doch am Ende hat er einen Kunden bekommen, der nicht voll zufrieden ist.

In einem anderen Projekt geschah etwas Ähnliches. Der Programmier wollte die Arbeit innerhalb des Sprints zu Ende bringen. Wegen des Zeitdrucks entschied sie sich die Lösungen mit ihren eigenen Erkenntnissen zu kodieren. Der Kunde verstand nicht, warum sie sich für diese Lösung entschieden hat. Der Scrum-Master erzählte mir, hätte er es selbst getan, hätte er sich zuerst mehr Zeit genommen das Produkt und das Geschäft zu verstehen, an dem sie gearbeitet hat. (Das Projekt hat kürzlich erst begonnen, deshalb hat die Programmiererin noch nicht alle Kenntnisse über das System und die Domain). Hinzu kommt, dass er mehr Zeit verbracht hätte nach einen wieder verwendbaren Code und ein nützliches Framework im Internet zu suchen. (er fügte hinzu, dass es die meisten holländischen Programmier wie er getan hätten). Jedoch hat es unsere indische Programmiererin nicht gemacht.

Was verursacht diese Probleme in interkulturellen Kooperationen? (Ich habe zwar zwei Beispiele aus Indien gebracht, doch ich hätte auch eins aus der Ukraine aufzeigen können.)

Ich glaube die Wurzel liegt in der Denkweise der Programmierer. Sie sehen sich selbst als „Programmierer“ und sind stolz darauf Arbeit erledigt zu bekommen. Aufgrund dieser Denkweise, haben sie das Gefühl sie können keine Zeit für Recherche verbringen, um zu sehen wie andere solche Probleme gelöst haben. Da sie beschäftigt sind, investieren sie keine Zeit tiefer in das Produkt oder die Domain zu tauchen, an der sie arbeiten. Sie wollen konkrete Aufgaben bekommen und mit dem Programmieren anfangen. Ich glaube in Indien regt auch das System bzw. die Gesellschaft dazu an. Die meisten Unternehmen werden mit starker Hierarchie geführt, was für Europäer ziemlich ungewohnt ist. Dort ist ein Account Manager für die Kundenbeziehung zuständig, ein Projekt Manager für die gesamte Projektplanung und Kommunikation, ein Gruppenführer für die Verteilung der Arbeit an die Entwickler und dann gibt es noch einen Programmierer ohne große Verantwortung außer zu programmieren. Hinzu kommt noch ein Tester, der übrigens den Code testet.

Die meisten europäischen Firmen haben die entgegengesetzte Denkweise. Sie bevorzugen Qualität gegenüber Schnelligkeit. Sie wollen einen Programmier, der ihnen sagt, dass er mit seiner User Story nicht fertig wird und vorschlägt es zum nächsten Sprint zu verschieben, da er mehr Zeit braucht zu recherchieren und um eine andere User Story zu testen.

Ich sehe ein paar praktische Möglichkeiten, um solche Probleme zu verhindern:

1. Erstens sollten Sie den Programmierer immer ermutigen Zeit für die Recherche aufzubringen und ihn ständig daran erinnern, dass Qualität wichtiger ist als Geschwindigkeit. Das wird langfristige positive Auswirkungen haben.
2. Innerhalb des Sprints sollte die Recherche, das Testen und Domain-Untersuchungen einberechnet werden. Dafür sollte eine separate Aufgabe erstellt werden. Danach sollte eine bestimmte Anzahl an Stunden dafür angesetzt werden, damit der Programmierer weiß, dass es in Ordnung ist und dass er erwartet zu recherchieren. Die Arbeit sollte also vorher gut getestet werden, bevor man sich zum Programmieren begibt.
3. Sie sollten eine klare Definition von der zu erledigten Arbeit haben (so weiß der Programmierer immer was ich von ihm erwarte) und fügen Sie Abnahmekriterien für die User Storys hinzu.
4. Nehmen Sie sich genug Zeit in Sprintplanungssitzungen um Lösungen zu diskutieren, bevor der Entwickler anfängt zu programmieren. Ermuntern Sie den Entwickler die vorgeschlagene Lösung zu erklären, schätzen Sie den Arbeitsaufwand ein und erhalten Sie eine Einigung über die Lösung. Wenn er es noch nicht weiß, fügen Sie Recherchezeit der User-Story hinzu und lassen Sie sich die Lösung während des Sprints und vor der Implementierung erklären.
5. Erlangen Sie eine Klarheit über die Hierarchie innerhalb des Scrum-Teams. Entwickler, vor allem in Indien sehen den Scrum-Master als einen Vorgesetzen an (und besonders wenn er von einem anderen Land ist und wenn er in Firma des Kunden arbeitet). Sie haben gelernt, dass es nicht in Ordnung ist einen Vorgesetzten zu korrigieren, so dass er sich womöglich zurückhält Lösungen vorzuschlagen oder Fragen zu stellen. Er geht davon aus, dass es der Scrum-Master besser weiß und ihm sagt was zu tun ist. Wiederholen Sie, dass die Rollen auf gleicher Ebene sind und Belohnen Sie Ideen, Anregungen und Eigeninitiativen.