![\"\"](\"https:\/\/www.bridge-global.com\/blog\/\/wp-content\/uploads\/2013\/02\/Images_services-1-150x150.png\" "\\"offshore")
<\/a>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.<\/p>\nOm 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).<\/p>\n
De programmeur in India verbindt zich aaneen \u200b\u200bbepaalde 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.<\/p>\n
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.<\/p>\n
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.<\/p>\n
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\u00efnekunnenbeschrijven)<\/p>\n
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\u00ebrarchie 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.<\/p>\n
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.<\/p>\n
Ik zie een paar praktische manieren om dergelijke kwesties te voorkomen.<\/p>\n
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.<\/p>\n
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.<\/p>\n
3. Heb een duidelijke definitie van \u2018gedaan\u2019 (dus de ontwikkelaar zal altijd weten wat er van hem verwacht wordt) en voeg acceptatiecriteria toe voor de user stories.<\/p>\n
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.<\/p>\n
5. Maak duidelijkheid over de hi\u00ebrarchie 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 \u200b\u200bsuperieur 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\u00ebn, suggesties en eigen initiatief.<\/p>\n
<\/p>\n
<\/p>\n
En av skillnaderna p\u00e5 tankes\u00e4tten som ofta leder till problem i samarbeten mellan olika kulturer \u00e4r kvaliteten kontra snabbheten. Jag tror att detta \u00e4r en kulturell skillnad som beh\u00f6ver uppm\u00e4rksamhet i alla offshore-samarbeten. Det kan vara ett resultat av ett visst lands kulturella perspektiv likv\u00e4l av en viss f\u00f6retagskultur.<\/p>\n
F\u00f6r att illustrera den h\u00e4r po\u00e4ngen ska jag dela med mig av ett exempel. I ett av v\u00e5ra projekt samarbetar en indisk programmerare med ett holl\u00e4ndskt mjukvaruutvecklingsteam. Scrum-mastern finns i Nederl\u00e4nderna och produkt\u00e4garen likas\u00e5. Teamet anv\u00e4nder sig av tv\u00e5 sprinter veckovis och beslutar vilka user stories som ska slutf\u00f6ras p\u00e5 sprintplaneringsm\u00f6tet f\u00f6re sprinten.<\/p>\n
\u00a0Programmeraren i Indien f\u00f6ljer en speciell sprint. Hans tankes\u00e4tt \u00e4r att leverera alla user stories fr\u00e5n den sprinten inom en given sprint. Det h\u00e4r h\u00e4nder ofta i projekt d\u00e4r jag \u00e4r involverad; p\u00e5 n\u00e5got s\u00e4tt har utvecklarna tankes\u00e4ttet att de m\u00e5ste h\u00e5lla en deadline, men scrum menar att en s\u00e4ndbar leverans vid slutet av sprinten \u00e4r viktigare \u00e4n att g\u00f6ra klart varenda user story i sprinten. Eftersom utvecklaren (som i detta fall jobbar ensam p\u00e5 distans) f\u00f6ljer sprinten, skulle han ocks\u00e5 kunna flytta n\u00e5gra user stories till n\u00e4sta sprint eller till produktens eftersl\u00e4pning. Men han \u00e4r ivrig att slutf\u00f6ra allt. Resultatet den sista veckan blev att alla user stories var klara men inte med den kvaliteten som kunden hade f\u00f6rv\u00e4ntat sig.<\/p>\n
\u00a0Fr\u00e5n programmerarens perspektiv har han jobbat v\u00e4ldigt h\u00e5rt f\u00f6r att visa kunden att han kan uppn\u00e5 resultat. Men i slut\u00e4nden f\u00e5r han en kund som inte \u00e4r fullt s\u00e5 n\u00f6jd.<\/p>\n
I ett annat projekt h\u00e4nde en liknande sak. Programmeraren ville f\u00e5 arbetet gjort inom sprinten. P.g.a. tidspress valde hon att koda l\u00f6sningen enligt hennes egen uppfattning. Kunden f\u00f6rstod inte varf\u00f6r hon valt denna l\u00f6sning. Scrum-mastern ber\u00e4ttar att om han hade gjort det sj\u00e4lv, skulle han f\u00f6rst ha tagit sig mer tid till att f\u00f6rst\u00e5 produkten och verksamheten som hon jobbade inom (det \u00e4r ett projekt som nyss startats upp s\u00e5 utvecklare har inte all kunskap inom systemet och dom\u00e4nen \u00e4n). Ut\u00f6ver det skulle han ha tagit sig mer tid att forska p\u00e5 internet efter anv\u00e4ndbar kod eller ett hj\u00e4lpsamt ramverk (och han la till att de flesta holl\u00e4ndska programmerarna ocks\u00e5 skulle ha gjort s\u00e5). Men v\u00e5r indiska programmerare gjorde inte det.<\/p>\n
\u00a0Vad orsakar att dessa problem uppst\u00e5r i samarbeten mellan olika kulturer? (Jag har anv\u00e4nt tv\u00e5 exempel fr\u00e5n Indien men jag skulle lika g\u00e4rna kunna beskriva n\u00e5got fr\u00e5n Ukraina).<\/p>\n
Jag tror att k\u00e4llan till detta ligger i programmerarnas olika tankes\u00e4tt. De ser sig sj\u00e4lva som \u201dkodare\u201d och \u00e4r stolta n\u00e4r de har avklarat ett jobb. P.g.a. detta tankes\u00e4tt k\u00e4nner de att de inte kan spendera tid med att efterforska, spendera tid med att anv\u00e4nda Google f\u00f6r att se hur andra har l\u00f6st liknande problem. P.g.a. att de har jobb att g\u00f6ra, investerar de inte tid i att djupdyka i produkten eller dom\u00e4nen som de jobbar med. De vill ha tydliga uppgifter och vill bara b\u00f6rja jobba med kodningen. Jag tror att detta system \u00e4ven stimuleras i Indien. De flesta f\u00f6retag \u00e4r uppbyggda med en stark hierarki som \u00e4r ok\u00e4nd f\u00f6r Europ\u00e9er. Det finns en account manager som \u00e4r ansvarig f\u00f6r klientrelationerna, en projektledare som ansvarar f\u00f6r projektets planering och kommunikation och en team ledning som distribuerar arbetet till utvecklarna och s\u00e5 har vi en programmerare utan st\u00f6rre ansvar \u00e4n att koda. Ut\u00f6ver detta har vi en testare som testar koden.<\/p>\n
De flesta europ\u00e9iska f\u00f6retag har ett motsatt tankes\u00e4tt, de f\u00f6redrar kvalitet f\u00f6re snabbhet, de f\u00f6redrar en programmerare som ber\u00e4ttaratt han inte kan slutf\u00f6ra en user story och ist\u00e4llet f\u00f6resl\u00e5r att flytta den till n\u00e4sta sprint f\u00f6r att han beh\u00f6ver mer tid att efterforska och testa en annan user story.<\/p>\n
Jag ser ett f\u00e5tal praktiska s\u00e4tt att motverka detta fr\u00e5n att h\u00e4nda:<\/p>\n
1. \u00a0 \u00a0Det f\u00f6rsta \u00e4r att konsekvent stimulera utvecklaren att investera tid p\u00e5 efterforskning, att p\u00e5minna honom om att kvalitet \u00e4r viktigare \u00e4n snabbhet. Detta har en l\u00e5ngsiktig f\u00f6rdelaktig p\u00e5verkan.<\/p>\n
\u00a02. \u00a0 \u00a0 Planera f\u00f6r efterforskning, testning och dom\u00e4nutredning inom sprinten. Skapa en separat uppgift f\u00f6r detta, tilldela ett visst antal timmar p\u00e5 denna uppgift s\u00e5 att utvecklaren vet att det \u00e4r okej och f\u00f6rv\u00e4ntat att g\u00f6ra efterforskning, f\u00f6r att testa arbetet v\u00e4l innan kodningen sker.<\/p>\n
3. \u00a0 \u00a0Ha en klar definition av \u201cf\u00e4rdig\u201d (s\u00e5 att utvecklaren alltid vet vad som f\u00f6rv\u00e4ntas av honom) och l\u00e4gg till ett acceptanskriterium till de user stories som finns.<\/p>\n
\u00a04. \u00a0 \u00a0 Ta tillr\u00e4ckligt med tid p\u00e5 sprintplaneringen till att diskutera l\u00f6sningar, innan utvecklaren b\u00f6rjar koda. Stimulera utvecklaren att f\u00f6rklara f\u00f6rslaget till l\u00f6sningen, ber\u00e4kna arbetsm\u00e4ngden och n\u00e5 en \u00f6verenskommelse p\u00e5 det f\u00f6rslaget. Om han inte vet \u00e4n, l\u00e4gg till efterforskningstid till user storyn och l\u00e5t honom f\u00f6rklara l\u00f6sningen f\u00f6r dig under sprinten f\u00f6re genomf\u00f6randet.<\/p>\n
5. \u00a0\u00a0\u00a0\u00a0Skapa en klarhet av hierarkin inom scrum-teamet. Utvecklare, s\u00e4rskilt i Indien, ser ofta scrum-mastern (s\u00e4rskilt om han \u00e4r fr\u00e5n ett annat land och jobbar p\u00e5 kundens f\u00f6retag) som en \u00f6verordnad person. De har l\u00e4rt sig att det inte \u00e4r okej att r\u00e4tta en \u00f6verordnad \u00f6verlag, s\u00e5 de kan h\u00e5lla tillbaka med att dela sina l\u00f6sningar och l\u00e5ta bli att st\u00e4lla fr\u00e5gor. De antar att den \u00f6verordnade alltid vet b\u00e4st och kommer att f\u00f6reskriva vad som ska g\u00f6ras. Forts\u00e4tt repetera att alla roller \u00e4r p\u00e5 samma niv\u00e5 och bel\u00f6na id\u00e9er, f\u00f6rslag och eget initiativ.<\/p>\n
<\/p>\n
<\/p>\n
Die Unterschiede in der Denkweise, die oft zu Problemen in Kooperation zwischen verschiedenen Kulturen f\u00fchren, sind oft zu dem Thema Qualtit\u00e4t 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.<\/p>\n
Um den Punkt deutlich zu machen, werde ich ein Beispiel aufzeigen. In einem unserer Projekte arbeit ein indischer Programmierer mit einem holl\u00e4ndischen Softwareentwicklungsteam. Der Scrum-Master ist in den Niederlanden und auch der Produkteigent\u00fcmer. Das Team nutzt zwei w\u00f6chentliche Sprints und entscheidet \u00fcber die User Storys, die vor dem Sprint abgeschlossen werden, im Sprintplanungsmeeting. (Sie benutzen auch Planning Poker)<\/p>\n
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.<\/p>\n
From the programmer\u2019s 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.<\/p>\n
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.<\/p>\n
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).<\/p>\n
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.<\/p>\n
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.<\/p>\n
I see a few practical ways to change such issues from happening.<\/p>\n
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.<\/p>\n
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.<\/p>\n
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.<\/p>\n
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.<\/p>\n
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.<\/p>\n
![\"\"](\"https:\/\/www.bridge-global.com\/blog\/\/wp-content\/uploads\/2013\/02\/01.jpg\" "\\"01\\"")
<\/a><\/p>\n<\/p>\n
\n<\/p>\n
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\u00e4rt, dass eine lieferbare Abgabe am Ende des Sprints wichtiger ist als jede User Story im Sprint zu beenden. Da der Entwickler \u00a0der in diesem Fall alleine aus der Ferne arbeitet ) sich zu dem Sprint verpflichtet hat, kann er auch einige der User Storys zu dem n\u00e4chsten Sprint verschieben oder zu dem n\u00e4chsten Backlog. Jedoch hat er Lust alles zu beenden. Das Ergebnis letzte Woche war, dass alle User Storys beendet waren, jedoch nicht auf dem Qualit\u00e4tsniveau wie es der Kunde erwartet hatte.<\/p>\n
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.<\/p>\n
In einem anderen Projekt geschah etwas \u00c4hnliches. Der Programmier wollte die Arbeit innerhalb des Sprints zu Ende bringen. Wegen des Zeitdrucks entschied sie sich die L\u00f6sungen mit ihren eigenen Erkenntnissen zu kodieren. Der Kunde verstand nicht, warum sie sich f\u00fcr diese L\u00f6sung entschieden hat. Der Scrum-Master erz\u00e4hlte mir, h\u00e4tte er es selbst getan, h\u00e4tte er sich zuerst mehr Zeit genommen das Produkt und das Gesch\u00e4ft zu verstehen, an dem sie gearbeitet hat. (Das Projekt hat k\u00fcrzlich erst begonnen, deshalb hat die Programmiererin noch nicht alle Kenntnisse \u00fcber das System und die Domain). Hinzu kommt, dass er mehr Zeit verbracht h\u00e4tte nach einen wieder verwendbaren Code und ein n\u00fctzliches Framework im Internet zu suchen. (er f\u00fcgte hinzu, dass es die meisten holl\u00e4ndischen Programmier wie er getan h\u00e4tten). Jedoch hat es unsere indische Programmiererin nicht gemacht.<\/p>\n
Was verursacht diese Probleme in interkulturellen Kooperationen? (Ich habe zwar zwei Beispiele aus Indien gebracht, doch ich h\u00e4tte auch eins aus der Ukraine aufzeigen k\u00f6nnen.)<\/p>\n
Ich glaube die Wurzel liegt in der Denkweise der Programmierer. Sie sehen sich selbst als \u201eProgrammierer\u201c und sind stolz darauf Arbeit erledigt zu bekommen. Aufgrund dieser Denkweise, haben sie das Gef\u00fchl sie k\u00f6nnen keine Zeit f\u00fcr Recherche verbringen, um zu sehen wie andere solche Probleme gel\u00f6st haben. Da sie besch\u00e4ftigt 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\u00fchrt, was f\u00fcr Europ\u00e4er ziemlich ungewohnt ist. Dort ist ein Account Manager f\u00fcr die Kundenbeziehung zust\u00e4ndig, ein Projekt Manager f\u00fcr die gesamte Projektplanung und Kommunikation, ein Gruppenf\u00fchrer f\u00fcr die Verteilung der Arbeit an die Entwickler und dann gibt es noch einen Programmierer ohne gro\u00dfe Verantwortung au\u00dfer zu programmieren. Hinzu kommt noch ein Tester, der \u00fcbrigens den Code testet.<\/p>\n
Die meisten europ\u00e4ischen Firmen haben die entgegengesetzte Denkweise. Sie bevorzugen Qualit\u00e4t gegen\u00fcber Schnelligkeit. Sie wollen einen Programmier, der ihnen sagt, dass er mit seiner User Story nicht fertig wird und vorschl\u00e4gt es zum n\u00e4chsten Sprint zu verschieben, da er mehr Zeit braucht zu recherchieren und um eine andere User Story zu testen.<\/p>\n
Ich sehe ein paar praktische M\u00f6glichkeiten, um solche Probleme zu verhindern:<\/p>\n
\n- Erstens sollten Sie den Programmierer immer ermutigen Zeit f\u00fcr die Recherche aufzubringen und ihn st\u00e4ndig daran erinnern, dass Qualit\u00e4t wichtiger ist als Geschwindigkeit. Das wird langfristige positive Auswirkungen haben.<\/li>\n
- Innerhalb des Sprints sollte die Recherche, das Testen und Domain-Untersuchungen einberechnet werden. Daf\u00fcr sollte eine separate Aufgabe erstellt werden. Danach sollte eine bestimmte Anzahl an Stunden daf\u00fcr angesetzt werden, damit der Programmierer wei\u00df, 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.<\/li>\n
- Sie sollten eine klare Definition von der zu erledigten Arbeit haben (so wei\u00df der Programmierer immer was ich von ihm erwarte) und f\u00fcgen Sie Abnahmekriterien f\u00fcr die User Storys hinzu.<\/li>\n
- Nehmen Sie sich genug Zeit in Sprintplanungssitzungen um L\u00f6sungen zu diskutieren, bevor der Entwickler anf\u00e4ngt zu programmieren. Ermuntern Sie den Entwickler die vorgeschlagene L\u00f6sung zu erkl\u00e4ren, sch\u00e4tzen Sie den Arbeitsaufwand ein und erhalten Sie eine Einigung \u00fcber die L\u00f6sung. Wenn er es noch nicht wei\u00df, f\u00fcgen Sie Recherchezeit der User-Story hinzu und lassen Sie sich die L\u00f6sung w\u00e4hrend des Sprints und vor der Implementierung erkl\u00e4ren.<\/li>\n
- Erlangen Sie eine Klarheit \u00fcber 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\u00f6glich zur\u00fcckh\u00e4lt L\u00f6sungen vorzuschlagen oder Fragen zu stellen. Er geht davon aus, dass es der Scrum-Master besser wei\u00df und ihm sagt was zu tun ist. Wiederholen Sie, dass die Rollen auf gleicher Ebene sind und Belohnen Sie Ideen, Anregungen und Eigeninitiativen.<\/li>\n<\/ol>\n
<\/p>\n","protected":false},"excerpt":{"rendered":"
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 …<\/p>\n","protected":false},"author":4,"featured_media":44071,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[14,5],"tags":[],"class_list":["post-5190","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-offshoring","category-outsourcing"],"featured_image_src":"https:\/\/www.bridge-global.com\/blog\/wp-content\/uploads\/2013\/02\/Quality.jpg","author_info":{"display_name":"Hugo Messer","author_link":"https:\/\/www.bridge-global.com\/blog\/author\/hugomesser\/"},"_links":{"self":[{"href":"https:\/\/www.bridge-global.com\/blog\/wp-json\/wp\/v2\/posts\/5190","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.bridge-global.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.bridge-global.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.bridge-global.com\/blog\/wp-json\/wp\/v2\/users\/4"}],"replies":[{"embeddable":true,"href":"https:\/\/www.bridge-global.com\/blog\/wp-json\/wp\/v2\/comments?post=5190"}],"version-history":[{"count":4,"href":"https:\/\/www.bridge-global.com\/blog\/wp-json\/wp\/v2\/posts\/5190\/revisions"}],"predecessor-version":[{"id":28534,"href":"https:\/\/www.bridge-global.com\/blog\/wp-json\/wp\/v2\/posts\/5190\/revisions\/28534"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.bridge-global.com\/blog\/wp-json\/wp\/v2\/media\/44071"}],"wp:attachment":[{"href":"https:\/\/www.bridge-global.com\/blog\/wp-json\/wp\/v2\/media?parent=5190"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.bridge-global.com\/blog\/wp-json\/wp\/v2\/categories?post=5190"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.bridge-global.com\/blog\/wp-json\/wp\/v2\/tags?post=5190"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
![\"\"](\"https:\/\/www.bridge-global.com\/blog\/wp-content\/uploads\/2013\/02\/Images_services-1-150x150.png\" "\\"offshore")
<\/a>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.<\/p>\n