Den første av mange? Oppsummering av Capras Team Topologies-konferanse

Tidligere i september samlet Capra over 80 ulike selskap på Rebel i Oslo for verdens aller første Team Topologies-konferanse. Her følger en oppsumering.

Team Topologies, boken som ble sluppet i 2019, presenterer en måte å drive moderne softwareutvikling på. Boken har fokus på hvordan optimalisere organisasjoner for flyt gjennom tverrfaglige team, og er skrevet av Manuel Pais og Matthew Skelton. I løpet av dagen hørte vi fra nevnte Pais, i tillegg til representanter fra noen av Norges største selskaper. Konferansen rundet av med en paneldebatt med tema “Er Team Topologies egentlig for alle? Erfaringer og utfordringer”. Denne bloggartikkelen har som hensikt å oppsummere de viktigste læringspunktene.

Dersom du er interessert i å motta informasjon om slike arrangementer i fremtiden kan du melde deg på vårt nyhetsbrev her (merk at vi maks sender ut nyhetsbrev 4 ganger i året):

From Roles in a Hierarchy to Team Topology

Therese Engen, Organisasjonsutvikler i Capra.

Capra er et konsulentselskap basert i Oslo som fokuserer på å levere verdi til kunder gjennom nymotens teknologi og innovative løsninger. Vi er veldig opptatte av å rigge vårt eget selskap for fart og flyt, ettersom vi tror dette fører til bedre løsninger for våre kunder og en større følelse av eierskap for våre ansatte. I 2019 startet vi nettopp en slik reorganisering. Dersom du ønsker å lese mer om vår reise fra en ledergruppe til autonome team, ta en titt på følgende bloggartikkel: Slik reorganiserer vi Capra.

Capra tjente penger, kundene våre var happy og folkene våre var happy - så hvorfor initierte vi denne endringen? Ledergruppen følte at farten sank. Mange utfordringer ble løst utenfor ledergruppen, og de fikk dessuten mange spørsmål fra kolleger som man like gjerne kunne, og burde, løst selv. Med autonomi, samkjøring og flat struktur i bakhodet oppdaget ledergruppen Team Topologies - en bok som ga dem vokabularet til å starte reisen.

Det første teamet, Team Nyorg, fokuserte i starten på å lage et starter-kit for nye team. Dette for å hjelpe dem med å finne sitt formål, sette gode mål, lage en teamkontrakt og veilede teamet gjennom Tuckman’s stages of group development. Inspirert av boken The Five Dysfunctions of a Team, fasiliterte de også retrospektiver for teamene for å påse at teamene ikke mistet fokus. Therese tror at vi kunne ha unngått noen av utfordringene vi møtte, dersom man i starten hadde fokusert mer på tillit, konflikthåndtering, forpliktelse til resultater, ansvar og resultater.

Så, hva har vi fått til? Vi ser en klar tendens til at flere tar ansvar og føler et større eierskap til oppgaver. I tillegg har vi merket at endringsfarten har økt på grunn av at beslutninger tas nærmere de som er påvirket av dem. Ønsker å lese mer om hva vi har lært etter to år med Team Topologies? Ta en titt på følgende bloggartikkler:

To år senere: Dette har vi lært siden vi anvendte Team Topologies

Team og troll – erfaringer fra en helt vanlig geit

Remote-first Team Interactions with Team Topologies

Manuel Pais, forfatter av Team Topologies og selvstendig konsulent.

Remote arbeid handler ikke bare om digitale verktøy. For å lykkes er det helt nødvendig å innføre noen grunnregler, fokusere på psykologisk trygghet samt lage noen praksiser for å la teamene samhandle på en enkel måte.

I en remote først-kontekst er det essensielt å forstå hvem som jobber med hva. Roadmaps som kun er synlig gjennom faste statusmøter er ikke nok - man bør ha som mål å gjøre dette lett tilgjengelig gjennom Team API. Team API er en artefakt som eies av hvert team, og inneholder roadmap med prioriteringer, kommunikasjonspreferanser, arbeidspraksis og -prinsipper og mer.

Når arbeidet er synlig, kan man begynne å identifisere, klassifisere og spore avhengigheter til andre team. Eliminer de blokkerende avhengighetene, reduser de langsomme avhengighetene og behold de sunne avhengighetene.

Videre snakket Manuel om hvordan virkningen av tillitsgrenser (eng: trust boundaries) er enda mer tilstede i en remote først-kontekst. Kanalnavn i chatteverktøy som ikke er intuitive og andre eksempler på dårlig design i digitale løsninger, øker teamenes kognitive last (eng: cognitive load). En quick win kan dermed være å innføre en enkel navnekonvensjon.

Ikke forvent billigere samhandling fordi det meste er nettbasert i dag. Å kommunisere på nett har også en kostnad - og denne kostnaden er spesielt høy når det er vanskelig å finne ut hvor og hvordan man skal kommunisere. Vi kan, og bør ikke, forvente å kontinuerlig snakke med alle andre (personer eller team). Prioriter formålsdreven interaksjon fremfor prosessdreven interaksjon.

Etter eventet la Manuel til følgende:

I was honoured that Capra organised an event with Team Topologies as the topic, highlighting the importance of strategizing for fast flow in today’s competitive landscape. People were engaged and shared their real world stories, how the adoption of ideas from Team Topologies helped address their organisation’s challenges but also raised new challenges. In fact, org transformations are journeys that we should only embark on with specific objectives in mind, and the understanding that we will have to adapt continuously if we want to get through the inevitable storms and unexpected events. Events like this help us learn and see what might be ahead in our own journey.

DNB: Teams & Topologies

