XP vs. Tillverkningsindustrin

Djupstudie i Coaching av programvaruteam Lunds Tekniska Högskola 2006-02-20 XP vs. Tillverkningsindustrin Hur behandlar man The FIVE dysfunctions of a TEAM? Emil Svärdh D02, Lunds Tekniska Högskola d02es@efd.lth.se

Abstract Denna rapport är en undersökning av hur XP-metodiken förbygger eller minimerar risken att The five dysfunctions of a team uppträder i ett programvaruutvecklingsteam. I rapporten gör jag även en jämförelse av hur XP hanterar problemen. Jag kommer även att göra en jämförelse med hur tillverkningsindustrin hanterar dessa problem. För att kunna göra det har jag intervjuat två produktionsledare för tappningen på V&S Absolut Spirit i Åhus. Slutligen kommer slutsatser dras angående hur man kan dra nytta av varandras erfarenheter för att kunna motverka The five dysfunctions of a team. -2-

Innehållsförteckning 1. Inledning...4 2. Bakgrund...5 3. The five dysfunctions of a team...6 3.1 Absence of Trust...6 3.2 Fear of Conflict...7 3.3 Lack of Commitment...7 3.4 Avoidance of Accountability...8 3.5 Inattention to Result...8 4. Extreme Programming Practises...10 4.1 Coding Practises...10 4.1.1 Code and Design Simply...10 4.1.2 Refactor Mercilessly...10 4.1.3 Develop Coding Standards...10 4.1.4 Develop a Common Vocabulary...10 4.2 Developer Practises...10 4.2.1 Adopt Test-Driven Development...10 4.2.2 Practise Pair Programming...11 4.2.3 Adopt Collective Code Ownership...11 4.2.4 Integrate Continually...11 4.3 Business Practises...11 4.3.1 Add a Customer to the Team...11 4.3.2 Play the Planning Game...11 4.3.3 Release Regularly...11 4.3.4 Work at a Sustainable Pace...12 5. Hur motarbetar XP The five dysfunctions of a team?...13 5.1 Absence of Trust...13 5.2 Fear of Conflict...14 5.3 Lack of Commitment...15 5.4 Avoidance of Accountability...15 5.5 Inattention to Result...16 6. Hur motverkar industrin The five dysfunctions of a team?...17 6.1 Absence of Trust...17 6.2 Fear of Conflict...18 6.3 Lack of Commitment...18 6.4 Avoidance of Accountability...19 6.5 Inattention to Result...19 7. Hur kan XP dra nytta av industrins erfarenheter?...20 8. Referenser...21-3-

1. Inledning Denna djupstudie behandlar Lencioni s The five dysfunctions of a team [1] och kommer till mångt och mycket centreras kring hur XP s practises [2] kan motverka dessa. Även en jämförelse med hur tillverkningsindustrin kommer att representeras i studien, denna grundar sig på intervjuer med två produktionsledare [3][4] på V&S Absolut Sprits. Till grund för studien av funktionsstörningarna använder jag boken The five dysfunctions of a team skriven av just Patrick Lencioni. Slutligen kommer jag i denna studie att försöka fundera ut på vilka sätt XP skulle kunna förbättras för att på ett bättre sätt motverka de fem funktionsstörningarna. -4-

2. Bakgrund Under den första delen av kursen Coaching av programvaruteam (EDA270) [5] läste vi en liten del om funktionsstörningar i grupper, speciellt fokuserat då genom Lencioni s The five dysfunctions of a team [1]. Detta intresserade mig vilket gjorde att jag naturligt valde att läsa mer om dessa i min djupstudie samtidigt som det verkade intressant att läsa mer om hur XP motverkade dessa funktionsstörningar. För att ytterligare ge studien lite substans ville jag även genomföra intervjuer inom något företag för att se hur de jobbade för att minimera effekterna av funktionsstörningarna. Det blev naturligt att göra denna studie på V&S Absolut Spirits då jag själv jobbat där. -5-

3. The five dysfunctions of a team Patrick Lencioni beskriver i sin bok, The five dysfunctions of a team [1] en modell bestående av fem olika steg som ett team måste vara utan för att vara ett fungerande team. Stegen i hans modell illustreras i figuren nedan: Figur 1 - Modell över "The five dysfunctions of a team" Denna modell beskriver hur ett team fungerar eller vad ett team måste jobba på. Då allt i pyramiden ovan hänger ihop måste man börja med att bearbeta Absence of Trust [1] om den existerar för att med tiden arbeta sig upp för att avsluta med att bearbeta Inattention to Result [1]. Tanken är att då denna funktionsstörning är bearbetad skall man ha ett väl fungerande team som samarbetar väl och producerar en produkt med hög kvalitet. Jag kommer nu att gå in mer noggrant på vad de olika stegen i modellen innebär samt ge exempel på hur utvecklarna kan bete sig om de känner av denna. 3.1 Absence of Trust En av de absolut viktigaste egenskaper som ett team måste ha är att de litar på varandra. Skulle det vara så att medlemmar av ett team inte litar på varandra är det omöjligt att upprätthålla ett fungerande team. I detta fall så syftar orden lita på varandra till att man litar på varandras förmåga att t ex producera kod i ett projekt eller att man litar på coachens välvilja. Med andra ord är det viktigt att utvecklarna inte känner sig hämmade av någon i gruppen [1]. En del i att lita på varandra kan vara att man av egen erfarenhet vet att en viss person alltid producerar kod med väldigt hög standard och på det sättet kan man lita på den personen. Lencioni [1] vill dock dra detta ett steg längre genom att säga att det inte räcker med den sortens tillit utan man måste även vara beredd att berätta för gruppen om sina svagheter, misstag man gjort samt våga be om hjälp samtidigt som man känner att ingen i gruppen vid något tillfälle skulle kunna tänka sig att använda det för att trycka en själv. -6-

