Alle kan mer enn én ting

Jeg har jobbet som programmerer i over 20 år. Mer eller mindre samme jobbtittel hele veien. Men betyr det at det å skrive kode er det eneste jeg kan? Når programmeringen sitter i fingrene, så brukes ikke lenger all mental kapasitet på å finne ut av hvordan strukturere kode for å kunne lukke en task i Jira. Man tenker større: hvilket problem skal denne koden egentlig løse?

Etter mange år med samarbeid mellom folk i forskjellige disipliner, får man også innsikt i hvordan disse rollene kan utøves. Arkitektur, UX, prosjektstyring, prosess-fasilitering, dette er noe man etterhvert får en god del erfaring med, selv om man er ansatt som “programmerer”. Selv har jeg til og med gått diverse prosjektlederkurs (delvis ufrivillig dog) og lest masse bøker om ledelse og produktutvikling (helt frivillig).

Med TDD og DevOps-bevegelsene har det etterhvert blitt naturlig å forvente at utviklere også kan være ansvarlig for både testing og drifting av sine løsninger. Må det stoppe her?

Jeg tar for mye plass.

Jo mer erfaring jeg får, jo dårligere passer jeg inn i boksen “programmerer”. Jeg klarer ikke la være å “bre meg utover” forbi det snevre kode-fokuset. Javisst, jeg digger å finne gode tekniske løsninger på konkrete brukerbehov. Det å finne elegante løsninger i kode, enkel kode, effektiv kode, kode man lett kan sette seg inn i, kode som er lett å teste, kode som er lett å endre; Jeg koser meg virkelig med disse utfordringene, og har ingen ønsker om å slutte å jobbe som utvikler. Men jeg ender alltid opp med å gjøre så mye mer!

Det er naturlig nok ikke alle roller jeg ville vært komfortabel med å levere på. UX for eksempel har jeg dessverre jobbet altfor lite med. Men jeg har masse kunnskap om hvordan utviklingsarbeidet bør organiseres for at vi skal kunne levere best mulig. Hvis jeg er helt ærlig, så føler jeg meg mer komfortabel med å jobbe med dette enn de mer tradisjonelle “drifts”-oppgavene det etterhvert forventes at jeg skal ta meg av som en del av utviklerfaget.

Betyr det at jeg må ta meg jobb som prosjektleder? Nei, da får jeg jo samme problem, bare motsatt: At jeg som prosjektleder har masse å si på hvordan koden kan skrives, uten å få lov til å bidra der.

En person tar mindre plass enn to.

Må man velge kun en rolle?

Hvorfor det?

Hvem er tjent med denne strenge inndelingen?

Det at en organisasjon trenger både utvikling, UX, test, prosjektstyring, prosess-fasilitering, osv osv betyr jo ikke at man trenger én person til hver ferdighet/rolle. Hvis en person kan levere på flere områder, så ville det kanskje vært en fordel for alle parter? Man kunne få to roller til prisen av en, kanskje tre for en! Det er en kjempedeal! Det kan redusere kostnader og øke effektivitet samtidig.

Noe av grunnen til at startups er mer effektive enn store organisasjoner er at de er færre folk, der de få som er der tar mer ansvar. Det er ingen grunn til at større organisasjoner ikke skal kunne benytte seg av akkurat samme teknikker for effektivisering.

Programmerere som samarbeider

I team der programmerere sitter mye sammen og jobber, og kjenner ansvar for produktet som lages, tar mange erfarne utviklere automatisk på seg roller som minner om både scrum-master og produkt-eier. Det er ikke uvanlig at utviklere både har mer erfaring med produktet som lages, og med prosessen som skal følges, enn det prosjektledelsen har. Når slik en gjeng utviklere sitter sammen og skriver kode, diskuterer man helt naturlig hva som må gjøres, hvordan man skal gå frem, hvem man må koordinere med osv osv. Hvis produkt-eier/scrum master rollene var noe utviklerne hadde selv, så kunne disse diskusjonene ført til direkte handling. Når ledelsen og ansvaret er eksternt, må man ty til verktøy som Jira, kalle inn til møter, skrive eposter, og andre former for byråkrati for å få opprettet bestillinger tilbake til en selv.
Dette skaper frustrasjon for alle parter. Utviklerne blir frustrerte over at de ikke bare kan løse problemene de vet de må løse. Samtidig kan ledelsen føle at de mister kontroll hvis utviklerne begynner å gjøre for mye utenom det offisielle byråkratiet. Begge deler er legitime bekymringer og frustrasjoner.

Jira-helvete og Smidig-fail

