Hur sätter man ihop ett agilt team?

En av de tidiga aspekterna av en agil transformation eller för den delen en förflyttning mot ett mer lättrörligt arbetssätt är att sätta ihop ett agilt team (ibland kallat ett scrumteam) I regel brukar man säga att ett team består av 3 huvudroller. Produktägaren, Scrum Mastern samt utvecklarna (teammedlemmarna).

För att skapa hanterabara team skall storleken på ett agilt team , enligt Scrum och flera andra ramverk, vara mellan 3-9 personer. Detta inklusive Scrum Master och Produktägare. Men vad behöver man tänka på mer? Vilka är riskerna eller konsekvenserna om man slarvar med att sätta ihop sitt Agila team?

Exempel på vanliga problem i agila team

Genom åren har vi på Onbird observerat några vanligt förekommande problem när team sätts samman. Dessa är:

• Konflikter i teamet. Eller team som inte klarar att samarbete på ett bra sätt.
• För att inte nämna icke hanterade konflikter i teamet. Där medlemmar i teamet undviker varandra. Alternativt endast tolererar sina kollegor/teammedlemmar. Utan att för den delen respektera och samarbeta med dessa kollegor.
• Team där medlemmar driver egna agendor och ärenden. Det vill säga i teamet delar man inte prioritet, arbetsmetoder, kvalitetsstandarder eller andra aspekter av gemensamt arbete mot gemensamma mål.
• Personberoenden (ibland extrema sådana) till specialister i teamet.
• Inte ovanligt heller är demotiverade team. Som ständigt drabbas av omorganisationer, personalbrist och personalförändringar.
• Slutligen också överstressade medarbetare som slits mellan många olika team och för stora arbetsbördor.

Oönskade efftekter till följd av dåligt sammansatt agilt team

Utöver de rent negativa effekterna för medarbetare kan det lätt uppstår fler negativa följdeffekter. Vilka också kan drabba den verksamhet som teamet är satta att leverera till. Således har vi flera gånger observerat:

• Långa ledtider i leveranser. Eller projekt som pågår i evighet utan att bli klara.
• Dålig kvalitet på det som levereras. Antingen i termer av instabila system eller helt enkelt dåliga lösningar.
• Ofullständiga leveranser som inte möter kunders/intressenters förväntningar eller behov.
• Överdrivet höga kostnader för lågt levererat värde.
• Stor/oönskad personalomsättning. Där tyvärr ofta våra vassaste teammedlemmar är först att lämna.
• Frostig/icke-fungerande relation mellan verksamhet/beställare och teamet.

Sammanfattningsvis, 7 viktiga faktorer att beakta

Dessa problem kan för teamets kunder leda till sämre service. Dålig intern lönsamhet/ekonomi och i värsta fall väsentligen sänkt konkurrensförmåga.

Utifrån dessa problem har vi identifierat sju viktiga faktorer, att beakta noga, vid sammansättningen av ett agilt team. Dessa faktorer är:

• En tydlig produkt att utveckla.
• Ett lagom stort agilt team
• Till vem levererar teamet, vilka är de centrala intressenterna.
• Medarbetare ska helst inte placeras i flera team samtidigt.
• Teamets kompetensresurser bör säkras i tre olika dimensioner.
• Låt teamet utveckla sin dynamik och samarbetsförmågor.
• Uppmuntra teamet att formulera mål och spelregler för sig själva för sin egen ständiga utveckling.

Här följer ett utdrag ur texten. Vill du ha läsa texten kan du ladda ned den nedan.

1.   Ge det agila teamet en tydlig produkt.

Till att börja med, teamet behöver som sagt ha ett tydligt scope eller ansvarsomfång. Vad är det teamet ska respektive inte ska ansvara för. I agila termer oftast kallat en ”produkt”.  Vidare är det ofta viktigare att definiera vad som inte ingår i teamets produkt än vad teamet faktiskt har ansvar för. Vidare ska en produkt vara förståelig. Den ska skapa ett tydligt värde för dess mottagare/nyttjare. Och vanligtvis är den föränderlig över tid.

Med detta i åtanke, så kan produkten gärna/helst/ofta definieras i termer av någon form av verksamhetsförmåga. Såsom tex E-handel, logistik eller någon delmängd därav. Om man därmed ser att delar av det ansvarsområde man tänkt ge teamet inte är så föränderligt, ska kanske dessa delar ska exkluderas. Alternativt hanteras någon annanstans och/eller enligt traditionella metoder. Denna fråga behöver därför beaktas med tillsammans med storleksfrågan nedan.