Gruppdynamik och gruppsykologi i Extremet Programming

Transkript

1 Gruppdynamik och gruppsykologi i Extremet Programming Jerry Malm, d02jm@efd.lth.se Gustav Olsson, d02og@efd.lth.se Lunds Tekniska Högskola Lund, den 22 februari 2005

2 Sammanfattning Denna djupstudie kan ligga som grund för en introduktion till kommande års studenter i kursen, Coaching av Programvaruteam vid Lunds Tekniska Högskola. Den ska även kunna väcka frågeställningar om hur man kan påverka sitt team genom sitt agerande som coach. Man vill, genom sitt agerande, skapa ett team som trivs tillsammans samtidigt som de producerar högkvalitativ kod. I djupstudien presenteras ett antal metoder och resultaten av dessa ifrån vårt projekt. Däremot inte sagt att resultatet alltid kommer bli desamma, ett annat team kan och kommer säkerligen få annorlunda utfall av samma metod. Djupstudien kommer även att gå igenom coachens roll och FIROmodellen utifrån våra egna funderingar kring kursen. Dock kommer vi enbart att gå igenom de sociala bitarna av coachens roll och utelämnar de tekniska aspekterna. 2

3 Innehållsförteckning 1. Inledning 4 2. FIRO-modellen 4 3. Coachens roll 5 4. Scenario Scenario - Teamet möts för första gången Scenario - Frågor utan svar Scenario Medveten krasch i systemet Scenario Belöning/Bestraffning 9 5. Utvärdering Slutsatser Källförteckning 11 3

4 1. Inledning Under den teoretiska delen av kursen Coaching av Programvaruteam, som ges på Datainstitutionen vid Lunds Tekniska Högskola, kände vi att det saknades en hel del inom områdena gruppsykologi och gruppdynamik. Enligt oss är detta en minst lika viktig del av coachningen som kunskaper om XPmetodiker och programmering i allmänhet. Valet av djupstudie hamnade därmed inom dessa områden för att utöka våra egna kunskaper inom området, men även för att praktiskt få testa olika metoder av ledarskap. Djupstudien påbörjades genom att leta upp tänkbara scenario teamet skulle kunna råka ut för under kursens gång. Dessa scenarier analyserades sedan för att hitta tänkbara lösningar och ageranden från vårt håll som coacher. Underlag för eventuella scenarion och lösningar införskaffades i huvudsak från [1] CoachIsMe av Magnus Starseth och [2] Pedagogiska Grunder för Försvarsmakten. Om metoderna, som presenterades i rapporterna, inte föll oss i smaken försökte vi att ta fram egna metoder för att senare testa dessa under kursens gång. Målet, med våra metoder, var att så snabbt som möjligt nå den effektiva fasen, öppenhet, i FIRO-modellen. I denna rapport kommer resultatet om vad som lyckades samt vad som gick mindre bra att diskuteras. Vidare kommer våra slutsatser och resultat att jämföras med de slutsatser som Magnus Starseth dragit i sin slutsats. Rapporten kan vara en bra introduktion för kommande års studenter i kursen Coaching av Programvaruteam. 2. FIRO-modellen En amerikansk psykolog, Will Schutz, utvecklade under sin tid i den amerikanska flottan en teori som många personer refererar till när man vill beskriva en grupps utveckling. Studierna ledde till det som kallas FIRO-modellen, Fundamental Interpersonal Relations Orientation. Modellen beskriver tre olika huvudstadier som en grupp kommer att gå igenom. Den första fasen, tillhöra, är stadiet som en nybildad grupp befinner sig i början. Under denna fas är alla måna om att bli accepterade av övriga gruppmedlemmar. Vanliga funderingar under denna fas är om man kommer passar in i gruppen samt vilka de andra personerna är. Den andra fasen, rollsökning, är stadiet då alla gruppmedlemmarna försöker hitta sin roll i gruppen. Oenigheter 4