Då ett team inte litar på varandra leder det lätt till att diskussioner inom teamet avslutas med på ett destruktivt sätt då ingen vågar säga emot den som talar högst, vilket leder oss till nästa steg i modellen, Fear of Conflict [1] (se punkt 3.2). 3.2 Fear of Conflict Alla relationer som skall vara över en längre tid kräver att man engagerar sig i produktiva konflikter för att relationen skall växa [1]. Det samma gäller i ett team, då man skall arbeta tillsammans över en längre tid måste man uppnå ett stadie då man känner att man vågar konfrontera varandra på ett konstruktivt sätt. En svårighet med att uppnå denna konstruktiva konflikt är att coachen för teamet lätt kan uppfatta konflikten som oproduktiv. Som coach måste man vara väldigt säker på att det är en destruktiv konflikt innan man går in och försöker medla mellan parterna. Produktiva konflikter i ett team har egentligen som ända syfte att utvecklarna skall producera den bästa möjliga lösningen på så kort tid som möjligt [1]. Då detta genomförs diskuteras problemen noga och då båda parter är väldigt passionerade i debatten kommer man oftast fram till ett enhälligt beslut vilket sedan genomförs utan att någon känner sig nedtryckt för att den andra parten hade ett bättre lösningsförslag. En coach i ett team där han/hon tror att detta problem finns kan t ex försöka lyssna om diskussioner mellan teamets medlemmar slutar med personangrepp. Detta är ett tydligt tecken på att alla inte vågar säga sin idé utan istället använder personangrepp för att trycka ner den andra parten vilket är ytterst destruktivt för teamets produktivitet. Då teamet inte har konstruktiva diskussioner vid viktiga beslut så känner inte alla medlemmar att de till 100 procent kan ta till sig de idéer som kom fram vid beslutet [1]. Problemet är att man inte tagit nytta av alla medlemmars idéer vilket leder oss till nästa steg i modellen, Lack of Commitment [1] (se punkt 3.3). 3.3 Lack of Commitment För att verkligen kunna engagera sig för teamets bästa måste man uppnå två saker, klarhet i beslut samt att alla köper idén [1] för att senare verkställa den. Team som uppfyller detta stadie av modellen gör klara och koncisa beslut som alla håller med om, även de som hade argument för att lösa problemet på ett annat sätt under den beslutsfattande fasen. Team som detta inte fungerar för lämnar ofta det beslutsfattande stadiet med tanken att det kanske är någon i teamet som inte håller med om beslutet för att sedan trots beslutet som fattades göra det på sitt eget sätt. Enligt Lencioni [1] finns det två huvudordsaker till detta problem, behovet av konsekvens samt behovet av säkerhet. Inom teamet måste man på något sätt hitta en väg för personer som inte håller med om beslutet så att även de jobbar efter det man beslutade. En viktig punkt i detta är att människan oftast inte har svårt att gå med på ett beslut så länge de har fått säga sin åsikt, genom att alltid låta alla framföra sin åsikt kan man på detta sätt försäkra sig om att merparten av gruppen -7-

stödjer lösningen av problemet. Då medlemmarna trots detta inte kan komma överens är det coachens uppgift att komma in och fatta beslutet. Fungerande team på denna punkt förstår även att det är bättre att fatta ett beslut än att inte fatta ett beslut alls [1]. Det är även viktigt att teamet inser att man kan fatta ett felaktigt beslut för att sedan ändra beslut vid ett senare stadie då det visade sig att en annan approach hade varit bättre. För att sammanfatta hela detta stadie kan man säga att det är viktigt för teamet att alla medlemmar får presentera sina idéer innan man fattar beslutet. Om ett team inte är helt säkra på att alla i teamet köper det beslut som fattades samt vet exakt vad det innebär är det även väldigt svårt att ställa någon ansvarig för att vederbörande löste problemet på ett annat sätt, vilket leder oss till nästa steg i modellen, Avoidance of Accountability [1] (se punkt 3.4). 3.4 Avoidance of Accountability För att ett team skall fungera måste alla medlemmar våga berätta för sin coach om personer som tummar på kodkvalitet eller vars beteende kan skada teamets bästa. Ett av de stora problem med att överkomma denna funktionsstörning är att man överlag hellre håller en kompis / team-medlem baken ryggen än att talar om för personen i fråga att det du håller på med är fel för att man inte vill riskera den personliga relationen man har. På något sätt måste man arbeta för att få bort detta då det ofta visar sig att då man gärna berättar för varandra om felaktigheter man gör så växer den personliga relationen [1]. En annan aspekt på det hela är att då man påpekar varandras felaktigheter så ökar man även pressen på personen ifråga, d v s man visar för personen att man förväntar sig mer av vederbörande [1]. På detta sätt behöver inte personen i fråga känna någon extra press från coachen utan vet precis vad övriga medlemmar förväntar sig av honom eller henne. När man är medlem i ett team så finns det ju faktiskt inget värre än att få veta att resten av teamet tycker att man försinkar gruppen samtidigt som de hela tiden uppmuntrar en till att göra bättre resultat. Press från medarbetare känns dock bättre än att coachen skall gå in och sätta press på en. Om man aldrig hålls ansvarig för felaktigheter man gör leder det ofta till att man istället för att tänka på gruppens bästa fokuserar på sin egen framfart, vilket leder oss till det sista steget i modellen, Inattention to Result [1] (se punkt 3.5). 3.5 Inattention to Result Enligt Lencioni [1] så är det absolut värsta som kan hända i ett team att dess medlemmar bryr sig mer om något annat än det kollektivt bästa för gruppen. Lencioni [1] tar även upp det faktum att när man mäter resultat skall man inte enbart titta på finansiell vinst utan även att teamet har åstadkommit ett bra arbete såsom t ex kodkvalitet samt funktionalitet. -8-

