Oppsummering av Team Topologies

En bok om hvordan teamdynamikk og -strukturer kan bidra til oppnå best mulig flyt og verdiskapning. Skrevet av Matthew Skelton og Manuel Pais.

Team Topologies: Organizing business and technology teams for fast flow. Besøk teamtoplogies.com for kjøp og tilleggsmateriell.

Team Topologies handler om måter å organisere team på, og hvordan de bør kommunisere og interagere med hverandre, for å oppnå best mulig flyt og verdiskapning. Boken går hånd i hånd med Accelerate, og bygger videre på flere av funnene der.

TL;DR: Til tross for at man i moderne programvareutvikling ønsker å drive med innovasjon og samtidig optimalisere for fart, stabilitet og kvalitet, er det fortsatt mange som organiserer folk og team på måter som heller bidrar til det motsatte. For å realisere det fulle potensialet i smidig og DevOps trenger man hensiktsmessig organisering og myndiggjøring av stabile, løst koblede og kompetente team, som kommuniserer og samarbeider med hverandre på effektive måter.

Organisasjonsstruktur og flyt

Tradisjonelle organisasjonskart viser organisasjonens formelle struktur og rapporteringslinjer oppover og nedover i hierarkiet. Et problem med slike kart, i kontekst av moderne programvareutvikling, er at de ikke viser organisasjonens faktiske kommunikasjonslinjer og hvem som egentlig avhenger av hvem for å få jobben gjort.

Mennesker og team følger ikke nødvendigvis beslutnings- og rapporteringslinjene, men kommuniserer og interagerer på kryss og tvers i søken av å løse problemer. Organisasjonskartet er med andre ord ute av synk med virkeligheten, og dermed et lite egnet utgangspunkt for å dele opp og kontrollere arbeid. Man bør derfor danne seg et mer realistisk bilde av hvordan arbeid faktisk blir gjort og heller omfavne det.

Organisasjonen må snu seg rundt og optimalisere for flyt av endringer fremfor å holde fast ved overleveringer mellom funksjonelle siloer og andre flaskehalser som bremser farten. Med funksjonelle siloer menes for eksempel spesialiserte team for kvalitetskontroll, database eller sikkerhet. Organisasjoner bestående av slike siloer lykkes oftes ikke med å skape systemer rigget for ende til ende-flyt. Det vil si at det tar lenger tid enn nødvendig fra et behov dukker opp til det er løst i produksjon. Dermed bremses verdiskapningen.

I praksis betyr alt dette at man må investere i myndiggjorte, tverrfaglige, stabile og kompetente team som kan jobbe og samhandle mest mulig effektivt. Det danner et solid grunnlag for den smidigheten og tilpasningsdyktigheten som er nødvendig for å overleve i dagens knallharde konkurranse.

Ta høyde for Conways lov

Hvis gjeldende organisasjonsmodell ikke matcher ønsket systemarkitektur, må en av delene endres. Organisasjonsdesign vil alltid gjenspeiles i systemets arkitektur. Dette skyldes fenomenet beskrevet som Conway’s lov:

“Organizations which design systems . . . are constrained to produce designs which are copies of the communication structures of these organizations.”

Det betyr at en spesifisert programvarearkitektur ikke kan implementeres treffsikkert av en tilfeldig organisert samling av team. For å unngå et utilsiktet design, må man derfor ta grep om organiseringen og sørge for at den passer bedre med den ønskede arkitekturen. En slik manøver kalles for en inverse Conway maneuver. Andre effekter, av en mer hensiktsmessig organisering, er at hastighet og tid brukt på å gjenopprette fra feil også blir positivt påvirket.

Team først-tankegang

Ved å myndiggjøre team og tilrettelegge for god flyt, skapes tettere bånd mellom teammedlemmene. Teamet opptrer mer som en sammensveiset enhet og presterer langt bedre enn en samling av individer som jobber med hver sine ting. Å jobbe som individualister med moderne programvareutvikling er ikke bærekraftig.

Boken definerer team som en stabil gruppe mennesker, på fem til ni personer, som jobber som en enhet mot et felles mål. Et team må anses som organisasjonens minste og viktigste leveranseenhet, og organisasjonen bør aldri tildele oppgaver til enkeltpersoner — alltid til team (som selv finner ut av hvem som gjør hva).

