Svårt att få ihop teamet? 5 tips för att göra teamet till ETT

Tiden då testare och utvecklare kunde sitta på varsitt håll och jobba är förbi, det fungerar helt enkelt inte längre. Teamen måste bli mer agila, agila på riktigt och dela på ansvaret - från ax till limpa. Det kan däremot krävas en del arbete för att få ihop teamet som önskat, därför delar vi i det här inlägget med oss av fem värdefulla tips för ett starkare team.

Vi måste försöka se till att alla i teamet drar åt samma håll, har samma mål och förståelse och komma ifrån vår beskyllarkultur. Ett team - En produkt, är det som gäller trots oändligt med integrationer och beroenden. Går en release åt fanders är det inte en enskilds grupps fel utan teamet som har brustit i sina rutiner och i sitt arbetssätt. Är vi överens så långt trots att detta är utmanande och svårt? Bra, men hur kommer vi rent konkret till ett läge där hela teamet, oavsett roll samarbetar och delar på ansvaret och gemensamt står och faller med slutresultatet? Svaret är inte helt enkelt som många har fått erfara men här kommer några välbeprövade tips som vi av erfarenhet vet fungerar:

Dela information och lägg test tidigt

Dela information så att alla inom teamet får den samtidigt, det gör att alla hela tiden är på samma blad. Traditionellt sett har det varit så att utvecklare har fått se krav och design först och testarna har fått informationen långt senare. Därför är arbetssättet mobbprogrammering, där utvecklare och testare gemensamt sitter och programmerar och granskar tillsammans med UX, ett konkret exempel på hur detta skulle kunna gå till.

Ytterligare ett exempel som effektiviserar och knyter utvecklare och testare samman är att testarna själva får möjlighet att bygga sina egna virtuella miljöer. Detta möjliggör en granskning av utvecklarnas pull request trots att de inte är 100 procent klara, vilket medför en dialog och ett sätt för testarna att kunna hjälpa till och själva skaffa sig en bild så tidigt som möjligt.

Vidare kan man fundera kring varför en specifik testresurs ska kontrollera allt? Är det inte bättre att testresursen lär ut en del av sin kompetens (oftast det kritiska tänkandet) till personen eller de personer som är bäst lämpade att kvalitetssäkra det som måste kontrolleras? Varför ska en testare till exempel lära sig hur nätverkstrafiken ser ut när det finns en nätverkstekniker på plats? Är det inte bättre då att nätverksteknikern blir coachad och tar ett större helhetsansvar? Även utvecklarna borde med fördel bli coachade till ett mer nyfiket arbetssätt så att kvalitetsmedvetenheten ökar redan från kodrad ett.

Anpassade metoder framför processer och delegerat beslutsfattande

Arbetsmetoderna är centrala när vi pratar om att bygga team. Att vara agil och bygga lättrörliga team har länge handlat om att ta in en massa processer och sedan köra dem fullt ut utan att reflektera över varken verkligt engagemang och utfall. Ett modernt - agilt och välfungerande arbetssätt handlar mer om beteenden och attityder än metoder och processer som oftast bara tar dyrbar tid då syftet försvinner på vägen. Skräddarsy därför era metoder och processer efter teamets behov, som på så sätt får känna mer mening och gemenskap och hitta både teamets och slutanvändarens varför.

Låt teamet ta gemensamma beslut som förankras i verksamheten för bästa resultat. Se till ert nuläge och ta små nästa steg, för in glädje och energi, skapa en gemensam modell och öka kontrollen för att minska antalet obehagliga överraskningar. Försök dessutom att kontinuerligt utmana och ge dina teammedlemmar stimulerande arbetsuppgifter som de tillsammans kan växa med. Det gör att alla känner sig delaktiga, vilket eliminerar “vi och dem”-känslan. Vi tar ansvar för produkten, inte bara det vi själva anser vara vårt! Försök även få ut färdig kod så fort som möjligt (helst dagligen), för färdig kod är både kostsamt och dålig för teamets moral om den inte kommer ut i produktion. Ha sedan nära kontakt med supporten om sådan finns och gör fältstudier för uppföljning även om slutresultatet till synes gått bra - feedback ska alltid ses som en värdefull gåva.

Definition of Done måste inkludera test

För att backa bandet och ge fler tips för komma hit, så ska alla storys ha ett tydligt Definition of Done, där test är ett absolut krav. Det ska framgå vilken nivå det ska testas på och vilka delar som eventuellt ska ha ett automat-testfall. Om det inte är uppfyllt kan storyn inte stängas. Skapa därför en väldigt tydlig prioritering av storys, tasks och buggar som skall utföras och gå alltid tillsammans igenom förutsättningarna för aktuell story innan utveckling påbörjas. Starta inte för mycket samtidigt utan se till att göra klart så mycket som möjligt och hjälp varandra istället för att starta en massa parallella processer.

Code Review

Code reviews är något som de flesta gör men se till att ni verkligen analyserar lösningen utifrån kraven ni har skrivit och att önskade autotester finns på plats. Ju tidigare man kan identifiera ett problem i en implementering desto bättre! Se även till att beskriva era pull requests samt referera till motsvarande ärende på boarden så att en reviewer snabbt får en uppfattning om implementationens scope. För att initialt få med sig alla på förändringståget, lyft fram konkreta exempel på positiva effekter som kommer påverka teammedlemmarna och deras dagliga arbete. Det brukar vara en mer effektiv medicin för en skeptiker istället för buzzwords och en mer holistisk approach.

Walk the board

Och slutligen: Walk the board. Låt era stand-ups handla om er board, inte om teammedlemmarna. Vad du gjorde igår och ska göra idag är i regel inte lika relevant för teamet som att prata utifrån de ärenden som för tillfället ligger på er board och att teamet tillsammans sätter en stolthet i att ärenden inte fastnar på vägen mot DONE. Har teamet många ärenden i testkön kan med fördel en utvecklare hoppa på ett par testärenden (som denne inte utvecklat själv) innan man börjar arbeta på något nytt. Har teamet gjort sin läxa med Acceptanskriterier och Definition of Done så kommer alla i teamet förstå hur man ska testa ett ärende och känslan av att man tillsammans ansvarar för teamets och produktens fortlevnad och välmående ökar markant.

Ta reda på vilket team som passar bäst för ditt utvecklingsprojekt!

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.