För att kunna överkomma detta stadie är det viktigt för organisationen som står bakom projektet har en tydlig plan på vad som skall vara färdigt vid en specificerad tid. Med andra ord de mål som chefer, coacher och alla andra överordnade på företaget sätter upp blir en drivkraft för utvecklarna. Lencioni [1] ställer sig nu frågan Vad skall ett team fokusera på om det inte vore resultat?. Han svarar även på frågan med två olika alternativ, statusen för teamet samt den individuella statusen. Statusen för teamet [1] kan t ex vara att för vissa medlemmar av ett team är det enbart nödvändigt att vara en del av teamet och man känner sig inte alls resultatinriktad. Man kan se det som att medlemmen känner sig som en statusperson bara för att han/hon ingår i ett vinnande team utan att man kanske bidrar med speciellt mycket. Individuell status [1] kan t ex vara att en medlem av teamet framhäver sig mer än de andra och påpekar för allmänheten att det var jag som gjorde allt bra så all Crédit för projektet borde tillfalla mig. Detta enbart för att höja sin egen status på arbetsmarknaden vilket får till följd att man inte tänker på det kollektiva, d v s teamets bästa vilket är att alla var delaktiga till denna framgång. -9-

4. Extreme Programming Practises I denna sektion av djupstudien kommer jag att kortfatta beskriva de olika practises [2] som XP använder sig av för att senare i studien göra en jämförelse hur dessa motverkar de ovan beskrivna The five dysfunctions of a team [1]. 4.1 Coding Practises En av de absolut viktigaste egenskaper ett team har är att koda ett program. För att uppfylla detta på ett tillfredsställande sätt används en del practises [2] vilka beskrivs nedan. 4.1.1 Code and Design Simply Man kan sammanfatta denna practise som att utvecklarna skall göra det enklast möjliga som skulle kunna fungera. Samtidigt vill man ändå upprätthålla en viss flexibilitet då det faktiskt är så att en enkelt skriven kod är lätt att förstå och därmed även enkel att ändra i då man förstår snabbt vad koden gör. 4.1.2 Refactor Mercilessly Med refaktorisering menas att man ändras en kods utseende utan att ändra dess funktionalitet. Detta gör man för att hela tiden hålla hög standard på koden och undvika duplicerad kod. Man kan säga att det finns två olika stadier av refaktorisering, förebyggande refaktorisering samt rensande refaktorisering. Förebyggande används för att förbereda kod för en ny funktionalitet med rensande används efter kodning då man snyggar upp allt. 4.1.3 Develop Coding Standards Alla måste komma överens om en specifik standard man skall koda efter, detta för att alla lättare skall förstå koden. Det är även ett verktyg för att man skall kunna kommunicera inom teamet med samma kodningsstandard. Hjälper även till vid refaktorisering (se punkt 4.1.2) då det är lättare att förstå koden. 4.1.4 Develop a Common Vocabulary För att man skall kunna prata med alla involverade i projektet är det viktigt med en gemensam vokabulär. Även personer som inte är insatt i koden som producerats kan på detta sätt kommunicera om delar av projektet. En hjälp till detta kan vara användandet av egenutvecklade metaforer vilka på ett enkelt sätt kan beskriva komplicerad funktionalitet. 4.2 Developer Practises För att framgångsrikt kunna driva ett projekt framåt krävs det att utvecklarna samarbetar. För att uppfylla detta på ett tillfredsställande sätt används en del practises [2] vilka beskrivs nedan. 4.2.1 Adopt Test-Driven Development När du skall koda projektet du jobbar med så börja alltid med att skriva ett enkelt testfall som inte går igenom för att sedan koda den absolut enklaste kod man kan för att få det att gå -10-

