Laget före jaget är inte bara en aktuell inställning i samband med fotboll-VM. Det gäller i allt högre utsträckning även inom systemutveckling.

Tiden då utvecklare sågs som ensamvargar som utförde sin magi i tysthet är över på många företag. I stället läggs allt mer fokus på samarbete i team. Och det är gott så, resultatet blir ofta både snabbare systemutveckling och lösningar som passar verksamheten bättre än tidigare.

Att teamet lyfts fram på individens bekostnad har flera orsaker, så väl tekniska och metodmässiga, som sådana som har att göra med kommunikation mellan inblandade i projekt.

Den kanske mest uppenbara orsaken till teamfokus är att de applikationer som byggs blir bättre om folk pratar med varandra. Ett ökat fokus på team hänger ihop med att allt fler väljer agila arbetssätt för utveckling. Med sådana blir det naturligt att samarbeta och hjälpas åt.

Läs också: Det mesta blir sämre när verksamheten står för it-inköpen

Men det finns många fallgropar när mer fokus läggs på utvecklingsteam. Det berättade Iris Classon som är utvecklare på Konstrukt på IDG:s konferens Techworld Summit i Stockholm nyligen. Konstrukt, som har huvudkontor i Göteborg, gör ett populärt verktyg för budgetering, prognostisering och verksamhetsplanering.

Iris Classon beskriver vad som hände på Konstrukt i samband med att antalet utvecklare ökade kraftigt, till ett tjugotal. Expansionen sammanföll med att driften av planeringsverktyget flyttades till molnet, vilket gav upphov till en mängd tekniska problem som behövde lösas. Allt det här gjorde att det blev ett mycket starkt fokus på vad teamet skulle klara av.

Man hanterade den ökande belastningen genom att helt enkelt trycka in mer arbete i varje iteration, eller sprint som de också kallas.

– Vi körde bara på. Och då kan några olika saker hända. Till exempel att man helt enkelt inte klarar av det man planerat att göra, säger Iris Classon.

Hon beskriver att vissa utvecklare tycker att de ”försvinner” i teamarbetet, att de inte syns. Strategin är att hela teamet ska äga koden som produceras tillsammans. Det har många fördelar, som att man inte blir lika beroende av nyckelpersoner. Men det kan också göra att enskilda utvecklare känner sig utbytbara.

Iris Classon beskriver fyra konkreta risker med det här sättet att jobba:

• Till slut är tempot så högt att det blir omöjligt att upprätthålla det. Man kan inte spurta hela tiden. Det här kan leda till utbrändhet, eller som Iris Classon uttrycker det, att ”det inte räcker med en helg eller ens en semester för att vila upp sig”.

• Den tekniska skulden växer eftersom man inte tar sig tid att åtgärda problemen tidigt. Det här leder inte bara till merarbete längre fram, utan även till en stresskänsla under tiden som man bygger en snabb lösning, eftersom utvecklaren vet att det sättet att arbeta kommer att leda till problem.

• Eftersom man hela tiden trycker in mer funktionalitet i iterationerna så blir det ingen tid över för individuell utveckling. Det ger inte bara brister vad gäller färdigheter, utan kan också bidra till att man inte trivs på jobbet.

• Även om teamet äger en mjukvara tillsammans, så hålls det noga koll på vad var och en bidrar med. Det kan göras genom att ”räkna poäng” för funktioner som byggs. I värsta fall förvandlas stormötena under arbetsdagens början till förhör om hur många poäng man klarat av. Om någon utvecklare ständigt har låga siffror kan det inte bara leda till att den personen mår dåligt, utan även till att de andra teammedlemmarna blir irriterade.

Läs också: Snart semester? Låt chefen hjälpa dig varva ner

Vad kan man göra åt de här riskerna? Iris Classon ger fyra konkreta förslag:

• Avsätt tid för att tänka och för att testa ordentligt. Ett sätt är att ha ordentliga ”retrospectives”, alltså möten för reflektioner i slutet av iterationer. Sätt av en hel dag för ett sådant möte. Och försök att undvika att vara tidsoptimist. Man räknar ofta med att vara 100 procent effektiv när en uppgift ska utföras, men så är det sällan.

• Avsätt tid för att hantera teknisk skuld och sköta underhållsarbete. Det är lätt att glömma uppgifter som underhåll av verktyg, till exempel av devopslösningar. På Konstrukt försöker man avsätta hälften av tiden för att hantera teknisk skuld och underhåll, och den andra halvan till att bygga nya funktioner.

• Avsätt tid för personlig utveckling, till exempel att labba med nya tekniska lösningar. På Konstrukt sätts halva fredagen av till det.

• Beröm varandra. Det är en bra tumregel att ge mer beröm än kritik.