Distribuerte produksjonsenheter er kommet for å bli – eller Remote Work FTW

Credit: https://www.flickr.com/photos/snowpeak/14351894398/

Jeg tok en sjanse i sommer, jeg gikk over i en jobb hvor jeg visste at jeg kom til å jobbe som del av et distribuert team i Vibbio. Resonnementet bak å prøve var at om det funker og jeg liker det kan det åpne nye muligheter for å gjøre morsomme ting i femtiden.

Jeg har en erfaring med å jobbe distribuert og det var under en oppsigelsestid hvor jeg var fristilt. Da jobbet jeg med en person i Seattle og vi klarte og levere det vi skulle. Riktignok varte dette bare ca tre uker. Etter det var planen å finne noe annet, det ble aldri noe av.

Å skulle jobbe distribuert uten å ha noen du kan bare snu deg til også snakke med var skremmende. Alle som har jobbet med meg vet at mitt behov for å snakke er der ganske hyppig (beklager..). Jeg har også merket at jeg liker mennesker og liker å snakke med folk. De gangene jeg har hatt foreldre permisjon har jeg snakket hull i hodet på de hjemme fordi jeg ikke har fått snakket. Så vi kan si at kona var minst like bekymret.

Antagelig jobber du alt distribuert

Jeg her nå gjort det en måned og har vel egentlig erfart at det å jobbe distribuert er ikke så ulikt å jobbe i en stor bedrift. Hvis du uansett bruker digitale hjelpemiddel for all dag til dag kommunikasjon så er overgangen til å jobbe distribuert liten. Om kollegaen er i en annen etasje, bygg eller land betyr lite. Eneste overgangen er at du ikke like enkelt kan kaste bort tid på å bare snakke med folk.

Veldig mange steder har tatt i bruke ting som Slack / HipChat eller lignende. De aller fleste styrer oppgaver og prosjekter via digitale løsninger. Hvis vi skal oppsummere så er det egentlig bare møter som må endres (og strengt tatt er vel det bare 100% positivt ettersom alle selskaper er elendige på å holde møter) til å bli digitale via videokonferanse.

Ikke nødvendigvis hør på alle råd

Hvis du får muligheter til å ta en jobb som har et distribuert team, så er det verdt å sjekke ut. En liten viktig ting er å sjekke at dere er i samme tidssone. Etter hva jeg har hørt er det en helt annen greie og kanskje ikke så chill om dere er ca på samme tidssone (selv om min første remote jobb var på tvers av tidssoner og var bra, så tror jeg det først og fremst var fordi vi var et team på to mennesker).

Hvis du leser på nettet om Remote Work er det selvsagt en mega industri som er veldig klar på at dette med å jobbe distribuert krever at du leser masse greier, kjøper bøker, handler inn kontormøbler, setter deg inn i hvordan du skal gjøre dette mega endringen. Det er litt som når du får barn for første gang og begynner lese alle tingene du bare  ha, men som du senere innser er fullstendig unødvendig.

Jeg kjøpte 37 Signals sin Remote: Office Not Required bok, som var nyttig og lese men kanskje mest nyttig for de som trenger argumenter for å begynne jobbe distribuert. Utover det har jeg ikke gjort noe. Dagene jeg er hjemme sitter jeg ved kjøkkenbordet (fordi det er ikke plass til noe kontor). Jeg har ingen spesiell rutine annet enn å levere unger dit de skal også få meg kaffe.
Folk er selvsagt forskjellige, men det er verdt å ikke lese for mye og heller bare prøve seg frem selv. Snakk med folk du kjenner og stoler på som har gjort dette alt.

Hva er anderledes?

En ting jeg merker veldig er at du må være flinkere til å formulere deg presist og kanskje bruke litt lengre tid på å utforme det du skal kommunisere. For meg personlig er det ekstremt positivt, da jeg kan være litt vel rask og noen ganger ikke helt være innforstått med at kanskje ikke alle vet alle detaljer jeg har i mitt hodet. Du merker at det å bare slenge ut noe på Slack ikke funker så bra. Tidligere har jeg gjort det mye, men da har jeg som regel tatt det “offline” rett etterpå for å liksom rette opp i ting som ble misforstått.
Jobber du distribuert så må du rette opp alt skriftlig også, noe som kan bli lange og tunge chat dialoger. Så jeg forsøker å bli flinkere til å komme med litt mer gjennomtenkte og velskrevne ting for å unngå lange chat tråder.

Dokumentasjon kommer automatisk, fordi du må formulert noe skriftlig for å gjøre noe. Dermed har du allerede før du begynner noe dokumentasjon og for å forklare dine intensjoner klart ovenfor de andre må du som regel skrive litt til når du er ferdig med en oppgave. Vanligvis kunne du bare reist deg opp også sagt “ey, jeg har laga noe kom å se” eller tatt det i lunchen. Distribuerte jobbing gjør at du er nødt til å ha en “papirsti” for at andre skal kunne forstå hva du holder på med.