igenom. På detta sätt driver man utvecklingen av programvaran framåt genom att hela tiden skriva testfall för att sedan implementera en lösning för dem. 4.2.2 Practise Pair Programming När man programmerar skall man alltid sitta två och två. Den ena personen skriver kod varefter den andra övervakar det hela. På detta sätt försöker man upprätthålla en hög standard på koden samt hela tiden försöka hitta den optimala lösningen. Man kan väl sammanfatta det hela som att två hjärnor tänker fortare och bättre än en. 4.2.3 Adopt Collective Code Ownership Med detta menas att alla äger all kod som finns i projektet, d v s alla har rättigheter att ändra på vad de vill i koden. Då man även använder sig av testdriven utveckling (se punkt 4.2.1) är det väldigt enkelt för utvecklarna att kontrollera om deras nyskrivna kod fungerar genom att köra alla test som är gjorda och se om de går igenom. 4.2.4 Integrate Continually Det är viktigt för utvecklarna att de hela tiden uppdaterar det gemensamma repositoriet varje gång de har ny fungerande funktionalitet, för att alla skall få tillgång till den. Då man följer detta är det ju även viktigt att man gör på andra hållet, d v s hela tiden uppdaterar den kod man arbetar med för att hela tiden ha tillgång till all funktionalitet. 4.3 Business Practises För att klara av att genomföra ett projekt krävs det mycket mer än bara att kunna koda. För detta finns en hel del utvecklade practises [2] vilka beskrivs nedan. 4.3.1 Add a Customer to the Team När man hela tiden har en kund i teamet kan man vid behov även prata med denna för att klura ut frågor angående funktionalitet och användargränssnitt. Kunden kan på detta sätt snabbt informera utvecklarna om saker som skall ändras önskemål om ny funktionalitet. Kunden representerar ju faktiskt den framtida användaren av systemet som utvecklas. 4.3.2 Play the Planning Game Innan någon funktionalitet implementeras är det viktigt att den tidsuppskattas samt att kunden väljer ut vilken funktionalitet han/hon tycker är viktigast. På detta sätt men en nära kundrelation är utvecklarna hela tiden säkra på att det som utvecklas ju nu är den funktionalitet som kunden behöver allra mest. 4.3.3 Release Regularly Teamet som utvecklar mjukvaran skall hela tiden släppa nya versioner till kunden av programmet. Då man hela tiden släpper nya utgåvor kan kunden vid varje release komma med krav på förbättringar eller rapporter om funktionalitet som ej fungerar. På detta sätt upprätthåller man hela tiden produkten till det stadie som den slutgiltiga kunden vill ha. -11-

4.3.4 Work at a Sustainable Pace För att under projektets fortlöpande kunna arbeta i samma takt hela tiden är det viktigt att man inte överarbetar sig. Genom att ha en bestämd tid man arbetar varje vecka, t ex 40 timmar per vecka kan man säkerställa att utvecklarna håller samma takt igenom hela projektet då de aldrig kommer till jobbet med en känsla av att vara överarbetad. -12-

5. Hur motarbetar XP The five dysfunctions of a team? I denna sektion av studien kommer jag att för varje funktionsstörning beskriva vilka practises [2] inom XP som motarbetar denna. Naturligtvis kommer det även att medfölja en förklaring till varför practisen gör detta. 5.1 Absence of Trust En av de principer som XP använder sig av är att alla utvecklare skall sitta i samma rum, The Bullpen [2], vilket rent logiskt iaf enligt mig borde göra att utvecklarna börjar lita på varandra då de hela tiden befinner sig på samma plats. Detta gör mer eller mindre att utvecklarna är tvungna att prata med varandra varefter de kommer varandra närmare och slutligen börjar lita på varandra. En annan aspekt är det att XP vill att man skall bedriva programmeringen två och två, pair programming [2], vilket leder till att det hela tiden bedrivs diskussioner mellan två personer vilket gör att de bildar ett fungerande team. Då man under utvecklingens gång byter par kontinuerligt leder det till att alla inom teamet jobbat med varandra vid ett tillfälle eller ett annat. Av detta kan man dra slutsatsen att då personer kommer varandra nära och tvingas jobba tillsammans blir de oftast vänner som känner att de kan anförtro sig till varandra. En undersökning [6] av detta visar även att man programmerar bättre med mindre buggar när man parprogrammerar vilket enligt mig i sin tur borde leda till att man ger varandra mer tillit. Detta är ju även bra då en mindre erfaren programmerare starkt kan dra nytta av den andres erfarenheter och på så sätt lita mer på sin förmåga och på så sätt litar fler teammedlemmar på personen ifråga. En annan aspekt på det hela med programmering två och två, pair programming [2], är att utvecklarna hela tiden måste rådfråga varandra [6] och diskutera fram den bästa lösningen eller arkitekturvalet. Det är även viktigt att kontinuerligt ta pauser för att upprätthålla produktiviteten [6] vilket om man tar den tillsammans enligt mig borde göra så att teamet växer samman på ett mer personligt plan. Även testdriven utveckling, test-driven development [2], motverkar denna funktionsstörning då man hela tiden vet att det gemensamt implementerade fungerar. Detta leder till att man känner att man kan lita på vad de andra utvecklarna i teamet implementerat och på detta sätt byggs även en personlig relation där man litar på varandra upp samtidigt som var och en bevisar för teamet att de litar på varandras kod. Med detta resonemang kan jag även lägga till kollektivt ägande av koden, collective code ownership [2], då det är ett sätt för alla att verifiera att den kod som skrivs är effektiv och bra vilket ökar förtroendet för varandras implementationer. Då man arbetar i ett hållbart tempo, work at a sustainable pace [2], kan man även försäkra sig om att ingen utvecklare har en riktigt dålig dag, iaf inte beroende på att vederbörande är överarbetad. När jag tänker efter borde även detta bygga en grund av tillit då man kan konstatera att dåliga dagar i början av ett projekt kan leda till att den personen missuppfattas under en längre period av projektets fortlöpande. T ex skulle en person kunna hacka ner väldigt mycket på de andra utvecklarna under en dålig dag vilket är ytterst destruktivt för en växande tillit inom teamet. -13-