For at et team skal yte best mulig er det viktig at teammedlemmene har høy grad av tillit til hverandre. Om teamstørrelsen overskrider ni personer, vil dynamikken endres og tilliten svekkes såpass at det går ut over fart, kvalitet og innovasjon. Det skyldes at det finnes en øvre grense for hvor mange vi klarer å ha et nært og tett forhold til (Dunbars tall). Teamet bør dessuten ha et mangfold av mennesker med ulik kompetanse og bakgrunn, slik at flere muligheter undersøkes og mer kreative løsninger skapes. Det gjør også at det tas færre antagelser.

Et team bør være stabilt over tid og kun endres ved behov. Det tar tid å bygge opp nødvendig tillit og å bli effektiv. Derfor er det ødeleggende for organisasjonen om man plukker teamet fra hverandre når det først har begynt å prestere bra. I tillegg er det viktig å forstå at tilføring av nye medlemmer i et eksisterende team ikke umiddelbart fører til økt kapasitet, men snarere det motsatte (som stadfestet av Brooks lov, i boken The Mythical Man-month). Det tar tid å få nye medlemmer ordentlig i gang, og kommunikasjonsstrukturen i teamet blir mer kompleks.

Videre er det viktig med avgrensede ansvarsområder blant team, og at et team har eierskap til programvaren det jobber med. Aller best blir det om teamet i tillegg er autonomt nok til å planlegge eget arbeid og ta egne avgjørelser. For øvrig bør ingen team ha lov til å jobbe med den samme delen av systemet som andre. Det resulterer i at ingen tar ordentlig eierskap til det, eller ansvar for rotet det medfører.

Kognitiv overbelastning er en flaskehals

Kognitiv kapasitet bør være førende for hvor stort eller variert ansvarsområde et team kan ha. Det finnes tre former for kognitiv last:

1. Intern / iboende last (intrinsic load) gjelder for eksempel vanskelighetsgraden av et programmeringsspråk, eller kodebasens stadig økende omfang og kompleksitet (å unnlate å ta hånd om teknisk gjeld har også en prislapp). Iboende kognitiv last kan minimeres gjennom ulike kompetansehevingsaktiviteter, teknologivalg, parprogrammering, avgrensing av ansvarsområde med mer. Flere forskjellige ansvarsområder kan for øvrig gjøre at teamet dras i flere retninger og at prioritering i tillegg blir vanskelig.
2. Overflødig last (extraneous load) er noe som typisk er unødvendig å ha i arbeidsminnet og som bør automatiseres vekk. Det kan være kunnskap om hvordan en tjeneste konfigureres, hvordan infrastruktur provisjoneres eller lignende. For å minimere overflødig last kan man dokumentere API-er, gi innsyn i produktkø og hva det til enhver tid jobbes med, eller gjøre andre tiltak som reduserer behovet for kommunikasjon med andre.
3. Relevant last (germane load) er hva vi bør bruke det meste av den kognitive kapasiteten vår på. Det kan for eksempel dreie seg om å forstå et forretningsområde, hvordan ulike tjenester bør kommunisere med hverandre, eller annen verdiskapende tenkning.

Om man lesser på med ansvar uten å ta høyde for kognitiv kapasitet, svekkes både teamets motivasjon og evne til å jobbe effektivt. Mestringsfølelsen går ned, man opplever redusert grad av autonomi og finner mindre mening med det man gjør. Teamet slutter å opptre som en samlet enhet og går i stedet over til å være en løst koblet samling av individer som jobber med hver sine ting.

Når ansvarsområdet øker i størrelse eller kompleksitet, samtidig som kognitiv last allerede er på maks, må man gjøre grep for å få ned iboende og overflødig last.

Tilpassede ansvarsområder

Kognitiv last er vanskelig å måle. Det beste er ofte å spørre teamet om hva de føler. Mener de selv at de er kapable til å jobbe effektivt med arbeidet de er satt til å gjøre? Eller strever de med for høy kompleksitet?

Om et domene eller ansvarsområde er for stort og komplekst for et team, bør det splittes i flere biter og tilordnes flere separate team. Det er langt bedre å dele opp, avgrense og fordele ansvarsområder enn å la flere team ha et felles ansvar for en samlet, større ting.

Hvis et team har ansvar for to forskjellige kompliserte domener, er det ofte best å splitte teamet i to. Det blir da to separate, litt mindre team med ansvar for hvert sitt domene. Det fører til mindre behov for koordinering og kommunikasjon, og lavere kognitiv belastning (da ingen trenger å kunne begge domener i detalj).

