Coaching av programvaruteam, djupstudie:
Coaching practices för XP-projekt på högskolenivå
Björn Pileryd Mikael Pehrsson
D00, Lunds Tekniska Högskola d00bp@efd.lth.se
d00mp@efd.lth.se
13. Maj 2003
Innehållsförteckning
1. INLEDNING 2
2. COACHENS FUNKTION 3
2.1 Tävling inom teamet 3
2.2 Lyssna 4
3. PATTERNS 5
3.1 Planera release 5
3.2 Tracker 5
3.3 Informera om uppdaterad arkitektur 6
3.4 Strukturera 6
3.5 Anteckna 7
3.6 Professionell inställning 7
4. SITUATIONER 8
4.1 Ett par kör fast 8
4.2 Teamets prestanda räcker inte till 9
4.3 Teamet börjar tumma på egna ansvaret / spikes blir inte gjorda 10
5. SLUTSATS 11
6. REFERENSER 12
7. APPENDIX: ENKÄT 1 13
1. Inledning
Coaching är sedan länge ett känt begrepp inom idrottsvärlden. Det introducerades av Timothy Gallwey när han 1975 skrev boken The Inner Game of Tennis och har därefter spridits till andra yrkesområden. Följande definitioner kan vara på sin plats:
Definition:Coach = någon som gör vad som krävs för att du skall ha möjlighet att nå dina uppsatta mål
Mentor = en rådgivare eller någon som agerar ”bollplank”
Som deltagare på kursen Coaching av programvaruteam på Lunds Tekniska Högskola fick vi möjligheten att vara coach för en team bestående av 8-10 studenter som läser årskurs två på Datateknikprogrammet. Att agera coach var väldigt inspirerande men det kändes en aning oklart vad vi egentligen skulle göra. Vi saknade så kallade patterns med konkreta tips för hur en coach kan agera i vissa mer eller mindre generella situationer.
Det faktum att projektet var att utveckla ett program med XP (Extreme programming) som utvecklingsmetodik gjorde det om möjligt ännu svårare att hitta något pattern då detta är en metodik som sällan används ute i industrin. Med hjälp av våra tidigare erfarenheter från XP-projekt och från coachandet i det aktuella projektet bestämde vi oss för att försöka sammanställa coaching practices för XP-projekt på högskolenivå, en samling patterns och diskussioner kring återkommande situationer. Enkäter delades ut till de berörda teamen och vi utvärderade deras åsikter om coaching och diskuterade problem med övriga coacher för att få vidare kunskap inom området. Vårat mål är att dessa coaching practices skall kunna fungera som hjälp till framtida studenter och andra intresserade.
Artikeln börjar med en kort beskrivning av coachens roll samt reflektioner över några aspekter kring coachandet i ett XP-projekt. Därefter redovisas våra framtagna coaching patterns och några återkommande situationer belyses. Slutligen för vi en diskussion kring våra slutsatser. I bilagan till artikeln kan man finna utvärderingen av våran enkät. Varje aspekt och situation efterföljs av ett förtydligande exempel med tillhörande åtgärdsförslag. Delarna avslutas med konkreta nyckelord. Att ge generella lösningar är svårt eftersom det handlar om relationer mellan människor. Även om våra förslag kan tyckas aningen specifika ger de förhoppningsvis ändå inspiration till hur problemen kan lösas.
2. Coachens funktion
Coachen i ett XP-team har ett par fundamentala uppgifter. Följande föreslår Wake i sin artikel Managing XP; Manager, Tracker, and Coach:
Monitor the process – Övervaka
Enforce the process – Stå fast vid samma utvecklingsmiljö för teamet när den väl är definierad.
Change the process – Skräddarsy utvecklingsmiljön efter teamets behov.
Mentor – Agera guide och bollplank åt teamet.
Här är två aspekter på coachens funktion i ett team som vi uppmärksammade under kursens gång och anser viktiga för en coach att vara medveten om. Det finns naturligtvis många fler, men dessa upplevde vi att man lätt förbiser då man är allt för fokuserad på projektuppgiften.
2.1 Tävling inom teamet
I många team-baserade utvecklingsområden infaller sig oundvikligen ett inbördes tävlingstillstånd hos teamet. Detta är en naturlig del av individens vilja att prestera, både för sig själv personligen och för teamet i sin helhet. I projekt där man utvecklar enligt metodiken XP sker inte något undantag. Det faktum att alla ska äga koden och att teamets medlemmar idealistiskt sätt bör vara likvärdiga tror vi kan leda till att vissa medlemmar känner sig kuvade och därmed triggar till inbördestävlan. Om team-sammansättningen är homogen och det interna tävlandet hålls på en relativ låg nivå kan detta skapa en produktiv och stimulerande miljö för teamet. I annat fall tror vi att det kan skapa splittringar och eventuellt få personer att känna sig otillräckliga, vilket i sin tur skulle leda till att XP-metodiken inte efterföljs.
Det är coachens uppgift att se till att teamet har en så bra utvecklingsmiljö som möjligt och att utföra lämpliga åtgärder om så inte är fallet. Coachen måste analysera gruppens tillstånd och försöka identifiera eventuella problem på tidigt stadium. Om miljön är produktiv och stämningen är god inom teamet bör coachen inrikta sig på att övervaka teamet medan han/hon i annat fall får vidta åtgärder. Lämpliga sådana kan vara att delegera storys och spikes på ett sådant sätt att det interna tävlandet elimineras eller att formera utvecklingsparen så att man förebygger internt tävlande.
Exempel
Vi har två team, A och B. Team A består av en homogen och bra grupp programmerare medan grupp B består av ett fåtal mycket skickliga programmerare som utmärker sig i den programmeringsmässigt ganska mediokra gruppen.
I team A skulle inbördes tävlan, förutsatt att det hålls på en rimlig nivå, kunna leda till en mera stimulerande och produktiv miljö där resultatet blir bättre och sammanhållningen inom gruppen till och med ökas. Inbördes tävlan kan också rent konkret leda till effektivare programmering och att t.ex. spikes hanteras på ett seriösare sätt än annars. Coachens uppgift i team A blir att försöka kontrollera så att tävlandet inte
eskalerar och orsakar teamet skada. Lämpliga sätt att kontrollera detta är kontinuerlig rotation bland programmeringsparen samt att dela ut storys och spikes på ett rättvist sätt.
De olika kunskapsnivåerna som finns inom team B skulle i och med detta tävlande eventuellt kunna leda till splittringar inom teamet. Här är det coachens uppgift att identifiera detta på ett tidigt stadium och försöka förhindra att eventuella konflikter uppstår. Detta kan till viss del kontrolleras vid delegering av spikes samt vid utformningen av paren så att en duktig hamnar med en mindre duktig och parbyten görs kontinuerligt.
Nyckelord
1. Evaluera utvecklingsmiljön.
2. Identifiera internt tävlande inom teamet.
3. Bibehåll det fruktbara klimatet/vidta eventuella åtgärder.
2.2 Lyssna
Att kunna lyssna på andra människor på ett bra sätt kännetecknar inte bara en god ledare utan även en god människa. Att lyssna bra är en konst till vilken det är svårt att formulera regler för vad som är bra eller dåligt, eftersom det beror på egenskaperna hos dig och den du pratar med. Att lyssna gäller inte enbart ljud, utan även kroppsspråk, undertoner, mm.
Att helt förklara hur man blir en bra lyssnare ligger utanför ramen på vår uppgift, men vi rekommenderar varmt stycket ”Listening” i Co-Active Coaching: New Skills for Coaching (se källförteckning).
Exempel
Ditt team har som uppgift att utveckla ett lagersystem i Java. Du diskuterar lämpliga datastrukturer med det par som skall implementera detta. Paret är inne på att använda en vektor, och håller just nu på att berätta för dig varför. Dina gedigna kunskaper om datastrukturer säger dig dock att eftersom varor inkommer/avgår ofta behövs snabba metoder för att söka upp, lägga till, ta bort och sortera i strukturen. Dessutom kommer mängden varor att variera kraftigt så att en vektor hade inneburit antingen en massa tomma element eller kostsamma ombyggnader. Du tycker att någon form av lista hade varit en mera dynamisk lösning.
Åtgärder
Avbryt inte dem direkt, trots att du vet att det de kommer att säga kan vara i onödan. Den lilla tid det tar är värd att vänta för att inte köra över dem. Dessutom kan det inträffa att de själva kommer på lösningen, vilket är mycket bra. Om inte, så vid lämpligt läge bör du t.ex. ställa frågan ”Men hur blir det när vi ska lägga till eller ta bort varor”?
Då har du utan att såga deras förslag förhoppningsvis lyckats leda dem på rätt spår.
Ett annat fall som är minst lika vanligt är att du är den som har fel! Framför allt kan du oftast inte veta vilket förslag som är bäst förrän du hört allt de har att säga. Det kan vara en tillgång att låta någon lägga fram ett helt förslag innan man ens nämner något om sitt egna. Idéerna blir mera självständiga då.
Nyckelord
1. Var uppmärksam på hur du själv agerar, försök att se objektivt på det.
2. Avbryt inte den du pratar med. Låt det ta sin tid.
3. Lyssna inte på vad du tänker när någon annan pratar, utan lyssna på dem.
3. Patterns
Här följer en samling patterns som vi genom kursens gång funnit användbara. Det finns redan en del coaching patterns formulerade för XP, men de nedanstående är de vi upplevde som viktigast under projektet.
3.1 Planera release
När det gäller releaser så är vår erfarenhet att det nästan alltid leder till problem i början av ett projekt. Det spelar ingen roll hur pass förberedd man än tror sig vara, utan man får räkna med att det blir stressigt innan deadline och att de första releaserna eventuellt inte blir så lyckade som man önskar. Det finns ett par praktiska råd som coachen dock bör tänka på:
1. Förbered teamet inför den första releasen. Man kan t.ex. dela ut spikes på hur en release går till eller hur man packar ihop en jar-fil.
2. Arbeta gärna fram en checklista för hur en release går tillväga. Det är mycket lätt att glömma något när det är stressigt innan deadline. En checklista gör att i princip vem som helst i teamet kan göra en release.
3. Sätt ett stopp för incheckning av kod i god tid, alternativt förgrena projektet med en releaseversion där några utvecklingspar enbart jobbar med att finslipa releasen.
4. Se till att versionen är noga testad innan release så att enkla och förargliga buggar undviks. Detta kan t.ex. göras av coachen som agerar ”dummy” eftersom han/hon har extra god insikt i kundens krav men samtidigt saknar kodspecifik kunskap som kan göra det svårt att testa alla funktioner.
Nyckelord
1. Dela ut spikes på releasen.
2. Sammanställ en checklista för release.
3. Planera tiden, gärna pessimistiskt.
4. Testa noga.
3.2 Tracker
Övervaka utvecklingen och håll god överblick vad som pågår i teamet. Tänk framåt för att upptäcka vad som måste göras i nästa steg, samt vad man redan nu behöver tänka på.
Mycket tid och möda kan sparas genom ett aktivt trackerarbete. I större projekt är inte alltid coachen och trackern samma person men i vårt projekt med mindre grupper går det bra att en person agerar båda rollerna. Som aktiv tracker bör du anteckna och bokföra hur lång tid saker tar så att estimeringen kan göras realistiskt och med större precision.
Nyckelord 1. Överblicka 2. Bokför 3. Följ upp
3.3 Informera om uppdaterad arkitektur
När ett team på 8-10 personer sitter och utvecklar ett program kan det vara svårt att överblicka systemet och följa med när arkitekturen successivt ändras. Ett enkelt sätt att ge teamet en god helhetsbild av projektet och dess fortskridning är att kontinuerligt ge en uppdaterad överblick av arkitekturen. Som coach kan man t.ex. rita klassdiagram eller flödesdiagram på en whiteboard där teamet sitter och programmerar. Så fort någon ändring görs som påverkar arkitekturen på systemet eller flödet genom detta så är det upp till den enskilde programmeraren att modifiera den uppritade versionen (”alla äger arkitekturen”). Detta leder förhoppningsvis till att problem löses på ett tidigare stadium och kan bidra till så kallade ”stand up meetings” där väsentliga frågor tas upp gemensamt inom teamet.
Nyckelord
1. Uppdatera och bevaka arkitekturen kontinuerligt 2. Använd whiteboard eller dylikt i den mån det går 3. ”Alla äger arkitekturen”
3.4 Strukturera
Det kan vara mycket smidigt att på ett tidigt stadium samla gruppen för att tillsammans komma överens om vilka regler och standarder man ska följa. Detta är ett enkelt sätt att skapa en strukturerad miljö som förespråkar kvalitativ kod såväl som enhetligt systemutvecklande i övrigt. Exempel på färdiga standarder man kan följa är:
1. Java Code Conventions 2. Java Docs
3. Unified Modeling Language (UML)
4. Gemensamma verktyg, i vårt projekt motsvarade detta valet mellan Eclipse och Emacs
Det är också viktigt att teamet kommer överens om frågor så som hur man skall hantera raster och hur ofta man skall byta programmeringspar.
Nyckelord
1. Definiera standarder.
2. Bibehåll en strukturerad utvecklingsmiljö för teamet.
3.5 Anteckna
Att alltid ha något att anteckna på kan vara till stor hjälp under projektet. Många gånger kommer man på idéer eller saker som kan ställa till med problem senare medan man är ute och pratar med paren. För att inte avbryta dem eller tappa fokus på det man pratar om är det bra att anteckna det man kommer på och ta itu med det senare. På så sätt bygger man upp en ”to do” lista som man kan vända sig till när det blir lugnare. Sedan avverkar man listan efterhand som projektet fortlöper. En del punkter kan rent av vara material för hela storys, medan andra kanske bara behöver påpekas för det par som jobbar med motsvarande.
Nyckelord
1. Penna och papper. Samla alla anteckningar enbart på detta.
Bygg en ”to do” lista.
2. Håll hela tiden ett öga på listan, så att problem upptäcks i tid.
3. Vid storytilldelning: Ta en extra titt på listan. Är det något där som påverkar storyn?
Är det något ur listan som måste göras innan ny story kan påbörjas?
3.6 Professionell inställning
Det är mycket viktigt för en coach att agera på ett professionellt sätt. Med detta menas att alltid vara väl förberedd, passa tider och bidra med en positiv inställning till teamet. Detta kan tyckas vara en självklarhet men kan ändå vara värt att poängtera eftersom coachen har ett stort ansvar gentemot sitt team. Om han/hon inte uppfyller kraven kan man inte begära att någon i teamet heller gör det. Som coach är det viktigt att verkligen engagera sig i teamet och projektet.
Nyckelord
1. Var alltid väl förberedd 2. Passa tider
3. Bidra med en positiv inställning 4. Engagera dig
4. Situationer
En situation kallar vi en händelse som inte riktigt passar som pattern, men som ändå är återkommande och intressant.
4.1 Ett par kör fast
Vad som är rimlig tid att lägga på en story avgörs av dess (estimerade) storlek mer än parets prestanda, då det mest är tiden man spenderar på en uppgift som verkar uttröttande.
Att ett par programmerar dubbelt så snabbt som ett annat innebär inte att de blir trötta dubbelt så snabbt. Ett känt faktum är att ett par som kör fast med ett problem gärna vill knäcka det själva hellre än att ge upp och låta någon annan lösa det.
Exempel
Ett par har suttit med samma story i 4 timmar. Du känner ungefär parets prestanda och anser att de suttit längre än rimligt i förhållande till den estimerade tidsåtgången.
Åtgärd
Tala med paret försiktigt utan att direkt antyda om tiden. Bara att få igång paret att beskriva problemet konkret för coachen gör att de strukturerar sig själva. I många fall har vi upplevt att paret oftast själva kommer på lösningen då de gör detta. Fungerar det inte ge dem eventuellt mer tid. Kommentarer som ”Den var nog klurigare än vi trodde”,
”Detta hade räckt åt flera storys”, gör att paret känner mindre att det är deras fel. Fråga sedan hur de vill göra (se nyckelord för förslag). Att låta dem vara med och bestämma gör att risken minskar att de känner sig överkörda. Vill paret fortsätta och du inte anser att ett byte är nödvändigt låter du dem göra det. Till slut är en bytesåtgärd oundviklig. Det gäller att ge teamet inställningen att byten är ett naturligt och positivt hjälpmedel.
Nyckelord
1. Prata tidigt med paret utan att antyda att det är ett problem. Låt dem beskriva problemet
2. Försök komma med egna tips. Klarar coachen av att knäcka problem som de fastnat med ger detta stor respekt.
3. Ge dem mer tid
4. Tala igen med dem, fråga hur de vill lösa det
5. Om de har gjort framsteg och vill fortsätta, låt dem göra det
6. Byt antingen hela paret eller helst bara en av dem, så att man bevarar den kunskap de skaffat sig på vägen. Om det är känsligt att ta uppgiften ifrån dem, ta då in en eller flera andra ur teamet ett tag och låt dem lyssna när paret beskriver problemet.
* Bra tips oavsett tidpunkt är:
Om möjligt, dela upp problemet i mindre storys
Håll ett stand up meeting och diskutera problemet med hela teamet.
4.2 Teamets prestanda räcker inte till
XP-metodiken kan vara ganska känslig för ojämn eller låg kunskapsnivå inom teamet och detta kan bl.a. leda till felaktig estimering, att teamet kör fast lättare, viktiga saker inte blir klara till releaserna, mm. I arbetslivet anställer man folk, och då kan man förhoppningsvis bygga ett team med hög och jämn prestanda, men vid mindre projekt som detta har man varken möjlighet att välja ut eller förbättra medlemmarna nämnvärt efter hand.
Ett team har alltid begränsad kapacitet. Då man märker att teamets gemensamma prestanda inte räckt till helt gäller det att acceptera läget och anpassa sig själv och planeringen efter detta. Det är helt naturligt att blunda och försöka köra på med samma takt som tidigare och hoppas att det vänder, men man bör vidta åtgärder så snabbt som möjligt.
Exempel
Det är tre dagar innan projektets andra release och det är full aktivitet inom teamet. Vissa komplikationer har uppstått under iterationen, men dessa har avhjälpts genom partnerbyte, nedbrytning till mindre storys, mm. Du har haft på känn att det gått lite trögt framåt, men har hoppats att det skulle släppa och att senare storys inte skulle bjuda på samma motstånd, men nu har det blivit mera uppenbart att flera viktiga storys inte kommer att bli klara till releasen.
Åtgärd
Tänk efter först innan du börjar prata om det, så att du kan lägga fram det på ett bra sätt.
Det kan vara känsligt för teamet att inse att de inte presterat tillräckligt eller att de nu befinner sig i ett stressigt skede. Detta behöver inte ens vara teamets fel, men de bör dock vara de första som får reda på att du känner så här. Det inger förtroende att du vänder dig till dem först. Diskutera med teamet hur problemet kan lösas och försök på nytt estimera de storys som återstår. Gör detta realistiskt och summera timmarna först när alla storys är estimerade. Detta ger teamet bevis på att det kommer att bli svårt att hinna allt i praktiken, oavsett vad de själva tidigare trodde. Tala även om att du kommer att prata med kunden om problemet så att de inte tycker att du skvallrar bakom ryggen på dem.
Diskutera situationen med kunden.
Nyckelord 1. Inse läget
2. Belys problemet internt 3. Rapportera uppåt
4. Lösningar: ta in fler programmerare / delegera jobb till andra, välj bort storys, framflytta releasen.
4.3 Teamet börjar tumma på egna ansvaret / spikes blir inte gjorda Det finns en viss frihetsgrad då man jobbar med XP. En del är spikes som skall göras på tid utanför ordinarie projekttid. Det är lätt hänt att en individ inte alltid sitter sina timmar eftersom detta är svårt att kontrollera. Teamet skall ogärna känna att de är övervakade, men inte heller helt fria från ansvar. Inför på ett naturligt sätt en viss kvalitetskontroll redan i projektets början så påverkas inte stämningen negativt.
Exempel
Teamet har kommit en bit in på projektet och det känns som ni börjar lära känna varandra. Eftersom teamet varit skötsamt från början är stämningen bra, och din relation till teamet har kunnat vara avspänd. Det har inte känts nödvändigt att kontrollera noggrant att spikes blir gjorda eftersom du börjar lita på dem. En medlem i teamet har fått en spike som är central och du vill se exempelkod på den. Trots detta har personen inte checkat in något. Som svar får du något som låter som en dålig ursäkt.
Åtgärd
Hur denna situation bäst hanteras varierar kraftigt från person till person, men vi vill ändå försöka ge ett konkret exempel. En generell åtgärd hade blivit alldeles för diffus.
Eftersom detta är första gången det inträffar är det upp till dig att avgöra om det var en engångsföreteelse eller om det kommer att hända igen. Oavsett vilket så kan man kosta på sig att ge personen en chans till. Dock skall man inte köpa personens ursäkt direkt utan passa på när läget bjuds att låta personen känna en viss del skyldighet. En kort paus med lite pinsam tystnad räcker utmärkt utan att du framstår som för övervakande.
Här efter första gången brukar de ansvarsfullas väg skiljas från de ansvarslösas.
Om situationen upprepas och man är osäker på om personen gör det medvetet kan en neutral lösning vara att be dem göra om spiken och checka in den innan följande dag.
Alternativt även tilldela mer spiketid nästa gång.
Nyckelord
1. lyssna på vad personen har att säga som ursäkt, är det en engångsföreteelse?
2. Låt personen märka på dig att du anar vad som är på gång, men att du ändå vill ge honom/henne en chans till. Det inger förtroende utan att du verkar för blåögd.
3. Fundera på ditt sätt att behålla disciplinen och respekten för dig. Håller du en lämplig balans mellan kompis och chef? Bör den förändras?
4. Ge utökade spikeuppgifter. Lämpligt om personen är skötsam med övriga arbetet.
5. Slutsats
Eftersom det var svårt att hitta relaterad information så bygger djupstudien främst på våra egna samlade erfarenheter samt på utvärderingar från de coachade teamen. Artikeln är en sammanställning efter ett avslutat projekt och kan egentligen ses som en slutsats i sig.
Begreppen coach och mentor blir ofta förknippade vilket i sig är ganska naturligt.
Vår uppgift att coacha kunde dock snarare ha definierats som en kombination av att både agera coach men samtidigt fungera som en mentor till teamet. Enkätundersökningen vi gjorde visade att just mentoregenskaperna var något som teamen önskade hos sin coach.
Våra framtagna coaching practices för XP-projekt lämpar sig således främst för roller av typen coach/mentor. Vi hoppas och tror att denna dokumentation kommer att bli användbar för framtida kursdeltagare, inte bara på denna kurs utan även under liknande utbildning.
6. Referenser
William Wake: Managing XP; Manager, Tracker, and Coach.
http://www.xp123.com/xplor/xp0007/index.shtml
L. Whitworth, H. Kimsey-House, P. Sandahl: Co-Active. Davies-Black Publishing Business coaching. http://www.bestepeople.co.nz/coach_definition.php
Kennedy & Company: A History of Coaching.
http://www.resultsthatmatter.com/history.htm
Praktiska erfarenheter av coaching från projektarbete i kursen Coaching av
programvaruteam på Lunds Tekniska Högskola. Detta inkluderar egna erfarenheter, utvärderingar av enkäter samt intervjuer av de berörda teamens medlemmar.
7. Appendix: enkät 1
Vår första enkät delades ut till eleverna i våra respektive team under det första planeringsmötet. Syftet var att innan projektets början ta reda på deras åsikter om coacher och ledarskap.
Vilken utvecklingsmiljö föredrar du?
antal Alternativ
0 Coachen styr allt och bär allt ansvar
1 Coachen går in och styr endast när det behövs
10 Coachen fungerar som ett aktivt bollplank och får dig att själv lösa problemen 2 Alla beslut tas gemensamt inom gruppen, i princip ingen ledare
Rangordna de anledningar som gör att du lyder en annan människa.
Sammanställning av svar
0%
5%
10%
15%
20%
25%
30%
35%
40%
För att undvika konflikter / hålla god min
Personen har större kompetens än du
Du är osäker på din egen förmåga att ta rätt
beslut
För att slippa bära ansvar
För att få belöning (lön / högskolepoäng)
Annat
Anledningar
Vilka tycker du är de 3 viktigaste egenskaperna hos en bra coach?
• samordningsförmåga
• kunskap
• lyhörd
• villig att hjälpa till
• trevlig / social kompetens
• förstående
• bra på att förklara saker
• skötsam, (är på plats i tid, om något behöver ordnas så fixas det.. osv.)
• bra inspiratör
• positiv
• engagerad
• öppen för förslag
• rättvis
• bra på att organisera/planera
• kunna lyssna
• ge order
• kan leda en framåt när man fastnar
Nämn något du tror kan skapa konflikter inom teamet (coacherna inräknade).
• Olika åsikter om hur uppgift bör implementeras, man vill ha olika strukturer på Programmet
• Dålig kommunikation
• Dåligt programmerad kod
• Vara orättvis / ge några privilegier andra inte
• Att beslut och arbetsfördelning inte har diskuterats i gruppen
• Personkemi
• Oklara mål
• Övermäktiga arbetsuppgifter
• Stolthet – ”min lösning är bäst”
Skulle du själv kunna tänka dig att vara coach nästa år? varför då?
Det rådde delade meningar här. Ungefär hälften av de tillfrågade svarade ja.
Anledningarna för var främst att det skulle vara en bra erfarenhet inför arbetslivet, samt att det skulle vara kul och trevligt att leda en grupp helt enkelt. Bland de som svarade nej fanns anledningar så som ”mer intresserad av hårda kurser”, ”jag är inte bra på att leda”,
”skulle ta för mycket tid”, etc.