5 gällande kunskap, ledarskap och kompetens är vanliga inslag eftersom det, med största sannolikhet, kommer att uppstå konfrontationer mellan de olika gruppmedlemmarna. Den avslutande fasen, öppenhet, är stadiet då alla medlemmarna har hittat sin roll i gruppen. Alla gruppmedlemmarna lägger sin energi på att nå ett gemensamt mål. De har också kommit varandra nära och kan kommunicera mycket effektivare med varandra, vilket i sin tur leder till att antalet konflikter minskar. Figur 1: FIRO-modellen Bara för att en grupp kommit till det tredje stadiet behöver det inte nödvändigtvis betyda att rollerna i en grupp är bestämda för evigt. Det händer ibland att gruppen går tillbaka till den andra fasen och medlemmarna får på nytt försöka hitta sin roll. 3. Coachens roll En väldigt viktig del av att bli en bra coach, enligt oss, är att få en bra relation med sitt team. Då djupstudien genomförts på personer som läser en kurs så påverkar detta vårat agerande som coacher. Detta beror på flera faktorer som beskrivs här nedan. Skillnaderna mellan en team-medlem och en coach är, när det gäller programmeringskunskaper, ålder och arbetslivserfarenhet, inte särskilt stora. Detta gäller både i det verkliga arbetslivet och även här på Lunds Tekniska Högskola. Man ska inte försöka inbilla team-medlemmarna att man är mycket bättre än dem, utan istället vara uppriktiga mot dem om ens kunskapsnivå. Detta eftersom de annars kommer att tappa respekt och tillförlit till en om de upptäcker att man försöker framstå som bättre än vad man i själva verket är. Motiveringen till detta är att man inte kan skapa ett förtroende ifall man inte är ärliga mot varandra. 5

6 En annan viktig poäng är att inse att detta inte är ett riktigt projekt utan en del av en kurs vid Lunds Tekniska Högskola. Detta gör att alla team-medlemmarna inte har samma förkunskaper och mål. En del utvecklare har mycket goda erfarenheter av programmering sedan innan samtidigt som en del endast kommit i kontakt med programmering genom skolan. Ute i arbetslivet bestämmer coacherna vilka team-medlemmar han vill ha i sitt team beroende på deras olika kunskaper. I kursen, Coaching av Programvaruteam, slumpas däremot grupperna fram och därmed kan inte gruppen skräddarsys utifrån deras kunskaper. Därför är det viktigt att inte coacha teammedlemmarna som om det vore ett projekt ute i det verkliga arbetslivet. Det är dock viktigt att försöka efterlikna verkligheten men en del saker måste man ta hänsyn till. Team-medlemmarna deltar i projektet för att lära sig grunderna i XP-programmering och coacherna för att lära sig att coacha ett XP-team. Detta gör att misstag, med största sannolikhet, kommer att begås eftersom varken team-medlemmar eller coacher är fullärda individer på deras respektive områden. Om alla i teamet är införstådda med detta från början kommer ett fel från coachernas, samt team-medlemmarnas, håll inte framstå som så särskilt stort. Även när det gäller gruppsammanhållningen är det viktigt att ta hänsyn till att det är en kurs. Det är med största sannolikhet så att team-medlemmarna har större delen av sitt liv och sin bekantskapskrets utanför XP-kursen. Alla i gruppen är kanske inte intresserade av att gå och äta lunch eller att ta en kort fikapaus tillsammans. Man ska inte påtvinga alla team-medlemmar den sociala gemenskapen. Det är dock viktigt att alla respekterar varandra. 4. Scenario Följande scenarier är de vi i förväg förväntade oss skulle ske under projektets gång. De beskrivs här nedan på följande sätt. Först en inledande förklaring om varför vi valde scenariot. Därefter följer vårt planerade genomförande och slutligen utfallet, vilken effekt eller vilket resultat det fick. 4.1 Scenario - Teamet möts för första gången Med erfarenheter från våra egna liv så vet man att folk är väldigt blyga när de träffas för första gången. Man ser gärna att någon annan än en själv tar och utmärker sig då man vill hålla en låg profil. Vidare förväntade vi oss att några team-medlemmar skulle 6