Det er bedre å designe programvaren til å passe med teamets kognitive kapasitet, enn å henge seg for mye opp i hvorvidt monolitt eller mikrotjenester er riktig vei å gå. Da tar man utgangspunkt i mennesker fremfor teknologi, og da oppnår man best prestasjon. En slik tilnærming gjør at man gjerne favoriserer en en bestemt form for arkitektur; nemlig små, løst koblede tjenester som kan endres uavhengig av hverandre.

Teamtopologier

Det er viktig å ta bevisste valg rundt oppretting og utforming av team, hvordan de plasseres i organisasjonsstrukturen, samt hvilke ansvarsområder de skal ha. Slike gjennomtenkte team og teamstrukturer, med tydelige og avgrensede ansvarsområder, er hva boken kaller teamtopologier. En organisasjon bør velge topologi basert på hva man tror gir mest verdi i sin kontekst og situasjon.

Anti patterns

Ad hoc oppretting av team og hyppig utskiftning av teammedlemmer er to anti patterns, som bør unngås. Med ad hoc menes det at man tenker kortsiktig og handler reaksjonært, ved å opprette eller reorganisere team basert på umiddelbare behov. Det kan lede til funksjonelle siloer og flere overleveringer, som forsinker prosessen og som er det motsatte av hva man ønsker. Kanskje en hendelse i produksjon gjør at man oppretter et eget DBA-team, eller at for mange bugs gjør at man oppretter et eget QA-team?

Det er viktig å reflektere over valgene man tar. Hvordan vil oppretting eller endring av et team vil påvirke andre? Får det noe å si for arbeidsflyt og hastighet, eller arkitektur?

Mange organisasjoner gjør programvareutvikling som en enveisprosess med overleveringer fra spesifikasjon til design, fra design til kode, fra kode til testing, fra test til release og fra release til produksjon — uten direkte feedback, til teamene som bygger programvaren, om hvordan den faktisk kjører og presterer der. En slik prosess, hvor ulike siloer eier de forskjellige aktivitetene, er avleggs og ikke kompatibel med moderne programvare- og produktutvikling. Man bør ikke bygge team rundt bestemte aktiviteter eller fagkunnskap.

En bedre tilnærming

Teamene bør i all hovedsak bygges rundt forretningsområder, og ha all nødvendig kompetanse til å håndtere alle aktiviteter gjennom hele verdistrømmen selv. Det er tverrfaglighet, autonomi og færrest mulig avhengigheter til andre som gjelder. Feedback fra produksjon gjør at man i tillegg kan “føle” hvordan systemet fungerer, og at man dermed kan oppdage svakheter tidlig og fikse de kjapt.

Et typisk produktteam vil ofte ha en del avhengigheter til tjenester og infrastruktur som leveres av andre team. Da er det viktig at teamet er selvbetjent, slik at arbeid ikke blokkeres. Det man forsøker å unngå er harde avhengigheter, hvor arbeid stopper opp i påvente av at noen utenfor teamet skal gjøre sin del av jobben. Teamene trenger derfor et støtteapparat rundt de, som tilrettelegger for at de kan være selvgående.

Grunnleggende topologier

Boken definerer fire grunnleggende teamtyper:

• Stream-aligned team
• Enabling team
• Complicated-subsystem team
• Platform team

Å begrense seg til bare fire varianter bidrar til å redusere uklarheter rundt roller i organisasjonen, noe som er en nøkkelfaktor i moderne organisasjonsdesign.

Stream-aligned team

Et stream-aligned team jobber med hele verdistrømmen for et bestemt forretningsområde. Det betyr at teamet håndterer flyten av alle endringer forbundet med hele eller deler av et produkt, en tjeneste, brukerreise eller lignende. Verdistrøm-team, er kanskje en OK oversettelse. Dette er den primære teamtypen. Alle andre varianter eksisterer for å understøtte slike verdistrøm-innrettede team.

Å jobbe med hele verdistrømmen, fra idé eller krav til produksjon, impliserer at teamet er tverrfaglig og autonomt. Relevante kapabiliteter, representert i teamet, kan være (men er ikke begrenset til):

• Sikkerhet
• Forretning og markedsføring
• Design / UX og arkitektur
• Utvikling og koding
• Infrastruktur og drifting
• Produktledelse og -eierskap
• Måling og monitorering
• Testing og QA

