Digitaliseringen i Norge skjer med en forrykende fart, og fagområdet har utviklet seg voldsomt de siste årene. Kontinuerlig leveranse er i ferd med å bli standarden for utviklingsteam, og autonome team har vi hørt om utallige ganger. Når det kommer til ledelse av disse utviklingsteamene, eller produktteamene som det har blitt vanlig å kalle dem, har konseptet produkttrioen («product trio») gjort sitt inntog de siste par årene. I sin enkleste form handler dette konseptet om å sørge for at man har produktledelse, design og teknologi representert når man skal lage et digitalt produkt. Min påstand er at vi i kjølvannet av fokuset på autonomien og produkttrioen har glemt teamlederen, og at teamlederen er mer kritisk nå enn noensinne.

Teamledelse er et eget fagfelt, og det overlapper ikke med noen av de andre fagfeltene i produkttrioen. Det betyr ikke at ingen evner å gjøre begge deler, men heller at man kan mestre det ene uten å mestre det andre. En historisk felle mange har gått i, har vært at den mest teknisk kyndige i et team også har fått ansvar for teamet. Ofte samsvarer ikke dette med vedkommende sine interesser eller ferdigheter. Teamledelse handler i bunn og grunn om folk, og samhandling mellom folk. Jeg forventer dermed at en teamleder har stålkontroll på smidig utviklingsmetodikk, menneskelige relasjoner og samarbeid. Dette inkluderer blant annet:

Rigging av en kanbantavle for teamet, med tilhørende prosesser som for eksempel standups.

Tett oppfølging av folk med kartlegging av ambisjoner, utfordringer, preferanser og egenskaper. Tett oppfølging av folk inkluderer trivsel, og kan eksempelvis standardiseres ved hjelp av employee Net Promoter Score (eNPS).

Være sentral i bemanningsdiskusjoner. Dette handler essensielt om å svare på et enkelt spørsmål: Har vi de rette folka i teamet (gitt rammebetingelsene)? Dette henger svært tett sammen med punkt 1 og punkt 2. En person som ikke er tett på den faktiske samhandlingen og enkeltpersonene i teamet har ikke den nødvendige innsikten for å fatte gode bemanningsbeslutninger. I min erfaring er det dessverre svært vanlig at det tas dårlige bemanningsbeslutninger (på bakgrunn av mangelfullt grunnlag) når man ikke har en teamleder.

Være et kontaktpunkt for utfordringer folk i teamet sitter med. Dersom man ikke har en teamleder, hvem skal man oppfordre teammedlemmene til å snakke med?

Sørge for at DORA-metrikker måles i teamet, samt følge utviklingen av disse.

Jeg forventer ikke at en tech lead, designer eller produkteier skal ha ansvaret for dette. Det ligger ikke i kjernen av deres rolle, og kompetansen de trenger overlapper i liten grad med kompetansen som trengs for å ivareta disse momentene. Ved å investere i dedikerte roller får vi spesialister som i sum har dypere kompetanse. Alternativet gir oss folk som er «jack of all trades, master of none».

Teamlederen er teamets kontaktpunkt for omverdenen. Samarbeid er krevende, og å ha en dedikert rolle som har ansvar for dette er svært nyttig. Det handler om at eksterne kan komme til teamet og spørre om alt fra hvordan går det med folka, til når en leveranse er klar, til hvilke avhengigheter teamet har til andre team. I dette ligger det et behov for en totaloversikt, som ingen andre roller naturlig får. Dersom en annen rolle skulle oppfylt dette måtte man dedikert mye tid på siden av kjernen i det man gjør for å få det til. Som ekstern interessent er det effektivt og oversiktlig å forholde seg til én person for alle henvendelser som angår et team.

