Hvilke karakteristika og udfordringer har dit team?

All happy families are alike; each unhappy family is unhappy in its own way — Leo Tolstoy

Alle teams møder udfordringer, og ikke to teams er ens. Det er en universal sandhed, som de fleste køber ind på og et studie værd i sig selv. Når det er sagt, er der nogle særlige forudsætninger, der kan gøre, at nogle teams pr. definition er født anderledes end andre teams.

Det kan skyldes forskellige omstændigheder, og er ofte “by design” ovenfra. Min erfaring er dog, at mange organisationer og teams er uvidende om denne forskel, når agile rulles ud som “one size fits all”. Det bidrager med en masse udfordringer for teamet i forhold til deres egen identitet og selvforståelse.

Jeg får ofte team-relaterede spørgsmål, hvor min første tanke er: Hvilken type team taler vi om? Når det er afdækket, kan man ofte finde mange kilder til svar i den bevidstgørelse.

Min erfaring er, at der helt overordnet set findes en lille håndfuld team typer:

Disclaimer: Som alle andre modeller er nedenstående naturligvis blot en kraftig forenkling af virkeligheden. Så tag det for hvad det er — en forenkling af virkeligheden

Produktteam

Karakteristika: Er kendetegnet ved, at teamet har end-to-end ansvar for et eller flere produkter. Mantraet er “You Build It, You Own it”. Produkterne udvikles direkte til slutbrugeren, og teamet stiler mod at levere potentielt færdigt produkt efter hver iteration (og gerne oftere). Det er denne teamtype, som man forsøger at opnå i organisationer med det agile paradigmeskifte og den teamtype, som de fleste teams dermed forsøger at identificere sig med. Dette er “the holy grail”, når det fungerer.

Udfordringer: En typisk udfordring er, at teamet ikke har det mandat eller de kompetencer, der skal til for at være et produktteam, der kan varetage et end-to-end ansvar. Det kan resultere i indbyggede afhængigheder til andre teams. En anden typisk udfordring er, at de kan have ansvaret for mange produkter. Det resulterer i manglende fokus, meget vedligehold og “one-man-armies” indlejret i teamet, hvor hvert team member varetager hvert deres produkt, og at de derfor ikke fungerer som et rigtigt team.

Komponentteam

Karakteristika: Et komponentteam er et team, der leverer komponenter til andres teams (eks. produktteams). Det kan være i form af et API, et servicelag, en platform, infrastruktur etc. Kunden og stakeholders er dermed andre development teams og product owners i organisationen. Et komponentteam kan give mening, hvis flere teams har afhængigheder til samme komponent, og hvis denne komponent kræver en særlig sammensætning af kompetencer, eksempelvis dyb beregnings- og/eller domæneviden.

Udfordringer: Den største udfordring er, at et komponentteam pr. definition indeholder et element af vandfald, fordi det ikke leverer et produkt direkte til slutbrugeren. Med andre ord bliver feedbackloopet ikke lukket. En anden udfordring er, at der med et komponentteam indfører afhængigheder mellem teams. Komponentteams er derfor ikke den første løsning, I som organisation bør forfølge.

Kompetenceteam

Karakteristika: Et kompetenceteams produkt er en specifik kompetence. En kompetence som man ønsker at indføre som kapabilitet i en organisation. Kunden og stakeholders er dermed andre teams i organisationen. Komponent og kompetenceteams kan samlet betragtes som supporterende teams til produktteams. Et kompetenceteams vigtigste opgave er i virkeligheden at gøre sig selv overflødige. Med andre ord, at deres kompetence derved er blevet indlejret i produktteams. Et kompetenceteam er ikke at forveksle med et Community of Practice.

De mest almindelige former for kompetenceteams i dag er UX, agile og arkitektur teams. Ingen regler uden undtagelse: Kompetenceteams, der i større organisationer arbejder med jura og compliance, vil formentlig aldrig blive overflødige.

Udfordringer: Kompetenceteams giver som udgangspunkt mening, når organisationen vil indføre en ny kapabilitet. En udfording er dog, at mange kompetenceteams leverer deres kompetence som en ydelse og ikke som vidensoverdragelse og vidensopbygning. Lidt ligesom at tisse i bukserne… De gør sig dermed uundværlige i stedet for undværlige. En anden udfordring er naturligvis produktteams afhængighed til kompetenceteams, som nogle gange kan bidrage med gates og andre vandfaldslignende tendenser.

SWAT-team

Karakteristika: Et SWAT-team er et team, der bliver sammensat til lejligheden. Teamet opstår ofte, fordi der er et projekt eller en opgave, der skal løses hu-hej nu-og-her. Et SWAT-team kan også betegnes et projektteam. Man tager ofte eksisterende development team members fra andre teams og sammensætter dem midlertidigt i et SWAT-team. Når opgaven er løst, opløses teamet igen.

Udfordringer: Et SWAT-team skal være en undtagelse. Det er et anti-pattern. Et SWAT-team er typisk en forstyrrelse for de andre teams. Der er pludselig team members, der bliver flyttet rundt til noget, der er “vigtigere”. Et SWAT-team er det, man forsøger at undgå i bevægelsen fra projekt- til produkt-fokus. Et behov for SWAT-team er, ligesom med en “hero Developer” (/en selvbestaltet uundværlig brandslukker), ofte et udtryk for en dysfunktionel organisation. Med god organisering og planlægning bør behovet for SWAT-teams uddø.

Bevidstgørelse

Med bevidstheden om disse team typer in mente er det efter min erfaring langt lettere at italesætte udfordringer og anti-patterns i forbindelse med organisering, team identitet og teamets selvforståelse. Vi vil gerne undgå afhængigheder, men nogle gange er de blevet indført ubevidst inkompetent og andre gange kan vi desværre ikke undgå dem.

Arbejder du på et produkt-, komponent- eller kompetenceteam?

‍

Vil du vide mere om agile? Kom med Backstage!
Hold dig opdateret med den nyeste viden inden for agile og digital produktudvikling. Tilmeld dig 👉🏻 syndicate.dk/backstage

‍