Hva er distribuert programvareutvikling og hva er det som får slike team til å fungere? Man kan selvsagt argumentere med at det viktigste verktøyet i verktøykassen - nemlig hjernen - er alt du trenger for å få til et bra produkt. Men ikke glem lederen!
I min søken for mer kunnskap, henvendte jeg meg til Ben Armstrong. Denne utrolige mannen er ikke bare Program Manager Lead for Hyper-V-teamet. Ben Armstrong er også ansett som en mester innenfor virtualiseringsteknologi – den eneste ene «Virtual PC guy«!
Hver gang noe går galt er du nødt til å fikse det, og som vårt intervju med for rundt 2 år siden viste – er dette aldri en enkel oppgave.
Ben Armstrong
Ben innehar den prestisjetunge tittelen «Program Manager Lead» hos programvareselskapet Microsoft, hvor han i over et tiår har arbeidet med virtualisering.
Denne erfaringen har vært med på å bygge en enorm forståelse for disiplinen og gir ham mer erfaring enn sine seniorer (våre ord, ikke hans).
Du kan følge Ben på Twitter – @VirtualPCGuy
Ben Armstrong, hva er din erfaring med distribuerte team?
Når vi er inne på emnet om distribuerte team og min er faring med dette innenfor Microsoft; vi har flere team som er distribuert globalt. For å ta et eksempel så er kjernen av Hyper-V-teamet stasjonert i Redmond, teamet som leverer Hyper-V replika er stasjonert i utviklingssenteret i India, mens teamet som tar seg av store deler av vår Linux-support er stasjonert i Shanghai.
Når dagen er over, så er det her vi ønsker å være.
-Ben Armstrong
Jeg har mange tanker når det kommer til dette, og den viktigste er å ha en helt klar forståelse om hva suksess faktisk ser ut som når dagen er omme. Du vet, når du har distribuerte team, så kan du ikke jobbe i en modus hvor, hvis noen blir blokkert på et teknisk eller personlig tema – så kan de bare kontakte deg – eller, ha en samtale hvor alle parter er involvert.
Du er nødt til å tilrettelegge på en måte som gjør at personene kan løse problemene selv, og du må ha samtaler hvor alle er enige i at: «Når dagen er over, så er det her vi ønsker å være. Dette er det overordnede målet vi har; hvordan vi kommer oss dit – det finner vi ut på veien».
Så «når dagen er over» er egentlig mer som «når utviklingsprosessen er over»?
Ja, du vet, en av de største utfordringene vi har og vi bruker mye tid på å prøve å klargjøre menneskene og deres team på denne måten; du kan ikke ha en situasjon hvor gruppemedlemmene ved hvert eneste steg må sjekke inn hos de andre og spørre eller få bekreftet, «Du? Gjør jeg dette riktig her? Gjør jeg dette riktig der?».
Du er nødt til å kunne tilrettelegge slik at du kan si «Om fire ukers tid skal alle være på dette punktet».
Et flott eksempel på dette er en kar på mitt team. Jeg skal ikke fortelle hva han jobber med, det er et hemmelig prosjekt. Men han jobber for tiden med et prosjekt som er utfordrende for han, og før jeg dro til Australia satte vi oss ned sammen og diskuterte hvilke steg han skal jobbe på, og hvilke ting han skal jobbe videre med etter dette. Men, en av tingene jeg var veldig klar på var: Når jeg er tilbake, hovedmåten for å vurdere om du har vært vellykket eller ikke, er å snakke med to av nøkkelpersonene som du jobber med og se om de syntes du har gjort en god jobb.
Så hvis du går en uke frem i tid fra i dag og snakker med disse to personene, og de tror at du må endre på det du jobber med, da er det den riktige tingen å gjøre. Ikke å ukritisk følge det vi ble enige om en uke i forveien.
Hva med kultur? Er dette noe folk blir fornærmet over?
Dette er noe jeg personlig syntes er virkelig interessant. Bare det å måtte håndtere de kulturelle og sosiale aspektene ved å jobbe i miljøer som dette er veldig komplekst og utfordrende. Folk undervurderer viktigheten av den sosiale kontakten, så en av de tingene jeg snakker med folk i et miljø som dette, er hvor viktig det er å planlegge tid og så sette seg ned med folk bare for å ha uformelle samtaler. Bare på denne måten kan man forstå hva som motiverer deg og hva som er viktig for deg som en person utenfor de individuelle prosjektene.
Hvordan håndterer du din rolle som Program manager og sørger for at ting blir gjort i disse distribuerte teamene?
Første ting først, jeg er faktisk en Program Manager Lead, som betyr at jeg håndterer og leder et team med Program managere. Program manager-stillingen hos Microsoft er en mer utviklings-fokusert versjon av produkt managere hos andre firmaer.
Så en del av Program manager-jobben er å bruke tid på å se på bedriftens behov, på markedet, snakke med kundene våre. Det er viktig for oss å forstå hvilke problemer folk støter på når de bruker våre produkter, så vel som egenskaper og funksjoner vi burde satse på implementere i fremtidige versjoner av programvaren.
Nå skildret jeg egentlig rollen administrativt, men Program managerne er også mer på utviklernes side, og dermed ansvarlige for å designe disse egenskapene. Ofte går vi langt i de tekniske detaljene som brukeropplevelsen, definere APIer og brukerflyten i applikasjonen. Vi er også ansvarlige for å hjelpe til med å drive den daglige ledelsen av prosjektet.
Den desidert viktigste tingen er å alltid kommunisere, å alltid være i kontakt
– Ben Armstrong
For å svare på spørsmålet ditt så er jeg som en Program Manager Lead den som leder et team av Program managere og min primære jobb er å veilede dem og å assistere dem med å forstå hvordan de kan oppnå resultatene og utføre jobben på best mulig måte.
En av tingene jeg alltid snakker med folkene mine om – og dette er faktisk noe jeg jobber veldig hardt med når jeg er ute og reiser – er, den desidert viktigste tingen er å alltid kommunisere, å alltid være i kontakt.
Kan du være litt mer spesifikk på hva dette går ut på?
Faktisk så har jeg to eksempler på dette: Jeg er midt i en fem-ukers periode hvor jeg er på reisefot og driver med forskjellige oppgaver på reisen. Jeg snakker med kunder og samhandler med teknikere, og hver kveld skriver jeg e-poster til teamet; «Hei, dette er personene jeg har møtt, og her er diskusjonene vi har hatt». I tillegg sender jeg e-poster til teamet og sier: «Hvilke spørsmål har dere, skal jeg spørre kundene? Hvilken informasjon kan jeg skaffe dere?», og holder denne samtalen gående.
Det andre er, selv om jeg er på reisefot, så sender teamet konstant kopier av arbeidet sitt til meg og jeg tar meg alltid tid til å gå igjennom det og gi tilbakemelding. Om de er på riktig vei og hvilken retning de burde gå i, så bare for å være sikker på at selv om jeg er på reise, så er det hele tiden en pågående samtale og god kommunikasjon også i utviklingsprosjektet.
På bildet: Carsten Rachfahl (f.v.), Cristal Kawula, Ben Armstrong og Alexander Solaat Rødland." data-medium-file="https://i0.wp.com/itprox.no/wp-content/uploads/2016/02/Carsten-Rachfahl_Cristal-Kawula_Ben-Armstrong_Alexander-Solaat-Rodland.jpg?fit=700%2C383&ssl=1" data-large-file="https://i0.wp.com/itprox.no/wp-content/uploads/2016/02/Carsten-Rachfahl_Cristal-Kawula_Ben-Armstrong_Alexander-Solaat-Rodland.jpg?fit=1200%2C657&ssl=1" decoding="async" class="size-medium wp-image-28487 jetpack-lazy-image" src="https://i0.wp.com/itprox.no/wp-content/uploads/2016/02/Carsten-Rachfahl_Cristal-Kawula_Ben-Armstrong_Alexander-Solaat-Rodland.jpg?resize=700%2C383&ssl=1" alt="" width="700" height="383" data-recalc-dims="1" data-lazy-srcset="https://i0.wp.com/itprox.no/wp-content/uploads/2016/02/Carsten-Rachfahl_Cristal-Kawula_Ben-Armstrong_Alexander-Solaat-Rodland.jpg?resize=700%2C383&ssl=1 700w, https://i0.wp.com/itprox.no/wp-content/uploads/2016/02/Carsten-Rachfahl_Cristal-Kawula_Ben-Armstrong_Alexander-Solaat-Rodland.jpg?resize=768%2C420&ssl=1 768w, https://i0.wp.com/itprox.no/wp-content/uploads/2016/02/Carsten-Rachfahl_Cristal-Kawula_Ben-Armstrong_Alexander-Solaat-Rodland.jpg?w=1200&ssl=1 1200w" data-lazy-sizes="(max-width: 700px) 100vw, 700px" data-lazy-src="https://i0.wp.com/itprox.no/wp-content/uploads/2016/02/Carsten-Rachfahl_Cristal-Kawula_Ben-Armstrong_Alexander-Solaat-Rodland.jpg?resize=700%2C383&is-pending-load=1#038;ssl=1" srcset="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7">
På bildet: Carsten Rachfahl (f.v.), Cristal Kawula, Ben Armstrong og Alexander Solaat Rødland.
Du kommer fra en programmeringsbakgrunn, ikke sant, fortell litt mer om din bakgrunn?
Jeg begynte som en utvikler og utviklet på mange forskjellige systemer. Faktisk så begynte jeg primært med databaseutvikling, og som en utvikler er du veldig fokusert på det tekniske problemet, og langt mindre fokusert på det menneskelige aspektet ved tekniske løsninger.
Over tid kom jeg inn i Program manager-stillingen fordi jeg synes var mest interessant, fordi da ser man tydeligere hvordan det vi gjør med programvaren kan påvirke folk.
Som du vet bruker jeg mye tid på å snakke med folk om det faktum at, som en utvikler, så ser du på datamaskiner som veldig kalde – logiske ting. Men realiteten er at folk bruker datamaskiner på en emosjonell måte, vi bruker dem ikke logisk. Vi blir sinte på datamaskinene våre, vi blir glade i datamaskinene våre, vi snakker med datamaskinene våre. Selv når de ikke har stemmegjenkjenning.
Vi blir sinte på datamaskinene våre, vi blir glade i datamaskinene våre, vi snakker med datamaskinene våre. Selv når de ikke har stemmegjenkjenning.
– Ben Armstrong
Nå for tiden driver jeg utviklerne mine til vanvidd når det kommer til dette, men en av de klassiske tingene som jeg legger vekt på når vi utvikler programvare er: I det store og det hele, når folk bruker programvare, så leser de faktisk ikke teksten på skjermen.
Det er ganske fascinerende! Du har utviklere som ikke er vant til å fokusere på den menneskelige delen, og hvis det er et teknisk problem så er standard løsningen deres «Vi putter bare masse tekst på skjermen, som forteller brukeren nøyaktig det de trenger å vite».
Realiteten er en helt annen hvis du studerer hvordan folk faktisk bruker datamaskiner, folk vil prøve å finne ut hvilken knapp de skal trykke på intuitivt – uten å lese teksten på skjermen.
De kommer bare til å lese teksten på skjermen hvis de virkelig ikke klarer å gjette hva den riktige tingen å gjøre er. Vi har hatt utallige eksempler på det gjennom årene, du vet, folk som gjør merkelige ting fordi de rett og slett ikke har lest teksten på skjermen.
Men det er mange ting som det jeg virkelig liker. Jeg liker å forstå hvordan folk bruker programvaren vår og å forstå hva vi kan gjøre for at den skal bli bedre.
..du forklarte nettopp min erfaring med mitt nye kamera! Så kommunikasjon i distribuerte team er som en pågående samtale som bare fortsetter, og så holder du den gående?
Jepp! Du vet, den andre tingen som må belyses, og dette er ikke like relatert mot mine nærmeste team i Redmond, men med teamene vi har i India og Kina. Det er kjempeviktig å ta høyde for kulturelle forskjeller. For noen år siden fikk jeg muligheten til å reise og besøke disse teamene på deres lokasjoner i Kina og India hvor jeg faktisk tilbringe et par uker på kontorene deres.
Bare det å være der med dem og forstå de forskjellige kulturelle normene. Er du ikke er klar over dem har det lett for å dukke opp uheldige misforståelser. Folk tror bare at ord har eller kan bli forstått på den ene eller andre måten.
Det å være klar over de kulturelle forskjellene er kjempeviktig. Et av de enkle verktøyene jeg elsker å bruke for å avdekke dette er; hvis jeg snakker med noen eller vi utveksler e-poster, og jeg tror at vi nettopp har blitt enige om noe, så tar jeg faktisk tiden til å si direkte: «OK, så bare for å være helt sikker – vi ble nettopp enige om å gjøre A-B-C» og så gå gjennom alt sammen en gang til.
Ofte når jeg kommuniserer med et nytt team, eller til og med en ny person fra en kultur jeg ikke er vant med, har jeg omtrent femti prosent treff på akkurat denne teknikken, og det er fascinerende. Som du vet, jeg har hatt nye medlemmer på teamet som kom fra et annet land og med en annerledes bakgrunn, og jeg føler at vi har hatt en flott, konstruktiv samtale.
Jeg kommer til slutten og så sier jeg noe sånt som: «Bare for å være helt sikker – vi ble nettopp enige om å gjøre A-B-C» og personen ser på meg og sier «N-neei? – det er det motsatte av hva jeg akkurat sa». Det er veldig viktig å være klar over disse forskjellene når en kommuniserer med andre mennesker, spesielt fra andre kulturer enn den en kommer fra selv.
Har du et eksempel på en kulturell misforståelse som du har opplevd personlig?
Jeg har så mange! Faktisk, da jeg jobbet med en ny funksjon – dynamisk minne – som var en funksjon i Windows Server 2008 R2 Service Pack 1, så var en av utviklerne en kar fra Tyskland. Det tok oss flere måneder for å kommunisere effektivt. Du skjønner, jeg er fra Australia, han var fra Tyskland og det var veldig artig, for folk som kjente oss begge ville sagt at vi er begge veldig intelligente personer og vi hadde begge en sterk faglig bakgrunn.
Likevel, gang på gang satt denne personen og fortalte meg hvilken fremgangsmåte han skulle bruke, og hvis jeg prøvde å fortelle tilbake det jeg nettopp hadde hørt – så sa han noe sånt som «Nei, det var ikke det jeg sa i det hele tatt!».
Det tok oss mye tid å jobbe oss igjennom den delen og forstå hverandres kommunikasjon.
På den annen siden så nevnte jeg det teamet vi har i India. Den indiske kulturen har et veldig annerledes syn på ledelse, ledelsesstruktur og kommunikasjon enn den amerikanske kulturen. Min oppfatning av den amerikanske kulturen er hvis jeg samarbeider med et partner-team og vi kommer til en beslutning hvor vi sier: «Okay, vi skal fortsette i denne retningen».
Hvis min leder da kommer inn og er uenig med meg, så kan og vil jeg å svare: «Faktisk, nei. Vi har allerede forpliktet oss til dette partner-teamet og hvis du, som leder, har et problem med det, så må du ta en prat med vår partner, for dette er den avtalen vi har». I den indiske kulturen derimot, hvis du er i den situasjonen og din leder kommer inn og uenig, så har lederen rett.
Den ansatte ender opp med å gå tilbake til partneren og si: «Unnskyld! Jeg vet at vi ble enige om dette, men vi er ikke enige i det nå lenger». Dette er hverken positivt eller negativt, det er bare sånn kulturen er. Men hvis du ikke er klar over dette, så kan begge sider veldig lett fornærme den andre siden uten å innse det.
Det er viktig å være i stand til å se forskjellen mellom noen som er likegyldig eller upassende, i motsetning til noen som bare oppfører seg som man gjør i den kulturen. Altså om adferden er et kulturelt eller personlig trekk hos den personen.
Noen påstår at distribuerte team ikke fungerer like bra. Du nevner kultur, hvorfor fungerer ikke alltid distribuerte team, eller når er dette tilfelle?
Så når fungerer ikke ting like bra? La meg tenke litt på dette, for jeg vil gi det riktige svaret her (Ben tar for første gang et par sekunders pause!). En av de tingene jeg synes er vanskeligst i et distribuert miljø er å løse konflikter når de dukker opp. Noe jeg ofte prater med folk om er: «Det er veldig vanskelig å komme seg ut av en krangel på e-post. Det er veldig lett å komme seg inn i en krangel på e-post, men det er veldig vanskelig å komme seg ut av en krangel på e-post».
(…) Det er veldig vanskelig å komme seg ut av en krangel på e-post».
– Ben Armstrong
Jeg snakker mye om dette og budskapet er ofte det samme: «Hør her, du kan bruke e-post til å diskutere, planlegge, koordinere, men så fort det er en uenighet – hvis du ikke kan løse uenigheten på to eller tre e-poster, så er det på tide å stoppe e-postene og sette opp en telefonsamtale».
Jeg har sett situasjoner som har eskalert seg til svært komplekse konflikter når folk bruker e-post. E-post er forferdelig til å meddele følelse og intensjoner, og jeg har sett situasjoner hvor vi har utviklere som begge har de samme målene og som praktisk talt skriker til hverandre over e-post.
Bare det å få dem bort fra mail og inn i en konferansesamtale og ta tiden til å påpeke at «Hei, vi vil alle gjøre det som er rett her», og så bli enig om, hva som er greit og så bare få folk til å slappe av. Det er en av de vanskeligste tingene. Når en konflikt først har oppstått, og konflikter oppstår mellom mennesker, er det å få partene til å roe seg ned for å møtes «ved bordet» for å snakke ut om problemene. Slike ting er ofte langt mer utfordrende med distribuerte team hvor det ikke bare er å reise seg fra stolen og gå ned gangen og snakke med vedkommende.
Fra en systemutviklers perspektiv, var det ikke det jeg forventet å høre, men fra et psykologisk – eller atferdsperspektiv, så gir det på en måte mening..
(Ben skyter inn…) -og realiteten er, selv for systemutviklere, en av de tingene vi ofte overser er hvis jeg eller en annen utvikler setter sammen et forslag for hvordan vi ønsker å løse dette problemet. Men ønsker å løse det ved å bruke følgende teknikker og spesifikk fremgangsmåte. Realiteten er, og du kan ikke unngå dette, at litt av ditt personlige ego er innprentet i dette forslaget.
Resultatet av dette er at så fort folk kritiserer forslaget, er det veldig vanskelig å ikke se på det som kritikk av deg selv. Det er en egen ferdighet å være i stand til å si: «Vet du hva, det er bare en idé, og hvis folk ikke liker det, så er det ikke fordi de ikke synes noe om meg, det er bare fordi de har andre idéer». Jeg vil påstå at den største andelen av konflikter som jeg ser på utviklerteamene handler det ofte mer om ego enn om faktisk teknologi, utvikling design eller intensjon.
Vi takker Ben Armstrong for intervjuet som ble opprinnelig gjort 16. november 2015 over Skype for Business, og publisert på Alexander Solaat Rødlands blogg (på engelsk). Intervjuet med Ben Armstrong er oversatt av Kristine Jorskogen og publisert for ITpro av Martin Aleksander Holm.