Det betyr ikke at teamet må være stort, med minst en person per fagområde, men at at det kan bestå av noen få spesialister og flere generalister. Om teamet kun består av spesialister, som ikke bidrar utenfor sitt felt, får vi flere flaskehalser. (I dag snakker vi ofte om T-form på kompetanseprofiler, hvor den horisontale linjen representerer bredde og den vertikale representerer dybde. Selv om man har spisskompetanse på noe, kan man fortsatt bidra på, eller kunne akkurat nok om, noe annet).

I boken poengteres det at bruken av uttrykket stream-aligned team, i stedet for feature- eller produktteam, er bevisst og med vilje. Det fremhever viktigheten av flyt på organisasjonsnivå; strømmen av endringer skal flyte uhindret

Egenskaper ved slike team er blant annet:

• Jevn flyt av endringer.
• Eksperimentering, læring og forbedring.
• Minimalt med (helst ingen) overleveringer.
• Jobber aktivt med teknisk gjeld.
• Føler stor grad av autonomi, mestring og mening — som gir motivasjon og engasjement.

Enabling team

Et enabling team består typisk av spesialister innen et gitt teknologi- eller produktområde, hvis oppdrag er å hjelpe et eller flere verdistrøm-team med å skaffe seg ny og nødvendig kunnskap. Det kan hjelpe slike team å oppnå større grad av autonomi, og at de dermed kan jobbe mer effektivt. Det overordnede målet, for et enabling team, er at organisasjonen skal kunne levere fungerende programvare på en raskere, tryggere og mer bærekraftig måte.

Et enabling team kan for eksempel være spesialisert innen kontinuerlig leveranse og automatisering. Slike team hjelper til over en begrenset periode, og jobber for å spre kunnskap og å gjøre seg selv overflødige. Et enabling team kan ellers bli en flaskehals som flere til slutt avhenger av. Å lene seg på dedikerte spesialister er en langt mer effektiv måte å få inn ny kunnskap på, enn om de som jobber med en verdistrøm må investere tid og krefter i å komme fram til noe tilsvarende selv (som ville gått på bekostning av flyt).

Faggrupper, eller communities of practice (CoP), kan ha omtrent samme funksjon som et enabling team, men sistnevnte har det som fulltidsjobb. Fagrupper, bestående av medlemmer fra forskjellige team, møtes og bidrar typisk mer sporadisk og går ofte bredere ut for å spre kunnskap.

Complicated subsystem-team

Et complicated subsystem-team har ansvaret for å bygge og vedlikeholde en del av systemet som er så komplisert at det krever spesialistkompetanse for å forstå det. Målet for slike team er å redusere den kognitive lasten for et eller flere verdistrøm-team, som inkorporerer den kompliserte delen i sitt system. Det kan for eksempel dreie seg om en videokodek eller en motor for ansiktsgjenkjenning. Det ville vært langt mindre effektivt om et verdistrøm-team skulle ha håndtert dette selv.

Plattform-team

Et plattform-team leverer interne tjenester og annet som verdistrøm-teamene avhenger av. Med plattform menes et fundament bestående av API-er for selvbetjening, verktøy, tjenester, kunnskap og support — pakket inn som et internt produkt. Målet er, som for de øvrige støtte-teamene, å redusere kognitiv last for verdistrøm-teamene, slik at best mulig flyt opprettholdes. Det fordrer naturligvis god devEx (developer experience), som i at API-er og tjenester er av høy kvalitet, at de er stabile og enkle å bruke, og at de er formålstjenlige.

I tilfeller hvor plattformen stort sett består av tredjeparts tjenester, API-er og lignende, kan det fortsatt gi mening med et eget plattform-team. Det har stor verdi om noen har oversikt og tar grep når noe er utdatert og ikke lenger vedlikeholdes eller supporteres, når noe bør oppgraderes, eller når noe helt nytt bør trekkes inn.

Man bør alltid sikte mot en thinnest viable platform (TVP). Altså at man ikke lager plattformen mer kompleks enn den trenger å være, men akkurat avansert nok til at den bidrar til å akselerere flyten for teamene som bygger på den. En plattform bør være helhetlig og konsistent, samt ta høyde for organisasjonens behov og teknologiutviklingen for øvrig.

Konvertering av eksisterende team

Mange organisasjoner vil ha mye å tjene på å identifisere hvilken av de fire grunnleggende topologiene som representerer den beste måten å jobbe på for hvert team, for så å konvertere de. Det gir klarhet rundt hvilken rolle teamene har og hva meningen med de er.