Dersom man tenker at man ikke trenger teamledelse, og baserer seg på at en produkttrio sørger for det vi trenger, hvem er da ansvarlig for teamet i helhet? Er det tiltenkt å være et delt ansvar for de i produkttrioen? Da har jeg en historie å fortelle deg om Alle, Ingen, Noen og Hvem-som-helst: Alle trodde at Noen skulle gjøre jobben Hvem-som-helst kunne gjøre, men som Ingen tok. I min erfaring er det typisk slik det blir i praksis. En dyktig teamleder håndterer eksterne forespørsler og behov, og dette skjermer hele teamet. I tillegg til å skape arbeidsro internt i teamet er dette uvurderlig for samarbeid på tvers av team. Dersom dette behovet ikke ivaretas av en teamleder, vil teamet utsettes for mye støy. Dette gjelder alt fra enkelthenvendelser til inkludering i arenaer på tvers av team.

Å ha en teamleder i et team reduserer organisatorisk risiko. I den klassiske boka «The Phoenix Project» blir vi kjent med Brent. Brent er usedvanlig sentral: Han kan ekstremt mye, og svært mange oppgaver må gå via ham. Foruten det faktum at dette er en ineffektiv måte å jobbe på fordi Brent blir en flaskehals, utgjør det en kjempestor risiko for teamet. Hva gjør man dersom Brent blir borte? Han kan si opp (flinke folk har som regel mange attraktive muligheter) eller bli syk. Utbrenthet er en reell trussel, spesielt for en person som er så overlesset med arbeid. Hvorfor skal vi legge opp til en organisering som medfører så stor risiko? Ved å spre dedikert ansvar over flere roller får vi ikke bare rendyrket den faglige kompetansen som skal til for å lykkes, vi reduserer også risikoen betydelig. En bonus ved en slik tilnærming er at den gir flere karrieremuligheter, som lar oss løfte opp flere talenter. Mange har erfart at talenter sier opp på grunn av opplevd mangel på spennende muligheter: Det er ikke det at folk ikke er flinke nok, det er bare rett og slett ikke flere roller som trengs å fylles. Da blir flinke folk typisk utålmodige, og søker lykken andre steder.

Vi befinner oss i et paradigmeskifte i vår bransje hvor vi er i ferd med å gå fra en prosjektdominert utviklingshverdag til produktorientering med kontinuerlig leveranse. Det er en totalomveltning som krever betydelige endringer av hele virksomheter for å lykkes. Eksempelvis må toppledere lære seg å gi slipp på kontroll og delegere autonomi til teamene, og team må lære seg å jobbe målstyrt og forplikte seg til effektmålene de har satt seg. Vi må få en generativ kultur på tvers, og vi må finne den riktige balansen mellom autonomi og retning. I denne totalomveltningen mener jeg det er kritisk at ansvaret for teamet er plassert tydelig hos én person.

Jeg har jobbet som konsulent i Bekk i 11 år. I hele den perioden har jeg jobbet i, og tett på, utviklingsteam. De siste fem årene har jeg også hatt personalansvar for et tyvetalls teknologer, spredt utover vår kundeportefølje. Jeg har fanget opp mye fra store aktører på både offentlig og privat side i Norge. Summen av dette gjør at jeg ikke er i tvil om at team presterer og leverer bedre med teamledere: Folk har det bedre på jobb og samhandler mer effektivt. Når vi i tillegg legger til grunn paradigmeskiftet vi står i mener jeg konklusjonen er tydelig:

Teamlederen har aldri vært viktigere.











Teamlederen er viktigere nå enn noensinne

Okej! Du har kanske hört talas om Docker. Men har du hört talas om DevContainers? Paketera hela utvecklingsmiljön in i docker och koppla dig till den helt lagg-fritt från din lokala editor! Det borde vara vanligare än det är - låt oss se vad det handlar om...