Credit: https://www.flickr.com/photos/indi/3104247104/

Sjefer som er vant til å være “manager of chairs” vil bli helt åpenbart unyttige og være uten hjelpemiddel til å fortsette styre teamet på en gal måte. Å være på team hvor viktigste delen av jobben er å ha ræva si på en stol på et kontor er ikke gøy og ekstremt demotiverende. Ved å fjerne muligheten til å kalle “å se at folk er på jobb” ledelse så flyttes også fokus på hva det er som leveres av verdi. Det er ekstremt positivt og kanskje en av de aller største fordelen med distribuerte team.

Jeg merker at jeg må jobbe litt med min holdning / fremtoning i video møter. Hvis hele kroppen min og stemmen min utstråler “jeg vil gjøre noe annet, make it stop!!” så er det ganske dårlige signaler. I vanlige møter kan du rette dette opp med “koseprat” før / etter møtet, mens i videokonferanse får du liksom ikke det.

Konklusjon:

Å uttale bastant at dette er AWESOME etter rundt to måneder er i overkant naivt. Jeg vil si jeg er overrasket over at jeg liker det såpass bra allerede. Skepsisen jeg gikk inn i dette med er i ferd med å forsvinne. Jeg merker at friheten og ansvaret du får ved å jobbe distribuert passer med bra, kanskje varer det også.

Culture For Collaboration

“It is so cumbersome to have go round talking to people and submitting pull requests. Can’t we just go ahead and just duplicate or do whatever we want?”

Yes, working together and collaborating is hard. It requires a willingness to listen to others and learning about different points of view. This is of course something which takes time to get right.  Because it is about people and dealing with people is different each time and for each interaction.

The past few years there has been a tendency to focus only on a team. The team is always entitled to do whatever they feel is correct and requires at the time. Especially a team should always shy anything that is common. Libraries, frameworks and any common component will only slow a team down. This is the mantra of many agile thought leaders.

Now, if you look at this in a short perspective and with only an isolated project I would agree. However if you are looking at this from cultural and a human level, I disagree. If ever team shy away from anything created by outsiders, how can you create a sense of community? A Not Invented Here on a team level will really hurt a company. It makes collective code ownership almost impossible of course.

Having a culture for collaboration does not equal a culture of building massive frameworks and over engineered architectures. I think it boils down to making choice based on the common good and not what is fastest or easiest right then and there. It is about taking into account how you can make things better for the next person being in your position. 

It is kind of like the boy scout principle on a team level. When a team encounters an issue: a library which is outdated, some code which needs refactoring or a module which isn’t quite generic enough for their use case. The team tries to see how they can improve it and still get things done. Naturally there will always be a balancing act, but the instinct should be to seek to improve the whole.

Never listen to thought leaders

The mantra of the thought leaders tend to be quite the opposite. They have one great enemy, the software architect. In order to conquer this nemesis they say that all developers should go choose what’s best for them and it will always be the best solution. To me, that is someone speaking who haven’t been staying with a company for very long. It is a short sighted approach, to instruct teams to build walls around them. That kind of strategy works really well for contractors and especially when you have fixed price or goal price style contracts. You deliver really quickly and reach your targets, without the slightest thought about those who’ll be living with that code when you’ve left. 

Embrace openness

Having a culture where teams embrace openness and which tries to reach out to improve the whole will prove beneficial in the long run. It will help you build an organization which will gradually improve and continuously build with better quality and quantity. 

Quote

Our list of demands

I am working on a rewrite of the web tier at work. We’ve set this up as a “dugnad” where we do a section at a time with the team responsible for that part of our service. This effort is called the Strap-on Project and each section should take max 3 weeks (which is our release cycle).
When we bring in people (max 2) we have a list of demands in order to make things work:

  • No meetings or similar activities during your stay with us
  • The person joining in is responsible for all communication with the rest of his team
  • There will be no status meetings or similar activities except what the person joining does on daily stand up with his team

These points might seem odd, but you’d be amazed how happy people are to hear them. After the three week spell there is a case of strap-on blues. Because nothing beats just working, right?

The core Strap-on team does not communicate with the team we work with. This sounds strange, but the purpose is to make sure the team responsible for the section we work with feels ownership and take responsibility for the end result.

This is not some magic formula. It is just what we figured would be a way of doing it and it probably won’t work anywhere else.

Jeg vet hvorfor du ikke lykkes med Scrum (eller noen annen metode for den del)

I artikkelserien “jeg vet hvorfor” skal jeg nå ta for meg Scrum, men jeg tror dette gjelder alle metoder. Den absolutt mest utbredte av de smidige metodene er Scrum og den benyttes på så mange ulike måte og tolkes i så mange retninger at den naturlig nok begynner å miste litt av den sølvfargede glansen metoden hadde da den først kom. Årsakene til hvorfor mange føler de ikke lykkes med Scrum er like mange som årsakene til at andre føler de får mye igjen for å benytte metoden. Jeg har vært i kontakt med mange som hevder å benytte Scrum og det er selvsagt en enorm forskjell i hvordan metoden brukes rundt omkring. Likevel vil jeg påstå at det er en fellesnevner for alle de som ikke får Scrum til å fungere.