Dette er en dynamikk jeg synes det må snakkes mer om i smidig-miljøer. Utviklerne sier de hater Jira, og ledelsen sier de ikke har oversikt. Jeg regner med dette høres kjent ut for flere. I en hverdag der utviklerne sitter isolert hver for seg og nesten hjernedødt plukker ferdigspekkede tasks fra øverst i en backlog, så kan Jira og scrum funke helt fint.
Men ikke kom og kall dét smidig. Du kan i alle fall ikke kalle det et autonomt og selvorganiserende team. Tilhengere av scrum- og andre sprint/batch-baserte prosesser med separate dedikerte leder-roller (som produkt-eier) tar ofte til orde for nettopp selvorganiserernde, autonome team som kjenner domenet, tar ansvar og jobber sammen, gjerne med parprogrammering og “mob programming”. Man ber eksplisitt om arenaer der oppgaver og løsninger naturlig planlegges og utvikles i felleskap, kontinuerlig, uten at produkt-eier eller scrum master er tilstede. Hvordan får produkt-eier da prioritert effektivt, når de ikke er tilstede i de arenaene det er naturlig at oppgaver oppdages og utformes? Prosjektstyrings-verktøyene som anbefales passer også dårlig: Hvordan passer oppgaver løst i felleskap inn i et prosjektstyrings-verktøy der alle oppgaver skal tilegnes individer?
Jo større avstand det er mellom produkt-eier/løsnings-arkitekt/scrum master og utviklerne, jo verre blir Jira-løsningen, da den må stå for all kommunikasjonen mellom disse gruppene. Jo tettere samarbeidet er mellom produkt-eier og resten, jo mindre blir denne byråkratiske byrden. Du får ikke tettere samarbeid enn om produkt-eier og utvikler er de samme folkene. Selv har jeg mest tro på at utviklingsteamet i fellesskap tar på seg så mange av disse rollene de har kompetanse til å levere. Det er utrolig motiverende å jobbe sammen med folk som alle bryr seg og bidrar til å lage gode løsninger i felleskap.

Ingen må ta roller de ikke vil ha

Alle trenger selvsagt ikke ta på seg mer enn en rolle. Jeg holder stadig foredrag der jeg tar til orde for at utviklere bør ta mer ansvar og bli kjent med brukerne og være med å forme løsningene. Flere ganger har jeg i etterkant hørt fra folk som opplever at deres utviklere ikke er interessert i dette. Hvis det gjelder deg, kommer jeg gjerne på hospitering for å gi råd og tips. Dette er nemlig ikke en beskrivelse av utviklere jeg kjenner meg igjen i, så jeg mistenker at at det er ubevisste kulturelle eller prosessmessige ting som er i veien. I min erfaring trives de fleste utviklere godt med å ta mer ansvar for produktet. Det er en stor fordel om flest mulig på teamet har et nært forhold til formålet med produktet de lager.

Men uansett, dersom utviklerne virkelig ikke er interessert, så skal de åpenbart ikke påtvinges arbeidsoppgaver de ikke motiveres av. Det jeg vil frem til, er at dersom du har folk i din stab, som kan fylle flere roller, så bør du la dem gjøre det. Det er mer motiverende for den ansatte/innleide, og mer effektivt for organisasjonen som helhet.

Skjult sales pitch?

Er dette egentlig en salgspitch for å rettferdiggjøre høyere timerater for senior-utviklere som har mange flere ferdigheter å spille på? Ja, det er det også. Men jeg mener helt oppriktig at dette er vinn vinn, og at de som tar mer ansvar fortjener høyere rater. Det er både billigere og mer effektivt å få inn erfarne folk som kan levere på flere roller, enn å skulle hyre inn en og en til hver ferdigdefinerte rolle. Ikke bare blir totalprisen av flere folk høyere, men man må også faktorere inn ineffektiviteten som kommer av at flere mennesker bruker mer tid på koordinering seg imellom.

DevTestSec­BusinessMgmtUxOps

Men hvordan får vi til dette i praksis? Innen programmering har vi uttrykk som DevOps og Full-stack. Klarer vi finne ord på andre sammensetninger? Må vi ha ett uttrykk for hver kombinasjon? Det skalerer dårlig. Men noe burde vi finne på. Jeg ønsker, både for meg selv, andre som meg, og for våre oppdragsgivere, at vi skal kunne levere mest mulig verdi for pengene. Da kan det være dumt å leie inn de flinkeste utviklerne som “kun programmerer”. Hvordan får vi til dette? Hvordan kan man selge seg inn i flere samtidige roller?
Kanskje bare det å skrive om problemet er en god start? Jeg håper det!