Slutligen måste jag tillägga att även XP s feature spike [2] fungerar väldigt bra för att motverka att man inte litar på varandra. När jag nu coachar ett team märkte jag ganska snabbt att en av utvecklarna var väldigt blyg och knappt vågade säga vad han tycket vilket i sin tur tycker jag visade sig ytterligare genom att de andra inte riktigt litade på hans förmåga att producera. Detta förstärks även av att vederbörande gjorde en hel del fel och dåliga lösningar i början av projektet. För att komma till saken så delade jag och min coachingkollega ut en spike till honom att göra ett ANT-script till releasen detta ledde i sin tur till att han blev något av en expert på just detta som de andra i teamet var tvungna att till viss del luta sig mot honom. Detta ledde sedan till at han blev mer och mer delaktig i alla beslut och deltog mer och mer i alla diskussioner som uppkom kring möjliga problem eller liknande. Numera är vederbörande en väldigt god tillgång för teamet och tvivlar aldrig på att öppna sin mun vid åsikter eller eventuella invändningar. Av detta drar jag även slutsatsen att spikes [2] kan motverka Fear of Conflict [1] då personen ifråga faktiskt numera vågar ta upp en konstruktiv diskussion eller ge konstruktiv kritik. 5.2 Fear of Conflict I tidigare punkt beskrev jag The Bullpen[2], denna kan även appliceras på denna funktionsstörning genom att då alla sitter i samma rum är det lättare att ta upp en konstruktiv diskussion med någon av de andra i teamet. På detta sätt kan även alla andra utvecklare höra synpunkterna och slutligen bilda en konstruktiv diskussion inom hela teamet om detta skulle vara nödvändigt. En annan punkt är att då man hela tiden programmerar två och två, pair programming [2], gör det även det lättare att ta upp en diskussion då man är två som står bakom samma idé. Dock kan även detta vara negativt om man av någon anledning skulle para ihop två personer som inte vågar ta upp en diskussion. Detta skulle kunna leda till mycket skitsnack om i deras mening dåliga idéer vilket verkar destruktivt för både teamet och projektets fortlöpande. En annan aspekt på detta är att man hela tiden byter inom paren vem som är driver respektive navigator [2] vilket leder till att båda två inom paret får ventilera sina åsikter vilket jag anser borde leda till fler konstruktiva diskussioner. Då man hela tiden kan ha kontroll över all kod som implementerats, collective code ownership [2], ökar det även insikten över vad som implementerats vilket kan tyckas ge en bättre grund till att ta upp en konstruktiv konflikt. Bland annat hände detta i teamet jag coachar just nu då det visade sig att någon hade ändrat i fler klasser än nödvändigt vilket gjorde att arkitekturen förändrades mer än nödvändigt. En person i teamet reste sig då upp och tog upp problemet, detta ledde till en konstruktiv konflikt vilket till slut gjorde att teamet fattade ett beslut om att arkitekturen skulle behållas. Även under planning game [2] blir det lättare att ta upp problem då man t ex från repositoriet kan komma med konstruktiv kritik varefter en konstruktiv konflikt uppkommer. En nackdel med detta kan ju dock vara att det kanske inte direkt är lämpligt att ha någon typ av konflikt då kunden är närvarande. Ett annat exempel under planning game skulle kunna vara att man t ex tar upp klara brister i coding standards [2] hos något par i teamet. Med detta resonemang kan jag även dra slutsatsen att coding standards minskar risken för Fear of Conflict [1]. Problem på kodsektionen kan också mycket snabbt upptäckas om man integrerar kontinuerligt, integrate continually [2], varefter diskussionerna angående dessa bli mindre än om man t ex hade utvecklat efter vattenfallsmodellen. På grund av att XP även använder sig -14-