Lille speil på veggen der…

Jeg hadde gleden av å delta på Mike Cohn’s Scrum Master “Sertifisering” i fjor og en av tingene jeg sitter igjen med er det Mike sa om at:

“Scrum løser ingen problemer, den bare viser deg problemene dine”

Dette er selvsagt ikke noe som du nevner når du selger inn metoden, ettersom ingen vil ha noe som bare viser deg problemene uten noen løsning. Følgelig blir veldig mange skuffet når det viser seg at Scrum kun visualiserer og bringer for dagen alle problemer du tidligere har forsøkt å feie under teppet. Du titter i speilet og alt du ser er utfordringene du har slitt med tidligere og dette fra noe som alle mener er så bra. Naturlig nok sitter en ofte skuffet tilbake og begynner å se etter neste ting som lover å løse dine problemer uten noe jobb. Det er også en del andre ting som Scrum lover og dette snakker Geir Amsjø om i Hva oppnår du med Scrum?.

Arbeit macht frei

Arbeidet skal sette deg fri, og slik også når det gjelder metodearbeid. Hvis du skal lykkes med å implementere en metode må du være beredt på at det krever endringer. Gjerne store endringer som vil gå langt utover f.eks et prosjekt. Scrum vil i stor grad vise deg hvor problemene er og hvorvidt du skal få ønsket effekt ved å bruke Scrum avhenger 100% av din evne til å endre omgivelsene. Uten store endringer i både prosjekt og i omgivelsene vil du aldri lykkes særlig bra med Scrum.

Klarer du ikke å ha hyppige leveranser fordi du har en driftsorganisasjon som evner å ta i mot mer enn 1 gang i året? Vel, da må du ta tak i det. Hvis du ikke har noen som kan fungere som produkteier eller være kravstiller, ja så må du ta tak i dette å stable noe på beina.

Når Scrum ikke er nok..

Dette med endringer rører ved noe av det som mange snakker om i disse dager, nemlig at Scrum er en metode for prosjekt gjennomføring. Et prosjekt er noe flyktig som har en start og en slutt, mens organisasjonen som betalte for prosjektet består. Mangelen på helhets fokus er hva jeg mener er Scrum’s akilleshæl. Metodikken gir deg kun hjelp til å belyse mangler og gjennomføre et prosjekt. Utover dette er du på egenhånd og får liten hjelp. Organisasjoner trenger et helhets fokus og en måte å tenke på som hjelper i mer enn bare praktisk prosjektgjennomføring.

Lean, the “new” kid on the block

Veldig mange har begynte å snakke om Lean som et svar på manglene vi har erfart med Scrum. Mytologien rundt Lean har mange ingredienser som gjør at det er en sikker hit blant IT-folk: et ekskluderende vokabular av Japanske ord, har sitt opphav i østlige tanker og er noe nytt. Tiltross for all hypen som vi har sett, og som vi kommer til å se enda mer av i årene som kommer, så tror jeg faktisk at helhets fokuset i Lean er hva Scrum mangler for større organisasjoner.

Presisering rundt sosialdemokratiet

Jeg var så heldig å få sjansen til å holde min lyntale på Oslo XP Meetup igår. Det var utrolig spennende fordi det var diskusjon umiddelbart etter lyntalen. I motsetning til på konferanser så måtte jeg her svare for mine tildels breibente påstander om det ene og det andre.

En ting jeg åpnebart formidlet uklart var dette rundt spesialistenes rolle i smidige prosjekter. Mange tolket mine utsagn til at man skulle ha spesialister som kun jobbet med sin spesialitet og at ingen andre på teamet gjorde det. Dette er like dumt som bare å ha generalister og mitt poeng er at du må sørge for å utnytte spesialisten slik at du hever kompetanse på resten av teamet. Spesialisten må selvsagt kunne gjøre mer enn sin spesialitet og det er viktig å sørge for at spesialistens kunnskap kommer resten av teamet tilgode.

Det var også nevnt i diskusjonene at spesialister som får jobbe i fred på sine egne ting er et kjempeproblem når denne personen ikke lengre er til stede, og igjen er jeg helt enig her. “Smarte” programmerere er et kjempe problem dersom de sitter alene å koker opp noe, så de må selvsagt tvinges til å jobbe med noe annet også.

Lyntaler er ofte slik at de fungerer best om man ikke tar med de grå nyansene, og jeg holder de som regel med Caps lock’en på. Slik at det er selvsagt mange nyanser rundt tingene jeg snakker om i Det Smidige Sosialdemokratiet, men det blir en kjedelig tale om jeg tar med det også.

Takk til alle som kom med spørsmål og feedback under Meetup’en, det var utrolig gøy å få snakke der og jeg gjør det gjerne igjen.