Boken kommer med flere tips og ideer til hvilken topologi som passer hvilket team, og hvordan de kan konverteres. Eksempelvis at et DBA-team kan slutte å jobbe på applikasjonsnivå, men heller gå over til å bli et enabling team som hjelper andre team i gang med å håndtere lagring selv.

Definere og begrense ansvarsområder

Fornuftig avgrensning av omfang og tydelige skillelinjer mellom hvert team sine ansvarsområder er helt nødvendig for at teamene skal kunne ta eierskap og jobbe effektivt. Det gjøres gjennom å innrette systemet og trekke opp grenser basert på hvert team sine kapabiliteter.

Fra forskningen publisert i Accelerate, vet vi at en arkitektur med mange tette koblinger vil ha negativ innvirkning på teamets kapasitet. Avgrensning og API-er foreslås som veien å gå for å dele opp store domener i mindre, løst koblede enheter. For å gjøre dette på en hensiktsmessig og god måte må teamene også være løst koblet (ref Conways lov). Det er viktig å bruke team som innfallsvinkel — ellers risikerer man å splitte monolitten på feil steder. Det kan resultere i en såkalt distribuert monolitt, som betyr begrenset autonomi, da nesten hver eneste endring krever oppdateringer i flere separate tjenester.

Spalting av monolitter

I boken snakkes det om fracture planes som indikasjon på hvor man kan splitte en monolitt. Begrepet kommer fra steinindustrien, hvor steinens spalteflater (fracture planes), eller svake soner, sier noe om hvordan den kan dele seg (kløyves) med jevne, glatte flater. Når man skal splitte en monolitt i flere biter, bør man se etter naturlige spalteflater.

De kan for eksempel være basert på:

• Forretningsdomener
  Et større domene kan ofte splittes flere mindre underdomener. En streamingtjeneste for musikk er et godt eksempel. Den består typisk av spilleliste, oppdagelse av ny musikk, selve avspillingen med mer.
• Regulering og regelverk
  De delene av et system som er omfattet av strenge regelverk kan med fordel skilles fra resten, slik at det ikke stilles like strenge krav til alle deler av systemet.
• Endringstakt
  Om forskjellige deler av monolitten beveger seg i ulik hastighet, danner også det en naturlig spalteflate. En monolitt beveger seg bare så hurtig som den tregeste delen, og det er uheldig å la det være førende for hvor ofte man kan deploye eller release.
• Krav til ytelse
  Om en del av systemet har mer påtrykk og trafikk enn alt annet, kan den med fordel skilles ut til noe som kan skaleres helt uavhengig av resten.

Andre eksempler på spalteflater er lokasjon (hvor team og teammedlemmer befinner seg), risiko, teknologi og personas.

For å finne spalteflater kan man, som team, spørre seg; Kunne vi ha tilbudt eller konsumert denne spesifikke delen som en tjeneste (as a service)? Hvis ja, så er det en god kandidat for å skilles ut og tildeles et annet team.

Metoder for samarbeid på tvers av team

Teamtopologi er noe som bør endres evolusjonært og i takt med organisasjonens stadig endrede behov. Det bør ikke være statisk. For at organisasjonen skal være tilpasningsdyktig, må man vite noe om hvordan teamene best kan samhandle om felles mål. Boken definerer tre interaksjons- og samarbeidsmetoder:

• Samarbeid
  Tett samarbeid mellom to team over en definert, begrenset periode egner seg for eksempel når man trenger hurtig utforsking av ny teknologi og teknikker, eller i tidlig-fase utvikling og innovasjon. Det gir mest verdi når teamene har ulik kompetanse (for eksempel verdistrøm- og plattform-team), og kan mobilisere sin felles kunnskap for å løse problemer. Teamene må ha et delt ansvar for overordnet utfall om samarbeidet skal fungere. Ulemper er at tett samarbeid fører til økt kognitiv last og uklare grenser mellom ansvarsområder.
• X-as-a-service
  Et team kan konsumere en tjeneste eller benytte et API levert av et annet team. Ansvarsområdene er tydelig avgrenset mellom teamene, og liten eller ingen grad av kommunikasjon er nødvendig.
• Fasilitering
  Denne samarbeidsformen egner seg når et eller flere team trenger hjelp, i form av fasilitering eller coaching, til å få ny kunnskap om hvordan løse et gitt problem. Fasilitering er mye brukt av enabling team. Målet er at teamet som mottar hjelp skal bli selvgående så fort som mulig.