av enkel design, code and design simply [2], borde koden vara lätt att förstå varefter diskussion angående lösningen tas upp utan att ett missförstånd av funktionaliteten uppkommit. Även här kan man ju applicera exemplet jag beskrev ovan. Ytterligare ett sätt att minska risken för destruktiva konflikter är att använda ett gemensamt ordval, common vocabulary [2], vilket rent teoretiskt borde ta bort alla diskussioner av destruktiv karaktär då jag anser att ett gemensamt ordval minskar risken för missförstånd och därmed även diskussioner av destruktiv karaktär. Slutligen kan ju även tilläggas att det konstruktiva konflikter faktiskt även kan leda till att man utvecklar ett gemensamt ordval, common vocabulary [2]. Detta kan i sin tur leda till att de konstruktiva konflikterna snabbt löses och alla känner sig trygga med att ventilera sina åsikter. 5.3 Lack of Commitment Genom att alla talar samma språk, common vocabulary [2], undviker man även att det kan vara missförstånd som gör att inte alla vill vara med på idén trots att man under mötet kommit överens om att man skulle göra det på ett visst sätt. Trots ovanstående resonemang kan det ju uppkomma situationer där vissa inte vågar säga vad de tycker på mötet utan bara håller med på ytan för att sedan gå och implementera efter sin egen idé som för övrigt ingen annan fått ta del av. Detta tycker jag mig se kunna motverkas mycket väl genom par programmering, pair programming [2]. Resonemanget lyder som följer; En person håller inte med om ett beslut på ett möte, men väljer att inte kommentera det hela. Han/hon sätter sig sedan ner och skall implementera det hela efter sitt eget bevåg. Mitt antagande i detta resonemang är nu att rent teoretiskt borde den andra personen som vederbörande arbetar ihop med försöka få in personen på rätt spår genom att konsekvent påpeka då fattade beslut inte följs. En annan practise som motverkar detta är just att planning game [2] är till för att estimera stories men jag tycker även att det finns stora möjligheter att här ta upp lösningsförslag eller liknande varefter alla får vädra sina åsikter. Då man även använder common vocabulary [2] på planning game så minskar man ju som ovan nämnt riskerna för missförstånd. En annan faktor som spelar in på denna funktionsstörning är practisen code and design simply [2] varefter alla beslut angående vilken approach man skall ta i ett problem skall vara den enklast möjliga. På detta sätt finns det egentligen bara en lösning som är den optimala vilken troligen de flest också inser då den dyker upp under mötena. 5.4 Avoidance of Accountability Även denna funktionsstörning kan motverkas med hjälp av par programmering, pair programming [2], då jag tror det är lättare att vid felaktigheter skylla på två personer istället för att hänga ut en person. Dock är det ju ytterst ovanligt att personer måste ställas till svar för felaktigheter i koden då man även använder testdriven utveckling, test driven development [2]. Med andra ord minskar även testdriven utveckling riskerna för denna funktionsstörning. Även det faktum att alla äger koden, collective code ownership [2], gör det enklare att ställa någon till svars för felaktigheter då de mycket snabbt upptäcks. Att ställa någon till svars för -15-

förändringar som gjort att funktionalitet förstörts är ju inte direkt svårt då man enkelt kan visa för vederbörande att just det här testet inte går igenom. En liten nackdel med XP är att den vill att man kontinuerligt refaktoriserar, mercilessly refactoring [2], vilket gör att felaktigheter skulle kunna suddas ut om vederbörande som refaktoriserar så vill. Dock är ju detta en av XP s största fördelar då den hela tiden bärgar för en enkel och bra design. Såvida man inte använder ett utvecklingsverktyg med versionshanteringssystem är det nästintill en omöjlighet att ställa den ansvariga mot väggen, dock väger fördelarna iaf enligt mig över för att kontinuerligt refaktorisera koden. Även det faktum att man inom XP arbetar inkrementellt d v s små förändringar hela tiden vilket slutligen gör en stor förändring men med enkel design torde ju leda till att man enkelt kan följa upp vad var och en gör då man lätt kan se vid vilken story [2] problemet uppkommit och på detta sätt ställa vederbörande inför ansvar. 5.5 Inattention to Result Att inte alla bryr som om det kollektivt bästa kan motverkas ganska väl genom par programmering, pair programming [2], då man iaf kan hoppas att den ena parten fokuserar på det kollektivt bästa. Min tanke är ju då att om någon inte jobbar för det kollektivt bästa skall den andra parten skall leda in den villrådiga på rätt väg igen. En annan aspekt som motverkar detta är just att man hela tiden släpper en ny utgåva, release regularly [2]. På detta sätt är det svårt för någon i teamet att försöka ta på sig äran för allt som gjorts. En annan aspekt som ytterligare stärker detta påstående är det faktum att man skall arbeta i ett tempo som man kan hålla, work at a sustainable pace [2], vilket torde göra det svårt för utvecklare att dra till sig mer ära för framgången då alla jobbat precis lika mycket på den. För att ytterligare bli mer resultatinriktad adapterar XP att man skall testa först, test driven development [2], vilket leder till att det även blir hög kvalitet på det man tillverkar. Resultatet man levererar blir då fungerande och bra varefter man kan berömma teamet med argumentet att man gjort ett bra jobb både ekonomiskt och kvalitetsmässigt. Enligt XP [2] så skall man under projektets fortlöpande producera lika mycket hela tiden, d v s man skall hela tiden producera lika mycket funktionalitet, t ex estimerar man att man klara 40 gummibjörnar varje vecka skall det hållas hela projektet. Skulle man jobba mer och mer hela tiden d v s klara av fler och fler gummibjörnar varje vecka skall man göra sig av med personal för att behålla den konstanta produktiviteten. I ett fall där någon bryr sig mer om sitt eget ego än kollektivets bästa skulle man då kunna ta bort just den personen. -16-

