När pusselbitarna faller på plats

Du har säkert sett bra team där energin nästan går att ta på men även dåliga team där känslan är att de ligger långt ifrån sin maximala kapacitet. Vad är det som skiljer dessa team? Hur får man team att leverera till sin potential? När de nödvändiga pusselbitarna faller på plats kan ett team snabbt utvecklas till att bli högpresterande.  Det är fascinerande att se team göra denna utveckling.

Så vad krävs för att team skall bli högpresterande? En grundförutsättning är att teamet innehar rätt kompetens för sin uppgift. En annan är teamets sammansättning. Ett team med olika profiler tar ofta längre tid att bli högpresterande men har i gengäld en högre potential då de har mer och differentierad kunskap.

Men oavsett vilka teammedlemmarna är så utvecklas team genom ett antal steg (Schutz, Wheelans, Tuckman, mfl). Inom den agila världen refereras det ofta till Patrick Lencioni’s fem dysfunktioner som påverkar team. Dessa syns även (fetstil) i Tuckmans modell nedan

Fas	Kännetecken / Egenskaper	Viktiga Aktiviteter
Forming	Osäkra, Försiktiga, Artiga Avvaktande och lågt ansvarstagande Låg kommunikation ”Får jag vara med”	Riktat ledarskap Tydliggör mål/förväntningar Skapa förståelse för medlemmarna Öppenhet och återkoppling ger förtroende
Storming	Inre konflikt, Ifrågasättande, motstånd, positionering ”Varför skall vi göra så”	Coachande ledarskap Inkludera alla och diskutera hur det skall göras Hantera konflikter
Norming	Säkra, lugna, teamstolthet  Överenskomna normer och strukturer ”I vårt team gör vi på detta sätt”	Delaktigt ledarskap (Faciliterande/Möjliggörande) Förstärk åtagande/engagemang till teamets gemensamma mål och arbetssätt Arbeta med ansvar  på team/individ nivå
Perfroming	Förbättra, Resultatfokus, Självorganisera Nytta för team går före individen ”Om vi … kommer vi fram snabbare”	Delegerande ledarskap Inspirera mot förbättring/effektivisering Stärk resultat fokus
Adjourning	Separation, Sorg, Osäkerhet, Oro ”Vad händer nu?”	Riktat ledarskap Tydliga avslut /nästa steg Fira åstadkommanden

 

För en tid sedan hade jag förmånen att följa ett team som väldigt snabbt blev högpresterande. Teamet ifråga var lagom stort, sex personer. och var del av ett större projekt inom inbyggda system i färd med att utveckla en ny plattform och produkt. 

Teamet hade misslyckats med att leverera överenskommet innehåll för de flesta av de senaste sprintarna och deras Burn-Down chart (Kvarvarande tid vs nedlagd tid) såg inte bra ut:

 

 

 
       Bild 1-2: Burndown charts innan förändring

Graferna hade diskuterats i sprint-retrospektive där det konstaterats  problem med att leverera det planerade såväl som disciplin att rapportera i JIRA (det valda verktyget)

Man hade bytt teamledare (~scrummaster)  flera gånger under det senaste halvåret och man var nu två sprintar ifrån en viktig leverans. Då kom vändpunkten. Produktägare (PO)  kallade till ett möte för att skapa förståelse för den kommande deadlinen  och varför det var viktigt för PO själv och för teamet. Vilket resulterade i ett tydligt kortsiktigt mål som skapade engagemang.

Tillsammans diskuterades möjliga förbättringar och teamet fattade själva beslut över vilka de nödvändiga åtgärderna skulle vara:

• Fokusera på uppgiften, använda sig av teamledaren för att säga nej/minimera andra uppgifter
• Teamledaren hade tidigare föreslagit pararbete, utan bifall, men nu var teamet redo att prova
• Sätta sig parvis  för att stärka både fokus och parabete
• Rapportera tid bättre i JIRA för att få bättre kontroll på vad som verkligen gjordes
• Lägga mer tid på att bryta ner och estimera sprintbackloggen
• Göra färdigt istället för mycket parallellt arbete -  vilket blev ett resultat av pararbetet

”Det handlade mycket om att få förståelse och acceptans för vårt leveransmål” sammanfattade PO efter vårt möte. ”I de tidigare sprintarna uppfattade jag teamet som splittrat och med många åsikter. Det var verkligen en lärdom att olika individer och team kräver olika ledarskap”, sammanfattade PO när vi hade en uppföljningssamtal ett par veckor efter leverans.

Resultatet lät inte vänta på sig – Redan efter första sprinten levererades hela backloggen med en JIRA kurva från skolboken. Trenden höll i sig i den nästkommande sprinten, så efter fem veckor var det ett stolt team som hade fullgjort sin leverans.

        Bild 3-4: Burndown charts e​fter förändring

Var det då bara försiktigare planering och JIRA rapportering som blivit bättre?
NEJ, uppfattningen i teamet (och av PO) var att man även levererat mer

Teamet reflekterade över anledningarna och kom fram till:

• Motivationen att nå det utsatt målet från PO
• SPIKE och mer detaljerad planering medförde att man visste vad man skulle göra
• Att ligga nära sprintmålet ökade åtagande/engagemang och även antal  nedlagda timmar
• Genomföra uppgifter i par uppfattades som effektivt
• Fokus på rätt uppgifter (här hjälpte planen, lokalisering och pararbetet)

