Att skapa välfungerande team för IT-utveckling har ofta sina utmaningar. Hur påverkar behovet av till exempel IT-arkitektur , drift, testning, UX och kravställning sättet vi sätter samman personer som tillsammans bidrar till att leverera kvalitet på bästa sätt? Traditionellt sett var det tidigare vanligt att gruppera likasinnade personer som förstod varandra i samma team, men idag har man sett stora fördelar med att istället jobba i tvärfunktionella team.
Teamets ansvar kunde tidigare ses på ett sätt som avgränsat och väldefinierat, där teammedlemmarna tillsammans kunde hjälpas åt med arbetsuppgifter relaterade till deras expertis. I och med att olika expertområden delades upp i olika grupper blev den negativa konsekvensen att så kallade silos byggdes upp, där varje team visserligen förstod sin avgränsade uppgift, men fick svårt att se till helheten.
Ett modernare angreppssätt är att bygga team tvärfunktionellt. Idén med tvärfunktionella team är att teamet själva ska kunna ta ansvar från idé till drift i så stor omfattning som möjligt. Istället för att dela upp team utifrån expertområden, så görs det utifrån domän och verksamhet. På det sättet grupperas personer med olika kompetenser ihop som löser uppgiften tillsammans. Låt säga att en inloggningsfunktion för att låta kunder få tillgång till sin privata information ska utvecklas. Det ansvariga teamet kommer behöva kravställa, designa, utveckla, testa och drifta lösningen. En konstellation av kompetenser som nu tillsammans har förutsättningar att ta ansvar för helheten och användarens upplevelse av applikationen.
Helhetsperspektiv
Med tanke på den leveranshastighet som dagens IT-utveckling kräver, så är agilitet viktigare än någonsin. Istället för att bygga allt på en gång från grunden och uppåt, så behöver man bygga små levererbara bitar i taget som levererar värde. I ett team där alla på sina sätt bidrar under en kort tid för att arbeta fram en funktion, kommer ett helhetsperspektiv på ett naturligt sätt att etableras. Den enskilde teammedlemmen får en uppfattning om hur sitt eget och andra teammedlemmars arbete bidrar till den större bilden.
Autonomi
Ett tvärfunktionellt team blir också autonomt eftersom beroenden mellan team minimeras så långt det går. Så länge teamet följer det som är mest prioriterat, riktlinjer, och levererar i tid, så spelar det ingen roll hur det görs. Teamet har både mandat och ansvar för alla de delar som bidrar till kvalitén ut till kunden. Beroende på hur långt man tagit tvärfunktionaliteten kan teamet ta uppgifter som sedvanligen inte brukar ligga inom ett traditionellt utvecklingsteam, som till exempel drift. Genom att täcka driftansvaret i ett team, kommer muren mellan Dev och Ops rivas. Inga beställningar om installation och konfiguration behöver längre göras. Allt synkas över morgonmötet och mellan skrivborden där teamet arbetar.
T-Shaping
I och med det täta samarbetet mellan teammedlemmar med andra kompetenser än du själv har, kommer du ofrånkomligt lära dig saker du aldrig har arbetat med. Systemtestare lär sig skriva produktionskod, utvecklare lär sig arbeta med UX, Scrummasters får en förståelse i hur prestandatester fungerar. Att ha kvar och vidareutveckla sig inom sitt expertområde, samtidigt som man breddar sig inom andra områden brukar kallas för T-shaping. Målet är inte att bli expert på allt, utan att få en förståelse och om möjligt komma upp till en grundnivå på andra saker än det som är ens starkaste sidor. Med T-shaping får man en förståelse för andras arbete, men också en möjlighet att avlasta i det specifika området, om det skulle vara så att experten blir sjuk, eller om det under en period behövs extra resurser just där. Utifrån en organisatorisk nivå så kan en förflyttelse mot T-shaping få väldigt goda effekter. Dels blir leveransförmågan som helhet mindre sårbar, dels utvecklar sig teamen att arbeta mer tillsammans och på så sätt både förstå varandra och dra nytta av varandras kunskap och arbete.
En utmaning med att bygga tvärfunktionella team är att få in alla kompetenser som behövs utan att teamet ska bli för stort. Här kan T-shaping bidra starkt till att kompetensbehovet täcks även i ett team med 7-8 personer. Nästa steg i en förflyttning mot T-shaping är att man blir så pass vass att man helt självgående bidrar och driver arbetet i de sekundära områdena man valt att bredda sig inom. En person som kan axla flera roller och arbetsområden kallas för Broken Comb. Ett sätt att lättare bli Broken Comb är att satsa på ett nytt område som på något sätt angränsar till det man kan bäst. Backendutvecklare kan ta sig an front-end utveckling. UX designers lär sig kravställning. Testautomatiserare blir prestandatestare.
Mångfald.
I en mångfacetterad miljö är många personers olika perspektiv och bakgrund värdefulla. Även om du råkar jobbar med test, så är du inte den enda som vill uppnå kvalitet. En utvecklare eller en drifttekniker kanske har en helt annan syn på vad kvalitet är och hur den bör uppnås. I ett tvärfunktionellt team finns det både plats och tid för att gemensamt hitta de bästa vägarna mot en effektivare morgondag.
Att bygga tvärfunktionella team handlar mycket om att skaffa de bästa förutsättningarna för att leverera kundnytta på ett kostnadseffektivt sätt. I slutändan är målet detsamma oavsett om du är kravställare, programmerare eller drifttekniker. Så varför inte gruppera oss över kompetensgränserna och hitta nya vägar för att samarbeta med utveckling, testning, kravställning och drift? Kanske kan din nya skrivbordsgranne lära dig något du inte visste om automatiska tester.
Upplever du att det är en utmaning att hitta rätt balans mellan interna resurser, extern expertis och att bygga team med kompetenser som kompletterar varandra för era utvecklingsprojekt?
Genom att svara på några enkla frågor i vårt nya test kan du snabbt ta reda på vad som är rätt mix mellan interna och externa resurser för att kunna lyckas med ditt projekt.