6. Hur motverkar industrin The five dysfunctions of a team? Undersökningen av hur tillverkningsindustrin kämpar för att bli av med The five dysfunctions of a team [1] har jag gjort genom att intervjua Frederik Turner samt Andreas Stenberg på V&S Absolut Spirit i Åhus. Intervjuerna med ovan nämnda personer började med att de fick fylla i ett formulär med frågor angående om dessa funktionsstörningar finns i gruppen eller ej. Formuläret som användes var skapat av Lencioni [1], se sida 192, när detta sedan var ifyllt analyserade jag resultatet för att sedan ställa frågor angående hur de motverkade eventuella funktionsstörningar som formuläret pekade på. För att på ett bra sätt kunna beskriva hur tillverkningsindustrin måste jag börja med att berätta efter vilken princip löpande bandet fungerar. Bilden nedan illustrerar hur linjen ser ut. Figur 2 - Beskrivning av linje på V&S Absolut Spirit Systemet fungerar som följer. Först kommer flaskorna in i sektion 1 varefter de via ett löpande band transportera till sektion 2 där de fylls på. När flaskorna är fyllda transporteras de vidare till sektion 3 där etiketter sätt på. Efter etikettering transporteras flaskorna till sektion 4 där de paketeras i lådor varefter de skeppas iväg. 6.1 Absence of Trust En viktig del för att uppnå tillit till varandra är att man vågar fråga om saker som man inte själv kan lösa. För att uppnå detta jobbar man med något som kallas tekniksamordnare [3][4] vilket innebär att man har en så kallad mindre chef över var och en av sektionerna jag visar i figur 2. Tanken med dessa personer är att de har det yttersta ansvaret för just den sektionen varefter alla skall kunna känna trygghet att fråga de om problem de ej kan lösa uppstår. -17-

För att uppnå tillit spelar även ledarens roll in, man måste kunna lita på dem också och för att uppnå det är det som ledare viktigt att föregå med ett gott exempel, vara neutral i alla situationer för att en lösning av problem naturligt skall uppkomma följt av att man skall leva som man lär [3]. Ledaren roll är även viktig då han/hon har en möjlighet att hela tiden uppmuntra de anställda till att dela med sig av sin kompetens samt att de skall förstå varandra inom gruppen och respektera varandra för den man är. För att uppnå detta har man även något som kallas medarbetarsamtal där ledaren träffar var och en gruppen för att kontrollera hur vederbörande trivs osv. En annan viktig aspekt som lätt glöms bort är just team-building, bl a har man åkt iväg hela gruppen för att lära sig om att respektera varandra för den man är samt hur man på ett effektivt och tillitsfullt sätt arbetar i grupp. 6.2 Fear of Conflict Då det finns flera linjer som jobbar simultant med egentligen samma uppgift, i detta fall att producera vodka, finns ju alltid en viss tävlingsinstinkt. Vilken grupp har tillverkat flest flaskor idag etc. På detta sätt blir det en naturlig tävlingsinstinkt vilket kan ge upphov till konstruktiva konflikter för att kanske uppnå bättre resultat än en annan grupp gjort. Ledarna visar också kontinuerligt hur gruppen ligger till, om arbetet går bra osv. Genom att hela tiden hålla möten, c:a 1 gång i månaden, blir även detta ett bollplank då idéer samt tankar luftas. Det är även viktigt att ledaren avvaktar vid konflikter och ser om de kan lösas av arbetarna själva innan man går in och bestämmer vad som skall göras. Genom att hela tiden uppmana till konstruktiva konflikter d v s fråga under ett möte om det är något som behöver förändras för att efter viss betänketid låta alla berörda ta upp sina idéer för att fatta ett beslut om vad som skall göras. Man kan ju även tillägga att det som ledare är väldigt svårt att urskilja om det är en destruktiv eller konstruktiv konflikt. Detta leder ju då till att man initiellt ger gruppen chansen att lösa problemet internt då det oftast är en ytterst uppblossad konflikt då den når upp på ledarnivå. Skulle problem uppstå i gruppen avvaktar man först för att se om gruppen själv hittar en lösning. Skulle detta inte gå börjar man med ett möte mellan de berörda personerna där båda inför varandra för ge sin version av det inträffade för att slutligen hitta en lösning. Skulle inte detta heller fungera kallar man till möte med hela gruppen för att där försöka lösa problemet. Skulle inte detta heller fungera finns ju alltid möjligheten till omförflyttning inom företaget. 6.3 Lack of Commitment Problemet med industrin är att allt går enligt ett löpande band. På detta sätt hänger inte produktionens fortlöpande på en specifik person varefter det kan vara svårt att urskilja vilka som verkligen vill att planen skall följas. Dessa problem minimeras dock väsentligt då arbetarna hela tiden har en produktionsplan som sträcker sig en vecka i taget. Ett annat problem med denna funktionsstörning är att flera som arbetar där kanske egentligen inte vill vara där utan enbart stannar sina åtta timmar varje dag för att sedan gå hem och inte bry sig mer om arbetet. -18-