Om du är riktigt inne i träsket har du kanske till och med hört talas om Docker compose. Det var i alla fall så långt jag hade kommit i "virtualisering" av min utvecklarvardag. Och ändå satt jag där för 10e gången på ett år och skulle försöka få någon antik kod med ett obskyrt frontend-ramverk att köra. Jag som egentligen bara ville implementera en ny feature i ett av våra interna system ute hos kunden. Slet mig i håret för att jag återigen behöver sätta mig in i byggsystem, dependencies, konventioner, avsaknad av linting/hjälpmedler för just det språket m.m. I grund och botten vet jag ju vad jag ska göra med koden, men att få det runt omkring upp och köra är ofta ett projekt i sig.

Detta är något som man ofta stöter på i rollen som konsult, eller som del av ett team som försöker skapa en snabbare onboardingprocess för ny anställda (eller inhyrda konsulter). Jag trodde detta bara var "som det var", och att lösningen hette "standardisering av projekt-setup" och en bra dokumentation i varje projekts README om hur man bäst kommer igång. Det var därför jag fort blev väldigt intresserad när jag läste om "DevContainers" för första gången.


Här är hiss-säljsnacket (elevator pitch):

Tänk dig att någon som har koll på allt med projektet, går in och konfigurerar din maskin och utvecklingsmiljö helt perfekt för att göra utvecklingsjobbet - du kan hoppa direkt på det som faktiskt är kul - utveckling av business logik/APIer och den nya fina frontenden.

DevContainers är ett sätt att definiera inte bara hur programmet kan köras i Docker, men också allt det runt omkring så som linters/plugins/package-hantering som förväntas finnas på plats i det givna IDE't som används. Jag kommer använda VSCode som exempel, men motsvarande teknologi finns för IntelliJ också.




Låt oss ha ett exempel. Jag är utvecklare på ett team där vi har ett projekt som har en Express webserver och en Postgres databas.
Då kan vi skapa en simpel DevContainer för detta. Filstruktturen ser ut såhär:



En devcontainer fil:

Med tillhörande docker-compose.yml och två Docker filer:





Om vi nu har ett repo med denna foldern incheckad, och en VsCode IDE där vi har laddat ner denna från CMD-SHIFT-P > Dev Containers




Så är det allt som ska till för att nu köra CMD-SHIFT-P > Dev Container: Rebuild Container Without Cache

Vi kan nu slänga ihop en simpel express applikation:



För att få någon data att jobba med, använder vi en feature av postgres databas-imagen som gör att man kan seeda data om det ligger i en speciell folder, så vi placerar följande i ./pg_init/init.sql
som vi kopierade in under /docker-entrypoint-initdb.d
i Dockerfile.pg tidigare.


Eftersom vi har "forwardat" port 3000, kan vi nu besöka localhost:3000/users  - och se där!



Detta är egentligen mest Docker compose magi, i kombination med den "init" featuren från postgres imagen som är ganska cool på egen hand.

Det fina är att vi nu också har den integrerade terminalen i VS Code. Denna kommer koppla upp sig mot den docker compose containern som vi har specificerat som service i devContainer.json filen. Här kanske vi skulle vilja använda psql för att kunna debugga fel i koden också, eller för att manuellt föra in mer data. Låt oss installera psql i vår devcontainer image:


När vi nu öppnar terminalen i VSCode, kan vi köra psql postgresql://postgres:postgres@localhost:5432/postgres och vi är nu kopplat mot Postgres databasen från samma container som vår Express app kör. Tänk vad najs nu när din kollega har några problem och du hoppar in på videomötet för att hjälpa: Du vet att hon har psql installerat så det är bara att börja att felsöka, istället för att sitta och installera det manuellt.


Det finns också stöd för att i devContainer-speccen beskriva vilka extension som ska vara installerade. Inuti devcontainers.json lägger vi till:



Vi kan nu köra CMD-SHIFT-P > Dev Containers: Rebuild Container Without Cache, alltså öppna kommand-paletten och köra dev containers kommandot för att bygga om hela DevContainern. När vi nu försöker skriva kod, får vi spell-check på det vi skriver. Vi får också "tab completions" som är en funktion i VsCode för att föreslå kodförslag om man trycker på TAB. Det får också alla andra som försöker röra denna koden och som använder sig av vår DevContainer. Nice!