7 känna varandra sedan innan. Detta tillsammans med föregående punkt skulle leda till att folk grupperade sig och för att få göra stories eller spikes tillsammans. Då det är viktigt att snabbt få en bra sammanhållning i gruppen (komma igenom första fasen, tillhöra, av FIRO-teorin) ville vi snabbt få gruppen att ta ett stort ansvar istället för att vi skulle behöva berätta exakt vad och hur saker skulle göras. Coachernas roll är inte att gå in och bestämma med järnhand utan är mer ett ansvar att hålla projektet gåendes i rätt riktning. Vår idé var att hålla en tillbakadragen roll under första mötet och istället tvinga team-medlemmarna att prata med varandra och själva ta initiativet. Under första planeringsmötet presenterade vi oss för teamet och förklarade att vi läste en kurs som hette Coaching av Programvaruteam. Vi gick även igenom designen för den nollte iterationen så att alla fick en liten bild av projektet. När planeringen av första iterationen skulle genomföras drog vi medvetet oss tillbaka. Detta gjorde vi genom att slänga ut en fråga eller ett påstående och invänta ett svar eller en diskussion inom teamet. Resultatet av vårt agerande blev att alla satt och lyssnade gediget under vår korta introduktion till projektet. Då planeringsmötet övergick från introduktion till planering av första iterationen blev det extremt tyst när vi försökte få dem att prata och diskutera med varandra. Det dröjde ibland upp till två minuter innan vi ens fick respons på de frågor vi ställde eftersom ingen vågade utmärka sig. Nåt som man oftast gör i såna situationer annars är att man själv svarar på frågan men i det här speciella fallet höll vi tyst. Efter ett tag blev tystnaden så pinsam att någon tog på sig ansvaret och besvarade frågan eller startade en diskussion. När vi gick ifrån första planeringsmötet visste vi inte alls hur bra genomslag vår idé hade fått hos våra team-medlemmar eftersom de var väldigt tysta även i slutet av planeringsmötet. Under det första coachingmötet visade sig dock att det varit så här i så gott som alla team. Skillnaden var dock att under första iterationen var vårat team väldigt framåt och öppna för diskussioner mellan varandra, vilket de flesta andra team verkar ha saknat under första iterationen. Vi tror, med stöd av utvärderingen som gruppen fick göra, att detta berodde på att vi medvetet drog oss tillbaka och intog en passiv roll. Dels under planeringsmötet, men även att vi fortsatte med det under laborationen. Teammedlemmarna insåg ganska tidigt, under laborationen, att de inte skulle få något gratis utan att de skulle tvingas att lösa det genom diskussioner inom gruppen. 7

8 4.2 Scenario - Frågor utan svar På första iterationen förväntade vi oss att team-medlemmarna skulle ställa större delen av frågorna till oss coacher. Vi trodde också att de inte skulle prata så mycket mellan varandra, vilket skulle leda till konflikter och merge-errors. Vår tanke var att teamet skulle lära sig att inte söka svar ifrån oss coacher utan istället söka denna kunskap inom teamet. Deras samlade kunskaper är garanterat större än våra enskilda. När någon frågade oss om ett svar gav vi dem svaret att de skulle ta upp problemet inom gruppen och komma fram till en gemensam lösning. Under första iterationen var det, precis som väntat, väldigt vanligt att ett programmeringspar fastnade på något och beslutade sig för att fråga oss coacher om råd. Istället för att, som vanliga laborationshandledare, ge svaret direkt hänvisade vi istället till att ta hjälp av övriga medlemmar i teamet. Detsamma gällde frågor gällande datastrukturer och design. Vi ville att teamet själva skulle avgöra vilken datastruktur och design som de skulle arbeta med. Dels ledde detta till att det inte blev några merge-konflikter och att teamet var bra insatta i systemet redan under första iterationen. Det ledde också till att parbytena blev smidigare eftersom teamet tillsammans löste svåra problem och då var insatta i övriga pars sysselsättningar. 4.3 Scenario Medveten krasch i systemet Under tredje iterationen var det planerat att vi, som coacher, skulle checka in en bugg i det gemensamma systemet, repositoryt. Detta för att skapa en konflikt inom teamet och på så sätt få teamet närmare den effektiva fasen, öppenhet, i FIROmodellen. Genom att medvetet låta ett team få konfrontera varandra vill man att gruppmedlemmarna i slutändan ska ha kommit närmre den effektiva fasen eftersom de släppt ut en del av de aggressioner som de sitter inne på. Detta beror på att gruppmedlemmarna får bekräftat vilken roll de ska ha i gruppen. När tredje iterationen kom hade vi tänkt checka in en bugg under lunchen. Detta blev dock aldrig av, då det visade sig att teamet själv hade lyckats få in en bugg i repositoryt när de laddade upp sina spikes. Tyvärr reagerade inte teamet som vi hade hoppats. Detta beror troligen på att team-medlemmarna inte såg buggen som något någon i gruppen hade åsamkat, utan att det var [4] Eclipse som 8