Thomas Kjelsrud, Agile Coach i DNB.

DNB er Norges største finanskonsern. For noen år siden var prosjekter den primære måten å få ting gjort på. De ansatte var gjerne spredt rundt på flere samtidige prosjekter, hvor de også måtte føre timer for å holde øye med kost. IT-arkitekturen i DNB består av alt fra hyllevare, legacysystemer, egenutviklede systemer og mer, og spenner derfor et bredt spekter av teknologier. I 2020 laget DNB en IT-driftsmodell hvor de introduserte tech families. Dette er stabile, tverrfaglige grupper av team som er autonome og krever mindre administrasjon enn tidligere.

Driftsmodellen tar for seg to forskjellige typer tech families; Application Services Families (for eksempel kjernesystemer, brukersupport etc.) og Common Services Families (for eksempel Cloud, CI/CD, sikkerhet etc.). Common Services Families tilbyr felles praksis, plattformer og tjenester som gjør det mulig for Application Services Families å ta fullt ansvar over hele livssyklusen. Etter introduksjonen av IT-driftsmodellen, har man sett en flatere organisasjon med mindre nødvendig administrasjon.

Interaksjonsmetodene mellom team (som presentert i Team Topologies-boken) har vært utfordrende i DNB, ettersom mange team i stor grad er avhengige av tett samarbeid. Dette kan dermed bli krevende over tid, spesielt når det er mange involverte parter. Dette er noe DNB ønsker å fokusere på å forenkle fremover.

How can Team Topologies be applied in the data, analytics & machine learning domain?

Christian Moe, SVP Data & Analytics i Gjensidige.

Gjensidige er et av Nordens største forsikringsselskap. Data og dataanalyse er kritisk for kundereisen til forsikringsproduktene ettersom dette brukes i prissetting, vurdering av forsikringssvindel, predikering av fremtidige forsikringskrav og mye mer. Med mer enn 2000 prodsatte modeller, er Gjensidige avhengig av de rundt 25 tverrfaglige ML subsystem-teamene. Disse teamene finnes i mange former, men består typisk av én domeneekspert, data scientists, data engineers og softwareutviklere. I det siste har det vært mye fokus i organisasjonen på å legge et godt grunnlag for at teamene kan jobbe smidig og autonomt.

For å lykkes tror Christian det er viktig med støtte fra ledelsen, en fleksibel organisasjonsstruktur, fokus på å bygge et fellesskap for å dele suksesser og fails samt å ha en langtidsperspektiv.

Paneldebatt: Er Team Topologies egentlig for alle? Erfaringer og utfordringer

Stein-Otto Svorstøl (Capra), Torill Iversen (Avdelingsdirektør i NAV IT), Therese Engen (Capra), Thomas Kjelsrud (DNB), Christian Moe (Gjensidige) og Manuel Pais (Team Topologies)

NAV består av rundt 150 team innenfor teknologi. Torill mener at en viktig verdi Team Topologies tilfører, er et felles språk på tvers av organisasjonen. For Nav sin del har dette kommet særlig til syne i deres tjenesteplattform-team. Teamene reduserer den kognitive lasten til utviklerne og tilbyr tjenester til produktutviklingsteam gjennom blant annet X-as-a-service. Team Topologies kan virke enkelt, men selv det å klassifisere teamene innenfor de fire typene team kan være utfordrende i komplekse organisasjoner. Thomas la til kommunikasjonsmønstrene som en utfordring – hvordan få teamene til å bruke og oppdatere disse (team APIene), samt bli enige om hvilken interaksjonsmodus som skal brukes i ulike sammenhenger. Ofte har man et scenario der et team ønsker å tilby en tjeneste, men teamet som konsumerer tjenesten heller ønsker samarbeid. Videre mener han at det å identifisere team (eller områder) som gjør mer enn det som er naturlig, kan være vanskelig. Panelet var enige om at det er viktig å hente inspirasjon fra flere bøker og modeller, og tilpasse disse til organisasjonens kultur og kontekst.

Christian fulgte opp med å snakke om viktigheten av å alltid begynne med hvorfor. Få en tidlig suksesshistorie for å hjelpe interessenter og beslutningstakere å forstå hvorfor man gjør denne endringen. Manuel forklarte også hvordan det kan være lurt å ha noen (for eksempel en smidig coach) som kontinuerlig er observant på på potensielle problemer (Team APIer, interaksjonsmodeller osv.) hvis en organisasjon prøver å ta i bruk prinsipper fra Team Topologies.

Manuel avslørte at første utkastet av Team Topologies-boken faktisk hadde et kapittel om grensesnittet mellom Team Topologies og andre områder. Spesielt det å identifisere verdistrømmene dine (her kan domain-driven design være nyttig), lage en strategi (forstå landskapet, kundene og behovet det skal løse - her kan Wardley Mapping være nyttig) og dynamic reteaming (se boken av Heidi Helfand) tror han er viktig. “If your value streams would apply to almost every company, then probably you haven’t thought about them long enough”, la Manuel til senere. Han har stor tro på at det er mye verdi i å kombinere Team Topologies med andre modeller og litteratur. Basert på tilbakemeldinger fra sine lesere, mener han den største utfordringen er misoppfatningen at en endring av arbeidsmåte vil medføre høyere kostnader. Videre er en bekymring at teamene vil ha flere artefakter å vedlikeholde - noe som fører til en totalt sett høyere kognitiv belastning. Therese påpekte at det er avgjørende å forstå at team, akkurat som mennesker, kan være innadvendte, utadvendte og overbelastede.

Så - er Team Topologies for alle? Det korte svaret er; det kommer an på.