Å ha tydelig avgrensede ansvarsområder og klare føringer for hvordan team kan og bør samhandle fører til bedre rolleklarhet, bedre effektivitet og flyt, samt mindre frustrasjon og irritasjon. Interaksjonsmetoder utenom de tre ovennevnte bør anses som sløsing av tid. Det vitner om dårlig definerte ansvarsområder og at meningen med et eller flere team ikke blir forstått.

Interaksjonsmetodene mellom team må forventes og endres jevnlig, avhengig av hva man ønsker å oppnå. Det kan for eksempel hende at to team går fra et innledningsvis tett samarbeid til mer sporadisk samarbeid, før de til slutt går over til x-as-a-service. At teamene bytter på disse to interaksjonsmetodene, når det gir mening, kan hjelpe organisasjonen å oppnå ordentlig smidighet.

Noen ganger må man sørge for at teamene sitter fysisk samlet for å oppnå ønsket grad av samarbeid. I andre tilfeller må man flytte teamene lenger fra hverandre for å stimulere til X-as-a-service og bruk av API-er.

Tegn på at team eller ansvarsområder bør endres

Det kan være utfordrende for en organisasjon å være selvbevisst nok til å oppdage når et team eller ansvarsområde bør endres. Det finnes en del utløsende faktorer og symptomer man kan se etter.

Systemet har blitt for stort for et team

• Andre team blir sittende å vente (lenge) på at endringer blir gjennomført.
• Endringer på bestemte deler av systemet tildeles rutinemessig til de samme menneskene, selv om de er opptatt eller ikke er til stede.
• Teammedlemmer klager på manglende dokumentasjon.

Å basere tildeling av oppgaver på hvem vet hva fremfor hva er viktigst nå, skaper flaskehalser og fører til at flyt og motivasjon påvirkes negativt.

Leveransetakten har blitt tregere

• Metrikker for gjennomstrømning av oppgaver (throughput) og ledetid vitner om en nedadgående trend.
• Teammedlemmer føler at det tar lenger tid gjennomføre endringer enn før.
• Work in progress (antall samtidige oppgaver) øker, og flere oppgaver blokkeres i påvente av at noen utenfor teamet må gjøre sin del av jobben.

En årsak til tregere leveransetakt kan være innskrenket autonomi på grunn av innføring av funksjonelle siloer som teamet nå avhenger av. En annen årsak kan være at teamet har opparbeidet seg for mye teknisk gjeld og at kodebasen har blitt så kompleks at selv små endringer forårsaker regresjonstesting. En treg leveransetakt kan i tillegg skyldes manglende telemetri og overvåking, og at sporing og feilsøking er vanskelig.

Sansende organisasjoner

Team Topologies slår fast at organisasjoner kan bli smidigere og mer leveransedyktige ved å ha gjennomtenkte, stabile og myndiggjorte team som tar eierskap for hver sine deler av et system og som samhandler med hverandre på bestemte måter. Ved å følge rådene i boken kan organisasjoner også blir mer sansende, som i at teamene i større grad fanger opp signaler fra både inn- og utsiden. Hvilke signaler et team fanger opp avhenger blant annet av hva teamet gjør og hvor kundenært det er, men det kan uansett fange opp verdifulle signaler og informasjon som både teamet og organisasjonen da kan respondere hurtig på. Sense and respond, som det heter. Det handler om selvbevissthet og å forstå omverdenen, og å tilpasse seg deretter.

Teamtopologi er ikke nok

Å legge ned mye arbeid i å finne ut hvordan team bør organiseres og samhandle med hverandre når aldri sitt fulle potensial om man ikke samtidig har god ledelse, en god og positiv kultur og moderne tekniske metoder og praksiser. For eksempel blir kontinuerlig leveranse løftet frem som viktig. For en dypere forsåelse for disse tingene, vil jeg sterkt anbefale boken Accelerate: The Science of Lean Software and DevOps. Jeg har skrevet en oppsummering av Accelerate også.

Team Topologies er fullspekket av innsikt og gode råd for hvordan man kan levere mer effektiv og bærekraftig, samt flere case-studier. Alt presenteres på en oversiktlig og veldig ryddig måte. Med andre ord; sterkt anbefalt lesning!

Bokens nettside teamtopologies.com inneholder massevis av ressurser og tilleggsmateriell.

Oppdatering, mai 2022: Se også oppsummeringen av oppfølgeren Remote Team Interactions Workbook.