Ønsker du fart og flyt? Da må vi snakke samme språk først
Marielle Mortensdatter mener man må snakke samme språk på arbeidsplassen: – Når hele teamet bruker de samme ordene for de samme tingene, forsvinner ganske mange misforståelser.
Noen uker siden delte Mariell Mortensdatter sine tanker om hvorfor de flinkeste slutter. Nå har hun nye tanker – denne gangen om misfortåelser på jobb.
For noen år siden jobbet jeg på et offentlig digitaliseringsprosjekt. Flere etater rundt bordet. Utviklerne kalte det «brukerne», forskerne kalte det «arbeidstakere», og etatene kalte det «virksomheter». Alle mente de snakket om det samme, men det gjorde de ikke.
Vi brukte flere sprinter på å oppdage dette. Sprinter med research, prototyping og diskusjoner som traff feil fordi vi ikke hadde definert hvem vi faktisk laget løsningen for. Ikke fordi folk var inkompetente, men fordi ingen hadde tatt seg tid til å definere hva vi faktisk holdt på med.
Mange CTO-er og IT-ledere tror at fart og flyt handler om mer kapasitet. Flere utviklere, flere team, flere verktøy. Det stemmer ikke helt. Du kan doble staben og fortsatt stå fast hvis teamene dine ikke snakker samme språk. Det vil si, det faglige språket og ordene vi bruker for å beskrive domenet vi jobber i.
Jeg har sett det gang på gang, tverrfaglige team der data engineers, utviklere, designere og forretning sitter i samme rom, men lever i ulike virkeligheter. De tror de er enige, men det er de ikke. Da ender man fort opp med et system som ikke treffer, teknisk gjeld som hoper seg opp, og frustrerte folk som peker på hverandre.
Gjennom Domain-Driven Design (DDD), Design Thinking og Tight-Loose-Tight (TLT) kan vi bygge broen som mangler. Alle tre har holistiske tilnærminger som bryter ned siloer og krever dyp forståelse før vi i det hele tatt begynner å kode. Disse rammeverkene tvinger oss til å gjøre jobben mange hopper over. Her må man forstå problemet før vi løser det.
Eliminerer misforståelser
Hvor ofte har ledere i IT satt seg ned med domeneekspertene sine for å definere felles begreper? De tror de forstår domenet fordi de har lest en Confluence-side eller vært i et par kravmøter, men det holder ikke.
I DDD er «ubiquitous language» selve kjernen, et felles språk som brukes konsekvent i kode, dokumentasjon og møter. For de som ikke kjenner DDD, så handler det om et sett med prinsipper fra Eric Evans (2003). Disse handler om å modellere programvare tett opp mot forretningsdomenet, med felles språk og tydelige grenser mellom ulike deler av systemet.
Josefsson & Pettersson (2007) dokumenterte i sin fallstudie ved Høyskolen i Borås, hvordan et slikt domenespråk gjennomsyret koden og gjorde kundekommunikasjon enklere med færre feil.
Når hele teamet bruker de samme ordene for de samme tingene, forsvinner ganske mange misforståelser. Design Thinking gjør noe lignende, bare fra brukersiden. Gjennom empati, visualisering og workshops tvinger det alle til å starte med det samme spørsmålet, «er vi egentlig enige om hva problemet er?». Prosessen er iterativ, menneskesentrert, men den krever at du legger fra deg antakelsene dine før du starter.
Siloene du ikke ser er de farligste
Både DDD og Design Thinking er bygget for å se hele bildet. DDD deler komplekse systemer inn i avgrensede kontekster (bounded contexts), og kobler teknologi direkte til forretningsstrategi. Design Thinking setter brukeren i sentrum gjennom systematisk empati og prototyping.
I nordiske organisasjoner passer dette spesielt godt. Hofstedes forskning (1980, 2001) viser at de nordiske landene scorer svært lavt på maktdistanse, nemlig på grunn av vår flate struktur, høye tillit og forventninger om deltakelse i beslutningsprosesser.
Det vil si, vi har et naturlig fortrinn for tverrfaglig samarbeid, men det krever at vi faktisk utnytter det. Lav maktdistanse uten felles forståelse gir ikke et godt grunnlag for samarbeid. Det blir fort kaos dersom alle mener forskjellig og ingen tar ansvar for å samkjøre.
En svensk studie av Snyder, Ingelsson & Bäckström (2018), publisert i Business Process
Management Journal, fulgte tre produksjonsbedrifter over tre år. De fant at kombinasjonen av Design Thinking og verdibasert ledelse ga ledere ny innsikt i bedriftskulturen og økte
dialogen på tvers av nivåer i organisasjonen. Lederne begynte å forstå kulturen organisasjonen på en dypere måte. Det var dette i seg selv som drev engasjement, ikke et nytt verktøy eller en ny prosess, men forståelse.
Forstå før du bygger
Ledere vil ha fart, og det skjønner jeg. Men å hoppe rett på løsning uten å forstå domenet eller brukeren skaper unødvendig kompleksitet som bremser deg i årevis etterpå.
Hos det svenske konsulentselskapet Decerno bruker de DDD til å la domenet styre arkitekturen, ikke omvendt. I stedet for å starte med tekniske valg som databasestruktur, starter de med å forstå hva som faktisk skjer i virksomheten.
De gir aggregatene (de grupperte objektene som alltid hører sammen og behandles som én enhet), navn som «calculation» og «investment case», i stedet for tekniske begreper ingen i forretningen kjenner igjen. Det høres banalt ut, men det er akkurat denne koblingen mellom kode og virkelighet som mangler i mange team.
Design Thinking gjør det samme i empati-fasen, her observerer, intervjuer og lever man seg inn i brukerens virkelighet før man designer noe som helst. Det høres ut som en selvfølge, men det er stor forskjell på å faktisk brukerteste og det å krysse av for «brukertesting» i prosjektplanen.
Skap ekte autonomi med TLT
Der DDD bygger bro mellom forretning og teknologi, og Design Thinking setter brukeren først, handler Tight-Loose-Tight (TLT) om å sette de riktige rammebetingelsene for teamene.
For de som ikke kjenner modellen, TLT ble utviklet av Rune Ulvnes og er i bruk hos blant annet NAV og Telenor i dag. Konseptet er enkelt. Tight på retning og mål, hva og hvorfor, loose på gjennomføring, teamene velger selv hvordan, og tight igjen på oppfølging og læring.
Dette er et organisasjonsorientert rammeverk som har vist seg å fungere godt med norsk virkelighet. I tillegg passer den som hånd i hanske med den nordiske ledelseskulturen
Hofstede beskriver, med tillit, lav maktdistanse og forventning om at folk tar ansvar. Men her er det mange ledere som svikter. Av erfaring er de gode på den første «tight», hvor de setter mål og retning. De er også gode på «loose», hvor de gir teamene rom, men den siste «tight», med oppfølging, læring, tilbakekobling, glemmer de. Det som skjer da er at autonomien dør stille, fordi ingen lærer av det de faktisk gjør.
Bygg bro med context mapping
Dersom du virkelig ønsker å få tverrfaglighet til å fungere, lær context mapping fra DDD. Det er en visuell oversikt over avgrensede kontekster, kommunikasjonsmønstre og organisatoriske avhengigheter. Det høres teknisk ut, men egentlig er dette et gull lederverktøy.
Tenk på to team i samme organisasjon. Det ene kaller kunden «Kunde», det andre kaller den «Bruker». Begge har sine grunner, men når systemene skal snakke sammen blir det kaos. Context mapping viser hvor grensene går, hvem som eier hva, og hvordan informasjonen flyter mellom teamene.
Kombinert med TLT får du verktøy til å sette klar retning uten mikrostyring, slik at teamene kan snakke felles språk på tvers av siloer. Ingen kan tvinge et annet team til å endre språket de bruker, men du kan gjøre grensesnittene eksplisitte og forhandlingsbare.
Tre rammeverk, én forutsetning
DDD, Design Thinking og TLT er forskjellige rammeverk, men de deler én grunnleggende forutsetning, at du må ha forståelsen før du bygger. Alle tre motarbeider silotenkning, bare fra ulike vinkler.
Design Thinking tvinger deg til å spørre «trenger vi egentlig denne løsningen?» før du bygger noe som helst. DDD gir deg verktøyene til å strukturere kompleksiteten slik at systemene faktisk støtter forretningen over tid, ikke bare i neste sprint. TLT er limet som holder det sammen organisatorisk, ledelsesmodellen som gir teamene frihet innenfor tydelig retning.
Jeg sier ikke at jeg har alle svarene her. TLT-modellen er ikke fagfellevurdert forskning, og den passer nok ikke overalt. DDD kan bli for mye for et lite team med ett produkt, og Design Thinking kan fort bli teater hvis du ikke faktisk handler på det du lærer i empati-fasen. Men i de teamene jeg har jobbet med, har kombinasjonen av disse tre gitt noe ingen av dem klarer alene, et felles utgangspunkt som folk faktisk forstår.
Forskning fra SINTEF bekrefter dette. Dingsøyr og Moe har gjennom flere forskningsprosjekter, blant annet Agile 2.0-prosjektet, vist at koordinering og kunnskapsdeling på tvers av team er de største utfordringene i store digitaliseringsprosjekter, og at løsningen ikke er mer kontroll, men bedre felles forståelse.
Så, hvor starter du?
Du trenger ikke å lære deg tre rammeverk før du begynner. Start med ett, eller enda bedre, start med ingen av dem og gjør dette i stedet:
Samle teamet ditt i et rom. Bruk en time på å kartlegge hva som faktisk skjer i domenet deres. Still spørsmål, «hva kaller vi de viktigste tingene vi jobber med, og hva betyr de for meg? Er det det samme som det betyr for deg?». Dette trenger ikke å ta en hel dag. Ofte holder det med et par timer for å avdekke hvor dere snakker forbi hverandre.
Poenget er ikke å bli DDD-ekspert eller sertifisert Design Thinking-fasilitator. Poenget er å skape et godt grunnlag fra start, med et felles språk som gjør at folk faktisk forstår hverandre. Resten av verktøykassen kan du plukke opp etterhvert, når du ser hvor skoen trykker.
Slutt å ansette deg ut av problemet
Neste gang noen sier «vi trenger mer fart og flyt», stopp opp og still det ubehagelige spørsmålet, «snakker vi egentlig samme språk?». Hvis svaret er nei eller, «det tror jeg», så er det der du starter. Ikke med flere folk.
Lær DDD for strategisk domeneforståelse. Bruk Design Thinking for empati og iterasjon, og implementer TLT for å skape balansen mellom retning og frihet.
Fart kommer ikke av å trå hardere på gasspedalen. Fart kommer av at alle vet hvor veien går.