En teambaserad organisation är ett ekosystem av team. Dessa kort är tänkta att användas för att kartlägga nuläget för respektive team i organisationen och sätta mål för vilka typer av team man skulle vilja ha och därigenom identifiera vad som håller teamen tillbaka från att ta sig dit.
Den här modifierade versionen av team topologier bygger på det fantastiska arbetet från teamtopologies.com som är skapat utifrån ett DevOps-perspektiv. De tillägg och justeringar vi har gjort på ursprungsmodellen syftar till att möjliggöra en tydligare produkt-ledd organisation där agila ledningsteam utifrån Agile Management Areas är en viktig del och justering för kundcentrerade produktteam där ofta även marknad och tech möts i gemensamma team, i stället för enbart stream aligned vilket är mer vanligt på en IT / Infrastrukturavdelning.
Conway’s Law är ett begrepp som pekar på att system ofta speglar organisationen som bygger dem, dvs för att justera de teamen man i nuläget har som ofta är av typen komponent-team och röra sig mot ett ekosystem som bygger på produktteam behöver man göra en omvänd Conway’s Law design. Då utgår man från vilka förmågor man skulle vilja att organisationen, och teamen har, kanske vill man att teamen har förmåga att ansvara för en optimal upplevelse direkt till slutanvändare utan mellanhänder. Äger produktutvecklings-processen end-to-end. Tar ansvar för det de bygger över tid och ser till att det skapar verksamhets och affärsnytta på både kort- och lång sikt – det vill säga vara ett Produktteam. Viktigt är att betona att man alltid behöver en mix av team i alla organisationer, enbart produkt-team är inte eftersträvansvärt, utan vanligt är att man har plattformsteam samt även enabling team, vad man dock vill gå ifrån är komplicerat subsystem-team (komponentteam), samt ha team med både produkt, plattform och enabling uppdrag.
Utifrån det målet kan man sedan identifiera vilka typer av team man har i nuläget, samt vilka typer av team man behöver för att steg för steg förändra den tekniska arkitekturen och förmågan i organisationen för att möjliggöra mer autonoma produktteam på sikt.
Alla team behöver även få tydligt definierade mål som de kan arbeta mot. Dessa mål ser olika ut beroende på vilket typ av team de är, men målet brukar var att ha uppdrag för teamen som spänner över ca 6 – 12 månader som gör att de själva kan se om de bidrar med värde och stöttar dom i att göra löpande prioriteringar.
Samarbetsmönster nyckeln till en Agil organisation
I arbetet kring teamtopologier så finns det även olika samarbetsmönster. Dessa mönster är nyckeln till hur samarbete bör ske mellan olika typer av team. Många missuppfattar begreppet ”autonoma team” och tror att målet är att man inte ska samarbeta mellan teamen. Inget kan vara mer fel, gott samarbete mellan team är grunden till en dynamisk organisation som ständigt kan förbättra sig och ta ansvar för den övergripande användar-och kundupplevelsen. Däremot så är målet att man inte ska vara beroende av att andra team i sin leverans vilket gör att man fokuserar på att bygga bort beroenden så snart de uppstår. Dessa samarbetsmönster syftar till att bygga bort beroende och bygga förmåga i teamen att kunna leverera så självständigt som möjligt.
Samarbete – arbeta tillsammans över en bestämd tid för att upptäcka nya saker tillsammans (APIer, arbetssätt, tekniker osv.)
X-as-a-service – ett team tillgängliggör och ett annat team konsumerar någonting ”som en tjänst”.
Facilitation – ett team hjälper och mentorerar ett annat team.
Ladda ner kanvasen med kort för team topologier i en produktorganisation
Förslag på workshop
Gå först igenom varför ni ska jobba med detta och lite om teorin bakom team topologier . Gruppera alla i organisationen (del av organisation / tåg) i blandade mindre grupper av 4-5 personer. Skriv ut lapparna med team topologier och lägg på varje bord.
Be grupperna att mappa alla team i organisationen och vilka typer av team respektive team passar in på. Diskussionen som sker i grupperna är jätteviktig så kom inte med pekpinnar om vad som är rätt eller fel i detta läge utan gå runt och lyssna.
Många av teamen är kanske komponent-team men jobbar samtidigt som ett enabling team och kanske som produktteam till viss del med ansvar för leverans till slutkund. Visualisera därefter alla gruppernas bild av respektive team och diskutera om de ser det på olika sätt och vad det betyder att ha det ansvar de har. Tex om teamen har många olika ansvar kan det upplevas som stressigt och ett team som kanske borde vara ett plattformsteam inte får jobba med eget arbete utan bara tvingas hjälpa andra.
Därefter kan ni kanske gemensamt skapa idéer för vilka era nästa justeringar skulle kunna vara genom att tex att nyttja de samarbetsmönster som finns. Ofta behövs tex arkitekturell- och annan förflyttning och skapande av nya typer av team för att möjliggöra nya typer av team, men insikten att samarbete är vägen framåt är ofta grundläggande. Vet ni inte vad som håller er tillbaka från att förflytta era team mot mer autonoma produktteam så kan ni göra ett test med ett team för att prova och se vilka hinder som uppstår. Se till att stötta så mycket som möjligt i samarbetet under tiden och röja så mycket hinder ni kan så lär ni er vad som krävs samt hittar vilka större förflyttningar som kommer att krävas tex tekniskt och kompetensmässigt.
Lycka till!