När teamledaren och jag reflekterade över vad som skett menade han att ”det verkligen var förlösande när vi först fick engagemang mot målet och sedan såg att planen var utmanande men fullt realistisk” men var även lite självkritisk ”Kanske försökte jag jobba mot självorganisarande team för tidigt? Det var frågor som behövde klargöra som  vi inte fick på plats förrän vi blev pressade och jag blev mer direkt i min ledarstil”

Vad tar vi med oss från detta?

Pusselbitarna för att få högpresterande team är olika beroende på var teamen är i sin utveckling. När team är i tidig fas (”norming”) är behovet annorlunda mot när man kommit ur konfliktfasen (”storming”). En viktig poäng är att ledarskapet ändras under denna utveckling.

I det beskriva exemplet behövde teamet dels hjälp att lämna ”storming”  - med att sätta ner foten kring ett par ”hur  gör vi” frågor, men även kring att enas kring ett tydligt kortsiktigt mål för att skap åtagande/engagemang.

Hur får vi till mål som skapar motivation och delaktighet? SMART-formulerade mål är en bra checklista. Många känner till konceptet menförvånansvärt få annamar det (antagligen främst pga. brist på tid). Många gånger är det inte tydligt vad som skall uppnås, till vilken tid, eller vilka tillgängliga medel som står till buds. Nedan exemplifierat från fallet ovan:

• Specifikt: Det blev tydliggjort både varför leveransen var viktig och vad som ingick
• Mätbart:  Efter sprintplaneringen blev backlog / burndown chart tydligt och mätbart
• Accepterat: Baserat på den realistiska planen accepterade teamet leveransmålet. Man bestämde själva vilka förbättringar som var nödvändiga.
• Realistiskt: Teamet hade själva gjort en planering som visade att målet var utmanande men möjligt.
• Tidsbundet: Leveransdatum var tydligt, vilket var fem veckor från möte med PO och omplaneringen.

Problemet med mål är ofta att man har för lite tid till hands och sätter mål där uppgiften inte  är tillräckligt analyserad. Det leder till oprecisa mål som ofta är orealistiska.

Välformulerade mål är viktiga under hela teamets utveckling. I de tidiga faserna skall det få teamet åt samma håll medan i de senare faserna skall målet inspirera till förbättringsaktiviteter.

Varför skall vi lägga tid på planering – är en kommentar som är vanlig från team. Att ta fram genomarbetade estimat och planer är förstås bra för att hantera beroenden mellan team, resursfördelning, sätta ordning av uppgifter och ha ett underlag för uppföljning. Men för att göra en bra estimering krävs nedbrytning av funktionalitet tills man har tillräckligt förståelse för vad som behöver göras. Så det som ses som planeringsarbete (utan uppenbart värde) är många gånger att dela upp och förstå problemet. Planering är viktig för teamets utveckling. Utan nedbrytning och riktiga estimat är det svårt att få balanserat arbetsinnehåll (det blir ofta väldigt mycket mer än teamet hinner med). Detta leder till lågt åtagande/engagemang och ansvar. En gemensam planering leder också till ökad insyn i alla uppgifterna och stödjer ett gemensamt ansvar. Utan planering är risken stor att uppgifter delas upp per individ i teamet som själv skall köra sitt ”miniprojekt”.  Då är det lätt att teamet stannar i ”norming” och alla är nöjda med att sköta sitt.

En av de största anledningarna till ineffektivitet för team är för mycket parallellt pågående arbete där alla uppgifter skall bli klara samtidigt. Det leder till ökade ställtider, längre tid till återkoppling och lärande, svårare att följa status och främjar att teammedlemmar arbetar med separata uppgifter (miniprojekt). Dessa leder till att blir längre ledtider per uppgift och högre risk för att uppgifter påbörjas utan att bli avslutade. Det teoretiska upplägget med att alla i teamet jobbar med samma uppgift sekventiellt fungerar sällan praktiskt eller kompetensmässigt. Men ett exempel är hur fyra parallella uppgifter kan hanteras parallelt eller mer sekventiellt.

Observera att A är klar under 25% av tiden och att B och C blir klara långt tidigare i det sekventiella upplägget.

Ordningen på jobben är viktig, funktionens värde för kunden är teoretiska korrekta enligt de flesta agila metoderna.  Men detta är sällan hela sanningen, andra aspekter att ta hänsyn till är förseningskostnad, storlek, teknisk osäkerhet och resursberoende kan i olika situationer vara lika viktiga. (Speciellt vid nyutveckling av en ny produkt så går det ofta inte skilja på olika delar utan det krävs en helhet för leverans).

Att göra färdigt ofta snabbar även upp teamets utveckling. Det främjar det pararbete vilket leder till ökat förtroende och engagemang och även kortar tiden till ”storming” fasen. Teamet får oftare diskutera vem, vad och hur vilket driver mot ”storming” och ”norming”. Dessutom ökar motivationen med att man oftare kommer i mål.

För egen del som Agil Coach var det en utmanande/inspirerade dialog med
produktägaren kring hur vi skulle få en engagerande målbild, etablera lagom nivå av uppföljning och hur backlogen skulle prioriteras. Coachningen av teamledaren inkluderade bla.: på vilket sätt vi skulle landa ”hur” frågor, få till ”lagom” detaljnivå i planeringsen för att hjälpa teamet att hålla fokus och att få teamet att känna ansvar.