9 orsakat den. Det blev inga inre konflikter mellan personer eftersom de inte hade någon att anklaga samtidigt som de var fokuserade på att hitta lösningen till problemet. Efter att teamet hade felsökt i ca en och en halv timme, utan något lyckat resultat, gick vi som coacher in och hjälpte teamet med att hitta lösningen till buggen. 4.4 Scenario Belöning/Bestraffning I Magnus Starseths djupstudie [1] CoachIsMe påpekar han vikten av belöningar och bestraffningar. Detta är något som vi till fullo håller med om, dock skiljer sig våra åsikter åt om hur man skall göra det. Vi anser att det, åter igen, är viktigt att komma ihåg att detta är en kurs och att deltagarna mer eller mindre är här frivilligt. Vi som coacher hade ingen direkt större makt än övriga deltagare i teamet eftersom allihop var studenter. Det är därför svårt att själva försöka utdela straff. Mindre saker, som att någon inte vill byta par eller medvetet kommer för sent, skall självklart påpekas så att team-medlemmarna inser att de begått ett misstag. Om någon sätter sig emot dessa regler eller upprepat kommer för sent bör man låta den kursansvarige behandla detta. Dels för att sannolikheten att bestraffningen får önskad effekt blir större, men också för att hålla kvar förtroendet mellan coacherna och teammedlemmarna. I vårt team hade vi problem med att en person efter några iterationer började komma för sent. Då det hände andra gången påpekade vi inför hela teamet att om man kommer för sent till en laboration eller ett planeringsmöte så leder detta till att man får extrauppgifter, som delas ut av den kursansvarige. Vi påtalade detta för hela teamet och riktade det inte speciellt till någon person. Syftet var att påminna hela teamet om vad som gällde, men samtidigt pika personen i fråga. Efter samtalet med teamet tog vi även upp problemet med en av de kursansvariga som då såg till att vara närvarande vid starten av nästa planeringsmöte. Personen i fråga dök aldrig upp på detta möte och fick därför en extrauppgift. Eftersom hela teamet nu viste att vi menade allvar med vad vi hade sagt var det inga problem med närvaron efteråt. Personer som någon gång hade kommit någon minut för sent innan såg nu till att vara där i god tid. 9

10 5. Utvärdering För att få en övergripande bild om hur väl våra metoder slog ut, men även för att få reda på om teamet hade uppfattat samma saker som oss, bestämde vi oss för att genomföra en utvärdering under planeringsmötet på iteration fyra. Utvärderingen genomfördes på följande sätt: Under ca 15 minuter fick gruppen svara individuellt på frågor som vi hade skrivit upp på tavlan. Svaren skrevs ner på papper under tiden som vi väntade utanför. Detta eftersom vi ville att svaren skulle vara så ärliga som möjligt. Vi påpekade innan genomförandet att vi ville ha ärliga svar för att få en så bra uppfattning som möjligt av utfallet av våra metoder. Svaren skulle senare ligga till grund för denna djupstudie samt ge oss värdefulla kommentarer för att förbättra vårt coachande. 6. Slutsatser Vi tycker att det är svårt att dra allt för långtgående slutsatser då djupstudien enbart bygger på observationer under en femveckorsperiod, cirka 50 timmar. En av slutsatserna som vi drar är att man ska ta kursen för vad det är, nämligen en kurs och inget annat. Självklart vill och skall man försöka efterlikna verkligheten till så stor del som möjligt, men på flera aspekter går det inte. Dessa rör, tyvärr, till stor del gruppdynamiken eftersom utvecklingen endast var en liten del av utvecklarnas vardag. Vi anser att det, trots detta, går att påverka gruppens sammanhållning och effektivitet genom att påtvinga teamet de olika stadierna i FIRO-modellen. Det är önskvärt att uppnå den effektiva fasen, öppenhet, så snabbt som möjligt. Vi känner att gruppdynamik och FIRO-modellen fått för lite utrymme i kursens inledande teoretiska del då dessa är minst lika viktiga moment i kursen såsom XP-metodik och programmering. Även om man inte till hundra procent kan styra teamet så är det bra för coacherna att ha en grundläggande förståelse inom dessa områden för att kunna förstå en grupps beteende i olika stadier. Kursen är trots allt en kurs som ska lära ut hur man coachar ett team, inte bara lära sig XP-metodiken ännu en gång. Om en coach uppfattas som bra eller mindre bra anser vi beror på hans/hennes förmåga att leda och förstå sig på gruppen. Inte på hur pass duktig han/hon är på att programmera då det inte är coachen som skriver produktionskoden. 10

11 7. Källförteckning Rapporter: [1] Magnus Starseth: CoachIsMe Ledarskap i ett nötskal och några goda råd om bra coaching [2] Pedagogiska grunder för Försvarsmakten (Pedagogiska grunder), M Internet: [3] FIRO-modellen [4] Eclipse www. eclipse.org 11