Det finns dock en drivkraft som minimerar risken för att de inte alltid följer planen skall bli mer motiverade, nämligen en bonus. Denna bonus är uppbyggd på så sätt att om gruppen arbetar väldigt bra tillsammans under en viss tid beräknas det ut en bonus som läggs på grundlönen. På detta sätt blir det lättare för arbetarna att få drivkraft till att snabbt lösa problem som uppstår då det finns finansiell vinst i det. Ytterligare en aspekt som måste tas upp är det att flera av de som arbetar gärna stannar kvar efter arbetstid för att förbereda eller lösa problem så att dagens produktion skall gå lättare. Genom att ha personer som gör på detta sätt blir ju även det en drivkraft för de andra i gruppen då de känner att det p g a vissa personer blir mer bonus. Jag tror iaf att detta är en drivkraft för att bli den som jobbar för kollektivet. 6.4 Avoidance of Accountability Oftast är detta ett problem som ej når upp till ledarnivå. Skulle det dock göra det så måste man som ledare måste gå ner till arbetarna och påpeka att här är det faktiskt något som blivit helt fel. Detta slutar i vissa fall med att en person säger att det var han/hon. Dock händer det vid flertalet tillfälle att flera medarbetare tar på sig ansvaret, det är då viktigt för ledaren att berätta om konsekvenserna som detta leder till. För att komma tillrätta med detta är ett kollektivt samtal där man klargör vad som hänt, konsekvenserna samt uppmuntrar dem till att det är bättre att ta på sig ansvaret själv bra. När detta händer är det även viktigt att ge positiv kritik till vederbörande som gjort det för att han/hon inte på något sätt skall känna sig utanför gruppen utan enbart är medveten om att det som hände var fel. 6.5 Inattention to Result Då man har, som tidigare beskrivit, tekniksamordnare vilka skall agera som bollplank då man har problem försvinner även lite av funktionsstörningen genom att dess uppgift är att se till det kollektivt bästa. Han/hon agerar ju även som en liten ledare varefter det skulle kunna vara lite revirpinkande att det här kan jag och vill absolut inte berätta för de andra. För att kunna komma tillrätta med detta finns det egentligen bara en sak att göra och det är att som ledare hela tiden uppmuntra kollektivet och inte uppmuntra enskilda personer för saker de gjort som är bra. -19-

7. Hur kan XP dra nytta av industrins erfarenheter? En viktig aspekt som jag direkt tycker att man borde inkludera i XP [2] metoden är att man tydligare borde introducera en ledare för projektet. Ledaren skulle ha hand om frågor relaterat till teamet t ex problematik med utvecklare eller kundens krav. Borde vara kontaktperson med kunden då jag tror det är lättare för kunden att kunna prata fritt med en ledare än det är med t ex 8 utvecklare som kanske är lite för insugna i programmeringsvärlden. För att sammanfatta vad jag tycker skulle man kunna säga att XP hade behövt introducera practises [2] som enbart riktas mot just ledaren/coachen och hur han/hon skall agera i olika situationer. Man borde introducera medarbetarsamtal som ledaren håller i. På dessa möten skall medlemmarna i teamet en och en berätta för ledaren vad han/hon tycker känns fel, hur man arbetar ihop, problem som uppkommit och andra frågor eller förundringar som han/hon tycker är viktigt. Ledaren skall även ordna aktiviteter vars uppgift skall vara att bygga ihop teamet. T ex skulle man kunna åka iväg alla i teamet tillsammans för att lära sig om hur man arbetar i grupp samt hanterar destruktiva konflikter mellan varandra. Ledaren skall även ha till uppgift att försöka klura ut vilka som fungerar ihop och tvärtemot för att på ett effektivt sätt direkt hitta par som kan programmera tillsammans. Under projektets fortlöpande skall nu ledaren byta par kontinuerligt för att alla skall jobba bra tillsammans vilket i sin tur kommer att leda till att de jobbar bättre med varandra i kommande projekt. Ytterligare en tanke skulle kunna vara introducera ett slags bonussystem vilket skall ytterligare motivera att utvecklarna alltid gör sitt bästa och levererar en komplett produkt till kunden. En aspekt som skulle kunna förtydligas är att jag inte tror att det skulle vara någon speciellt bra idé att introducera en chef i ett XP projekt utan att det hålls på en lite lägre nivå med en ledare som svarar mot en chef. En chef tror jag skulle ha alldeles för lite med implementationen av projektet till skillnad från en ledare som dels deltog med kod till projektet samtidigt som vederbörande driver projektet framåt. -20-

8. Referenser [1] Patrick Lencioni; The five dysfunctions of a team, National Best-Seller, 2002. ISBN: 0-7879-6075-6 [2] chromatic; Extreme Programming Pocket Guide, O Reilly, 2003. ISBN: 0-596-00485-0 [3] Frederik Turner; V&S Absolut Spirit Intervjuad 2006-02-03 [4] Andreas Stenberg; V&S Absolut Spirit Intervjuad 2006-02-03 [5] Coaching av programvaruteam http://www.cs.lth.se/eda270 [6] Laurie A. Williams, Robert R. Kessler; All I Really Need To Know about Pair Programming I Learned in Kindergarten http://collaboration.csc.ncsu.edu/laurie/papers/kindergarten.pdf 2006-02-20-21-