Varför är inte detta vanligare där ute i det vilda?



Jag antar att det har lite att göra med att det kanske upplevs som en tröskel att sätta upp allt, eller att nuvarande setup fungerar "bra nog" för att det ska vara värt att lägga tid på. En bidragande faktor kan säkert vara att folk har sitt egna uppsätt på maskinen som fungerar för dem. De vill helt enkelt använda sitt IDE på sitt sätt och inte dra in massa config från någon annan. Men, egentligen förstår jag inte varför vi inte bara använder det här hela tiden - det finns inget bättre än när "någon" bara har fixat allt och jag kan börja koda. Samt att man får den skalerings-effekten av att om jag fixar vår DevContainer, så får alla nytta av det direkt. Fått en ny dependency, eller börjat använda en ny tool? In med det i DevContainern så alla kan få använda det. Jag är säker på att jag kommer försöka pusha för DevContainers nästa gång jag är ansvarig för att skapa ett nytt projekt/kodbas. Något vi inte hann gå igenom här, men som också är väldigt intressant, är att det inte finns något behov för att köra detta lokalt. Du kan ha DevContainern körande på en remote maskin eller till exempel GitHub Codespaces, som är en SaaS lösning som baserar sig på detta konceptet. Men mer om det en annan gång!

Har du några insikter/åsikter här? Dela gärna med dig!


Sammanfattning

Vi har nu skrapat lite på ytan av den här nya paradigmen som buntar ihop koden med dess kör-miljö, dependencies OCH utvecklingsmiljö på ett sätt som vi kan återanvända och checka in i Git. Vi har sett hur man med en grundinsats i början på ett projekt kan skapa förutsättningar för vem som helst att fortsätta utvecklingen utan att skapa massa problem på den personliga maskinen. Vi fick också sett lite snabbt på hur man enkelt kan få upp en test-databas och seeda den med data, samt felsöka mellan containers.

En släde kommer lastad med DevContainers!

Synes du retroer ofte tar for lang tid? I denne artikkelen får du den enkleste formen for retro du kan kjøre som både er raske å gjennomføre og som ikke krever noe utstyr. Her trenger du bare deg selv, teamet, tankene og følelsene dine.

Dette er del 2 av en serie med forslag til retrospektiver du kan bruke i ditt team. Del 1 finner du her. Alle retroene som blir presentert i serien kan finnes i Retrobanken.

What’s up Wednesday: snakk løst og ledig om uken så langt

Lavterskel øvelse for å kjenne på stemningen blant folka og lufte småproblemer tidligere

Tidsestimat: 20-30 minutter.

Passer for alle team hvor man vil lufte tankene og ikke føler for en fullspekket retro.

Mal: ingen.



What’s up Wednesday er en uformell sjekk-inn med teamet i løpet av uken. Av og til merker man at små problemer i teamet kunne vært løst tidligere, kanskje uten å måtte vente på en lengre retrosesjon. What's up Wednesday er en god mulighet til å ta opp mindre problemer/friksjon i teamet.

What’s up Wednesday er en kortversjon av en retro, og er veldig avslappet og løs i formatet. Så avslappet og løs at vi anbefaler å finne dere en sofakrok eller gå en tur rundt bygget mens den gjøres. Er du lur, kjører man denne rett rundt to-knekken fordi da trengs det uansett en pause.

Gå runden i teamet og lag rom for at hver enkelt kan ta opp det de måtte ønske. Om det er vanskelig å få i gang praten kan man bruke noen av spørsmålene under:

Hvordan synes du uken har vært til nå?

Er det noe som gjør at du blir hindret i arbeidet ditt? Er det noe som ikke fungerer helt som det skal?

Hva har fungert bra denne uken? Hva har vært gøy med oppgavene du har hatt?

Mood check-in: ta en humørsjekk på teamet

Få et innblikk i hvilket humør teamet er i.

Tidsestimat: 10-15 min.

Passer for team som vil rette blikket innover mot enkeltpersonene i teamet

Mal: Mood check-in (valgfritt, kan også kjøres uten).

Ta tempen i teamet! Mood check-in gir teamet muligheten til å dele hvordan dere har hatt det på jobb. Legg følelsene på bordet, og vær en aktiv lytter. Med en slik check-in oppstår det muligheter til å hjelpe hverandre og løfte humøret i teamet!

Denne er perfekt for de som har hatt en tøff uke(r), har støtt på utfordrende arbeidsoppgaver, eller bare har behov for å dele tankene sine. Enkelt er det også! Ranger humøret ditt fra 1-5, hvor 1 er dårligst og 5 er best, og forklar hvorfor humøret ligger der det er. Hva har gjort at du har følt deg bra på jobb? Er det noe som kunne hjulpet på humøret?

Denne kan også taes før en vanlig retro, som gir et fint utgangspunkt videre i retroen, siden man har humøret til teamet i bakhodet. Det gir muligheten til å se hvordan lappene har påvirket et teammedlem og kan derfor gi en pekepinn på tiltak som bør innføres.

Følg med for flere forslag!

Fikk du ikke med deg første artikkel som omhandlet retroer med en artig vri? Les den her. Tredje, og siste, artikkel vil komme neste uke. Da skal dere gravere dypere 🔎

Retrobanken finner du her. 

Kilder

Illustrasjon til What's up Wednesday er fra Freepik.

Mal på Mood check-in er fra Nhi Tran.

Retrobank del 2 - Korte, gode og uformelle retroer hvor man kun trenger tankene og følelsene sine

VoiceOver clicks and mouse clicks are the same to the browser—so how can we differentiate them from each other?

The problem

A couple months ago I was coding away at some new dropdown components for our design system and came across an annoying issue. When using VoiceOver and focusing the input of my dropdown, VoiceOver announced: “… to display a list of options, press Control-Option-Space.” However, my dropdown did nothing when pressing Control-Option-Space—which obviously isn't good. 



My next issue then was: How do I know when the user presses Control-Option-Space? Some quick event investigation teaches me that Control-Option-Space sends out a normal click event. This means displaying my list with options when receiving a click event will work, but in my case I don't want to show the list when the user clicks with a mouse. 

My new issue now was: How do I know when the user clicks using VoiceOver? And this didn't seem to be as trivial. Web browsers can't detect screen readers[1] and VoiceOver sends normal click events … Well, after a lot of looking around I found one hacky way to solve my problem—it's not elegant but it works and is still better than nothing:

The solution

When sending click events with VoiceOver, the click position (i.e. the x and y coordinates) is always set to the center of the clicked element, halfway from the top and halfway from the left. An actual mouse click is very rarely placed exactly in the middle, so I used this to my advantage. I made a function that takes in a click event and tells me wether the click is within a small perimeter of the exact center or not. This tells me if the click was (most likely) a VoiceOver click or not. 



It's by no means a perfect solution and could break without notice, but for now it solves this very specific problem. 



A last notice

As a last notice, remember that VoiceOver isn't the only screen reader out there. This solution will likely not work for other screen readers and you should test your solution thoroughly. If you can solve your problem using traditional solutions you should always prefer that. In this case, the problem is VoiceOver-specific. The announced message did not reflect real usage, so we added extra functionality on top of an accessible component. Something like  isVoiceOverClick should never be used to build core accessibility functionality.

[1] Can you detect screen reader users



6-Dec

Today's posts

Teamlederen er viktigere nå enn noensinne

En släde kommer lastad med DevContainers!

Retrobank del 2 - Korte, gode og uformelle retroer hvor man kun trenger tankene og følelsene sine

How to detect clicks from VoiceOver