Självorganiserande team och coachens anpassade roll

Självorganiserande team och coachens anpassade roll Författare: Jakub Gorski, D07, (dt07jg8@student.lth.se) Jakob Svemar, D07, (dt07js6@student.lth.se) Kursansvarig för EDA270: Lars Bendix Inlämningsdatum: 04-03-2013

Abstrakt Denna rapport handlar om hur ett mjukvaruutvecklingsteam som använder agila metoder utvecklas, samt hur i takt med denna utveckling de tar på sig nya ansvarsområden. Målet med detta är att uppnå ett så kallat självorganiserande team som tar hand om allt från story-skattning till team-organisation. När detta sker kan coachens uppgifter gå över till team-relaterade problem samt att introducera nya metoder för att lösa problem.

Innehåll 1 Introduktion 1 2 Bakgrund 1 3 Kommunikation 1 4 FIRO-modellen 2 5 Inociella roller och ansvar 3 6 Teamets utveckling och coachens roll 4 7 Agila Modellen 4 7.1 Kontinuerlig Integration....................... 5 7.2 Releaser................................ 6 7.3 Iterationer............................... 7 7.4 Release Processen........................... 8 7.5 Strategi................................ 9 7.5.1 UML.............................. 9 7.5.2 Nod-modellen......................... 10 8 Sammanfattning 11 9 Ordlista 11

1 Introduktion Syftet med denna djupstudie som görs i samband med kursen EDA260 där en grupp andraårs studenter skall samarbeta för att skapa ett tidshanteringsprogram för så kallade Enduro lopp. Djupstudiens fokus kommer vara att få teamet att bli självorganiserat. Detta innebär att projektledarrollen coacherna har i början av kursen skall i senare skede tas över av teamet. För att uppnå detta kommer teamet ha en stor del av ansvaret när det kommer till planering och upplägg av projektet. Genom misstag och coaching kommer de förbättra sina metoder och därmed öka sin kompetens inom olika områden. För att uppnå ett välfungerande självorganiserande team kan coachingen sammanfattas i ett par punkter. Situationsanpassat ledarskap. Återkoppling och öppen feedback. Retrospekt - "Vad gjorde vi fel? Vad kan förbättras?" Låta teamet identiera problem, komma på lösningar och slutligen förbättra lösningarna. Resultatet av experimentet kommer behandlas i denna rapport. Ett problem med hur studien är att den genomförs under en väldigt kort tidsperiod. Även om kursen pågår över sju veckor har inte teamet mer eektiv tid tillsammans än lite över en vecka. 2 Bakgrund Genom dokumentation av teamets utveckling i form av de ansvar de tar över, vad de ber om hjälp med och våra egna observationer vill vi undersöka hur coachens roll förändras under projektets gång. Detta vill vi undersöka för att bättre kunna skapa riktlinjer för hur man kan anpassa coachingen och hantera olika skeden i teamets utveckling. 3 Kommunikation Ett självorganiserande team sätter höga krav på medlemmarna. De måste ta eget ansvar, hålla kollegor till ansvar samt konstant utvärdera sitt genomförande. Grunden för detta, och för alla andra team, är kommunikation. I vårt team valde vi därför att lägga stor vikt på att diskutera allt möjligt första mötet och därmed bryta isen på ett sätt som en lång genomgång av projektet av de två coacherna aldrig hade uppnått. Inte förrän man ck en känsla av att alla vågade prata gick vi in på själva projektet. Genomgången blev kort med stor uppmuntran till frågor från teamet, att låta dem driva diskussionen var de tvingade att kommunicera redan från början. För att fortsätta utveckla de sociala banden i gruppen har det organiserats gemensamma luncher och kor. Till skillnad från arbetslivet är tiden teamet spenderar tillsammans relativt begränsad och det gäller att utnyttja så mycket av tiden som möjligt. 1

Målet med all denna kommunikation är att få ett så kallat jelled team, eller på svenska, sammansmält team. Tanken bakom detta är att ett välfungerande team utför ett bra arbete samtidigt som medlemmarna trivs i gruppen vilket bör minska avhopp av olika slag. 4 FIRO-modellen För att få en uppfattning på hur välfungerande teamet är kan man använda sig utav FIRO-modellen[1]. FIRO står för Fundamental Interpersonal Relationship Orientation och är ett redskap för att mäta hur väl ett team fungerar. Figur 1: Illustration av FIRO-modellen. FIRO-modellen beskriver ett team i olika skeden. Dessa är tillhörighetsfasen, rollsökningsfasen och samhörighetsfasen. Den första inträar direkt när ett team skapas, och är i grunden en lära känna fas. När teamet fått kontakt med varandra kommer ett mellanstadium som kallas gemyt, här vågar teamet ta mindre konikter men alla är fortfarande försiktiga runt varandra. Under rollsökningen vågar gruppen ta konikt samtidigt som de utforskar varandras roller, inociella regler kan också skapas i detta skede. När alla roller är fastställda kommer en period av idyll. Slutligen når teamet en fas där de alla vet sin och sina medarbetares plats, de vågar ta viktiga diskussioner och är inte rädda för att skapa konikter, gruppen litar på varandra. Det nns i princip två vägar för att nå detta, en lång väg som är fylld av konikt och kanske även maktkamp för ett team som ska bli självorganiserat. Den korta vägen är istället fylld av dialog, detta ställer höga krav på gruppen och att medlemmarna framförallt visar tillit till resten av teamet i ett tidigt skede. 2

5 Inociella roller och ansvar För att ett team skall bli självständigt måste gruppen komma överens om vilka roller de har. Roller kan skifta runt men det är viktigt att maktkamper inte uppstår och att gruppmedlemmar anpassar sig för att fylla alla behov. Enligt Belbin[1] nns det nio olika roller i ett team: Coordinator Plant Resource investigator Monitor evaluator Completer Shaper Specialist Teamworker Implementer Som åskådare är dessa roller olika svåra att identiera. De tar även tid att få korrekt uppfattning, och roller kan behöva omvärderas då och då. Coordinator:n är det närmsta man kommer en ledare och antagligen en av de lättaste att identiera. Genom att tidigt överlåta ansvar över olika områden som release, tracking eller liknande till teamet kommer typiska ledare ta ett steg framåt och erbjuda sig att sköta det. Som coach är det viktigt att ta vara på dessa erbjudanden och låta ledaren prova sig fram. Efterhand kommer vissa av dessa uppgifter överlåtas till andra medlemmar i teamet. Nästa roll som bör uppenbara sig är plant och resource investigator. Personer som platsar in i dessa roller kommer att komma med mycket förslag, detta kan röra sociala händelser eller förslag på nya redskap för att förbättra arbetet. Som coach kan det vara värt att lyssna på dessa och ta vara på deras förfrågningar. Om gruppen känner att deras önskemål hörs och uppfylls ökar engagemanget. Resterande typer kommer vara svårare att upptäcka och lättare att misstolka. Till exempel monitor evaluatorn kan misstolkas som blyg till en början med dämpad entusiasm. De kommer förespråka noggrannhet och vara en voice of reason. Som coach är det viktigt att uppmuntra dessa personer till diskussion samt att få resten av gruppen att lyssna. Completern kommer liknande monitor evaluatorn verka mindre entusiastisk än de andra i teamet men kommer i gengäld jobba för att se till att arbetet verkligen blir klart och att alla buggar xade. En passande uppgift för dessa typer kan vara tracker-ansvarig att se till att stories blir helt klara och att det inte slarvas. Shapern är en problemlösare som eggar på teamet. Detta kan dock göras på ett intensivt sätt och det är viktigt att inte låta det bli en dålig stämning i teamet på grund av detta. Specialist kan översättas till expert, det är denna person som folk i teamet går till när de behöver hjälp med inom ett speciellt område. Som coach bör detta 3

uppmuntras, när teammedlemmar ber om hjälp sprids kunskap och hela teamet blir bättre. Det kan dock vara viktigt att se till att experten får jobba med andra områden än sitt eget för att uppmuntra spridning av kunskap i teamet. Teamworkern håller samman teamet, är bra på att lyssna och ser till att trivseln inom gruppen uppehålls. Det nns inte mycket att säga om denna typ mer än att teamet tjänar på att ha dem. Slutligen nns implementern. Denna person är den typiska utvecklaren. Uppgiften löses eektivt precis som den alltid har gjorts. Många av dessa roller går bra att para ihop och det är inte ovanligt att man kan placera en person inom era av dessa roller. 6 Teamets utveckling och coachens roll I kursen Programvaruutveckling i grupp skall ett team utveckla ett program som skapar tids- och resultatlistor för så kallade enduro-lopp. Detta ska de göra genom att följa extreme Programmings metodiker [2]. Coachernas uppgift är att hjälpa teamet med de olika delarna av XP samt att till viss del agera som projektledare. Efterhand som teamet lär känna varandra och kommer in i arbetsmetoderna XP dikterar börjar de även ta för sig mer av olika ansvar. En av de första teamroller som uppenbarar sig är Coordinatorn. Denna är en typisk ledarroll och uppenbarade sig redan under andra iterationen i form av ansvarstagande. Även drivande roller som plant, resource investigator börjar uppenbara sig. Ett problem som relaterar till kommunikation och teamroller uppenbaras dock. Tiden som kursen genomförs under är relativt kort, sju veckor, men den eektiva tiden är knappt över en vecka. Detta innebär att FIRO-modellen blir svår att använda och att teamet kan benna sig i era olika delar. Som det nämndes har ett par drivande roller uppenbarats tidigt men det nns en risk att mer passiva roller inte identierats när kursen är klar. Det största beviset på att teamet är på god väg att bli ett så kallat jelled team är dock hur de löser problem. De vågar fråga efter hjälp och är inte rädda för att samla alla för att diskutera ett eventuellt problem. Coachens ansvar genom projektet har därför varit enkelt att identiera. Från början var det väldigt likt en projektledares jobb. Mycket handlade om att struktuera arbetet och se till att det gjordes. Med introduktionen av trackerhantering började teamet själva ta ansvar för vad som skulle göras, vad som gjordes och hur det redovisades. Coachernas fokus kunde omdirigeras till att hjälpa teamet fokusera på olika agila metoder. För att uppnå huvudmålet med coaching, att låta de coachade upptäcka lösningen själva, har vi låtit teamet begå mindre misstag och därefter föreslagit viktiga element i en lösning. Därefter har teamet fått diskutera och utforma sin egen lösning. Många problem har lösts med spikes och därefter en utvärdering. 7 Agila Modellen Under kursens 6 iterationer utvecklar teamet en agil modell som anpassas och utvecklas efter behov. Coacherna upplyser teamet angående existerande XP 4

principer[3], varpå de strävar efter att teamet upprätthåller dessa. Mätvärdena i detta moment är teamets tempo och tillämpningsgrad av XP principerna, samt eventuell formulering av nya principer som bieekt av teamets utveckling. Resultatet skall kartlägga en generell utveckling av teamets agila modell. Eftersom teamets nya agila modell inte behöver vara en XP-modell generaliseras den i de återkopplingar[6] som nns i samtliga agila modeller enligt gur 2. Figuren utgör även grunden för rubrikerna och uppdelningen av detta avsnitt. Figur 2: En generell illustration av hur en agil utvecklingsmodell ser ut.[5] 7.1 Kontinuerlig Integration Under den första iterationen inledde coacherna kodbasen med en förbestämd arkitektur som syns i Figur 3. Teamet valde att fokusera mer på testdriven utveckling och samarbete än integration vilket orsakade att repository:t blev mindre rent (syns i Figur 4). Under tiden teamet gjorde sig bekant med koden, spenderade coacherna Iteration 1 på teambuilding och spridning av god stämning i gruppen. Efter den första releasen under iteration 2 insåg teamet att manualen bör integreras kontinuerligt. Det är även nämnvärt att teamet inledningsvis insåg 5

Figur 3: UML av Iteration 0. Figur 4: UML av Iteration 1 efter 4 timmar. vikten av att integrera manualen till releasen bättre än integrering av koden de arbetade med. Följande förändrades till iteration 3 där spikes, inom arkitektur och refaktorisering, genomfördes. Även om eekten inte blev ett renare repository, så uppnådde teamet bättre kodintegration. Denna observeration baseras på en minskning i mängden klasser i projektet, vilket resulterade i kodstrukturen som illustreras av gur 5. Under Iterationerna 2-3 visade teamet ett ökande behov av att testa koden. Anledningen till detta var en bristfällig mängd test som gav dålig testtäckning. Följande orsakade att teamet tog initiativet att ta på sig en spike och skapa en TDD metodik som alla i teamet kommer ha tillgång till på trac-wikin. Genom en ytterligare spike-uppgift som strukturerade upp trac-wikin, förvandlades wikin sakta till ett allmänt medium där teamet kunde förmedla sina bidrag. 7.2 Releaser Coacherna valde att under iteration 1 inte berätta för teamet att iteration 2 kommer innebära release. Under andra planneringsmötet hanterades releasen genom att avlägga en spike för att underlätta planneringen. Eftersom teamet var i behov av bättre tidsplanering i detta skede coachades dem till ett sätt att visualisera kostnaden av kundens beställning. Resultatet blev att en release story skrevs. Detta orsakade att teamet hade bättre uppsikt på tidsplaneringen inför releasen och kunden och teamet kunde bättre plannera iterationen. 6

Figur 5: UML av Iteration 3 efter 8 timmar. Enduro back-end till vänster, samt GUI till höger. Samtliga testklasser är segregerade i en spalt längst till höger. Teamets förhoppning var att samtliga kundbeställda stories skulle bli implementerade enligt tidsplan. Planen visade sig däremot vara för optimistisk. Dock så löste teamet detta genom att kontakta kunden, varpå de negotierade fram en kompromiss som reviderade planen. Eftersom teamet kontaktade kunden, vilket gav upphov till ärlig dialog, blev både teamet och kunden nöjda med releasen. Resterande stories som föll bort på grund av den reviderade planen skattades om till nästa iteration. Nästkommande Iteration 3 lärde sig teamet att förbereda releasen tidigt. För att kunna spara tid skall teamet kunna upptäcka problem med releasen i god tid. Lösningen blev att en viss mängd ansvar för releasen överfördes till en team-medlem. Eftersom ansvaret (Empower) för releasen förmedlades till en team-medlem kunde resten av teamet fokusera bättre. Detta på grund av att mängden stress i teamet minskade märkbart. Personen som hade ansvaret för releasen automatiserade även dess process, vilket tyder på att ökat ansvar även ökar produktivitet. Under de sista två iterationerna motverkade teamet samtliga stressfaktorer i samband med release genom att förbereda en inledande release tidigt i början av iterationen. Efter hand som större ändringar sker i koden, eller när en story blir färdig, så genererar teamet en ytterligare release. Följande repeteras tills teamet inser att det inte lönar sig att göra er större ändringar i koden inför release 7.3 Iterationer Coacherna insåg att kommer behöva kunna organisera sin tid under iterationerna. Därför delades det ut en spike på att införa en planeringsmetod som heter Kanban fram till iteration 2. Kanban modellen anpassades efter teamets behov, vilket gav upphov till följande modell: T odo U tveckling Acceptanstest Klar KlarKlar 7

Modellen vidareutvecklades till ytterligare en Kanban modell under Iteration 3 som passade teamet bättre: Stories Analys Ongoing Done U tveckling Ongoing Done Acceptanstest KlarKlar Ongoing Done Kanban -upplägget förändrades då teamet ansåg att stegen under Analys var för många. Därför såg den slutgiltiga Kanban -modellen Även detta segmentet ut enligt: Stories Analys U tveckling Ongoing Done Acceptanstest Ongoing Done KlarKlar Efter morgonmötet under iteration 4 insåg teamet ett behov att kunna se hur stories är prioriterade. På grund av detta ritades en liten nod-modell upp i nedre hörnan av Kanban brädet för, vilket gav teamet en omedelbar översikt på tidsplanen. Denna modellen är framtagen av coacherna och har inte inspirerats av någon litteratur inom EDA270 kursen och kommer beskrivas i avsnitt 6. Figur 6: Nod-modell för visualisering av story beroenden och deras status. 7.4 Release Processen Release processen har inte utvecklats under iterationernas gång, däremot så har den praktiska tillämpningen av release processen blivit bättre. Under planeringsmötet före Iteration 2 coachades teamet till att visa kunden kostnaden för en release. Resultatet blev en release-story som presenterades för kunden. Följande 8

story räknade endast med tidsåtgången för sammanställningen av releasen. Följande utvecklades till att en person i teamet ck ansvaret att förbereda releasen tidigt i början av iterationen. Genom att förbereda releasen tidigt kan teamet säkerställa att releasen projektet är tillräckligt stabilt för att kunna sammanställas som en release. Om detta inte är fallet skapas en lista av saker som är återstående att göra (TODO-list), vilket tillåter teamet att att snabbt iterera igenom release storyn en gång till om nödvändigt. Som redan nämnt i slutet av avsnittet 7.2 ck en medlem i teamet ansvar för releasen. Konsekvensen av detta var att denna person även utvecklade en automatiserad release-process för att underlätta release-proceduren. Vidareutvecklingen av detta automatiserade verktyg, som var skrivet i ANT, distribuerades över resterande team-medlemmar desto närmare teamet närmade sig iteration 6. Följande bekräftar att minst två personer i teamet har införstått med hur ANT skript fungerar. 7.5 Strategi Coachernas mening med studien var att få teamet att utveckla ett behov för skräddarsydda lösningar anpassade efter teamet, vilket även gäller för detta avsnitt. Under den första iterationen användes identiska metoder för presentation av strategi som teamet sett under planeringsmötet, vilket i detta fallet motsvarar nod-modellen som ses i gur 6. Det vill säga en nod-modell av stories, samt deras beroenden, tidsskattning, status och tidsplan för nästa iteration visualiserat i ett diagram. Teamet försökte att bruka nod-modellen som ett Kanban-bräde, vilket resulterade i en strukturlös uppsättning av story-lappar vars mening var att förmedla pågående iterationens status. Trots att denna improvisation från teamets sida inte var en särskilt eektiv lösning så tillät coacherna detta experiment för att skapa ett behov av en mer strukturerad översikt, till exempel i form av ett Kanban-bräde. Eftersom nod-modellen inte var särskilt strukturerad, vilket teamet tyckte var problematiskt, valde coacherna att ge lösningsförslag och låta dem bestämma vilken modell de tycker är bäst att använda. Teamet beslutade att ersätta nod-modellen med en Kanban modell under iteration 2, varpå nod-modellen föstes ut helt och hållet i iteration 3. Dock så blev det mycket förvirring för vissa teammedlemmar under dessa iterationer varpå coacherna ritade upp ett förminskat nod-diagram vid sidan av Kanban-brädet på begäran. Följande underlättade teamets arbete och tillät en jämnare övergång i planeringsmetodik. Planeringsmötena präglas dock fortfarande av nod-modellen som har vidareutvecklats och används för att beskriva story beroenden, kostnad, status, samt vad som skall vara med till nästa release. Denna nod-modell är något som coacherna använde sedan början av kursen för att observera ifall teamet vill behålla den, eller ersätta den med någon annan representation. 7.5.1 UML Coacherna valde även att experimentera med hur teamets översiktliga uppfattning av projektet skulle utvecklas ifall de skulle få se ett UML-diagram av sitt arbete för varje iteration. Under iterationerna 1 och 2 genererade coacherna 3 UML diagram per dag vid 0:e, 4:e och 8:e timmen. Under senare itera- 9

tioner genererades uppemot två UML diagram som redovisades för intresserade teammedlemmar under ett informellt möte; helt utan tvång. Teamet ck en glimt i ögat och passion för arbetet då kodbasen ritades med hjälp av UML. Att kunna presentera klassernas visuella ökning i mängd och storlek har en stor inverkan på teamet i de första två iterationerna. Under de senare iterationerna visualiserade diagrammen refaktoriseringar, vilket kan tydligt ses i gur 5. Jämförelsevis visade teamet en självsäker kunskap om koden. Det kunde observeras på planeringsmötena 3-5 där de snabbt och konsekvent erkände missnöje med implementationen av story 9, men samtidigt förlorade ingen stolthet över programmet i sin helhet. Detta kan även uppfattas som att teamet uppnådde en viss ärlighet angående kodbasens tillstånd, samt ett tecken på att teamet har attention to results.[7] 7.5.2 Nod-modellen Detta avsnitt kommer närmare beskriva hur coachernas nod-modell fungerar. En sådan modell kan ses i gur 6. Teckenförklaringen för denna modell är som följande: Varje nod i diagrammet är en story. Streck mellan noder betecknar beroenden. Tecken vid story:n symboliserar skeden i utvecklingen, punkt, en bock och två bockar representerar påbörjad, klar för granskning och helt klar. Tomma noder (punkter) används för att sammanfoga beroenden. Stories som inte har några beroenden är är i en treckad box. Horisontellt streck tvärs över diagrammet betecknar planerad tidåtgång för stories ovanför strecket. I gur 6 ses två nod-diagram. Vänstra illustrerar plan för Enduro, högra för dess GUI. Vanligtvis nns det även ett tredje diagram för releasen. Detta på grund av att ett projekt kan samtidigt följa era spår som har sina egna beroenden. 10

8 Sammanfattning För att uppnå ett självorganiserat team nns där era faktorer som måste fungera. Kanske den viktigaste av alla är att de måste kommunicera. Detta är något som teamet har utvecklat under hela projektet och har öppnat dörrar förbättring inom er områden som bland annat kan ses i gur 2. Efterhand som teamet börjar komma överens blir organisatoriska element viktiga, att ha en välstrukturerad plan där alla vet vad de ska göra blir en uppenbar askhals i ett tidigt skede. Detta följs av teamets utforskande av teamroller, att hitta sin plats och därmed uppfylla alla behov ett team kan ha. Samtidigt har den enskilda individens utveckling orsakat teamets utveckling som helhet. Coachernas inverkan på denna utveckling har varit tillämpningen av planeringsverktyg som nod-modellen och Kanban som tillkom efter behov. Ett verktyg som coacherna experimenterade med var UML diagrammen som presenterades för teamet efter intresse. Syftet med dessa redskap var att ge teamet en kontinuerligt uppdaterad uppfattning av projektets fortskridning och gav positiva resultat. På grund av att teamet har en bättre förståelse för utvecklingsprocessen har coachernas roll förändrats. De problemen som coacherna löst har under iterationernas gång skiftats från projektledningsproblem till utvecklingsorienterade problem. Alltså har rollen förändrats från en projektledning till mer renodlad XP-coaching. Teamets ansvar har ökat med varje iteration, vilket även innebär att varje person systematiskt får ett mera specikt ansvarsområde. En biverkning av detta är att det blir enklare att se vilka av Belbins teamroller individerna uppfyller. Detta är ett stort tecken på teamets utveckling, samt en början till att bli ett självorganiserat team. 9 Ordlista Även för en van programmerare kan det tillkomma några nya benämningar när man inför agila metoder. För att underlätta läsningen nns här några ord som nämns i studien samt en kort beskrivning på vad de innebär. Coach Coachen skall fungera som en XP-expert och hjälpa teamet att tackla de olika problem som uppstår genom projektets gång. Detta görs genom att uppmuntra teamet att prova olika lösningar med stor fokus på att låta dem själva komma fram till lösningar, även om lösningarna inte är de bästa. Projektledare En ledare är till skillnad från coachen någon som bestämmer. I detta projektet fungerar coacher till viss del även som projektledare, dvs styr upp hur projektet genomförs. Målet med ett självorganiserat team är att alla tar över delar av rollen som projektledare och därmed gör positionen överödig. Kanban För att hålla reda på projektets framfart introducerades ett Kanban som en metod för att organisera gruppens arbete. 11

Morgonmöte Ett Scrum inspirerat möte[4] som hålls i början av dagen. Där diskuteras vad som genomförts sedan senaste mötet och vad som skall ske under dagen, eventuella problem kan även tas upp. Mötet skall hållas kort. Standup Meeting Ett kortmöte där alla ställer sig upp och är delaktiga, målet är att diskutera ett problem och genom hela gruppens engagemang komma till en lösning på ett aktuellt problem. Planning Game På planneringsmötet diskuteras veckans iteration, det reekteras över vad som fungerade bra och dåligt, och hur det kan förändras. Vidare tillkommer det nya stories som skall skattas och därefter skapas, med hjälp av kunden, en plan för den kommande iterationen. Planning Poker För att optimera skattningen av olika stories används planningpoker. En grupp diskuterar en story kort och röstar därefter hur svår de tycker uppgiften är. De använder Fibonaccis sekvens som mätstock med bitanken att ju svårare problemet är desto svårare är det att skatta. Varje person lägger en egen röst och gruppen jämför. Om de är överens är det klart, annars diskuteras det igen och gruppen röstar igen. Stories Varje funktion i programmet beskrivs av en story. Teamet diskuterar dessa och genom planning poker kommer de fram till en skattning på hur svår storyn är. Kunden rangordnar därefter storys över hur viktiga och hur kostsamma de är. Spike Mellan varje långlabb nns det fyra timmars spike tid". Denna kan användas till att undersöka stories och annan plannering. Funktionalitet i programmet får aldrig läggas till under denna tiden. Referenser [1] Svedberg, (2003) Gruppsykologi, Om grupper, organisationer och ledarskap, tredje utgåvan., ISBN:9789144041544. [2] O'Reilly, (2003) Chromatic: Extreme programming pocket guide, ISBN:0-596-00485-0. [3] S. Kamran, G. Claudia, Team Development and Pair Programming tasks and challenges of the XP coach, http://cf.agilealliance. org/articles/system/article/file/935/file.pdf, Date accessed 10/12/2012. [4] S. Hamid, (2012) Scrum in under 10 minutes, http://www.youtube.com/ watch?v=xu0llrltyfm, Date accessed 10/12/2012. [5] [Agile software development poster] F. Devon [image online] Available at: http://en.wikipedia.org/wiki/file:agile_software_development_ methodology.svg [Accessed 26 February 2013]. [6] Asklund U., Bendix L.,T.E., (2004, pp.136-137). Software Conguration in Agile Development. Lund, Sweden: Lund Institute of Technology, Computer Science department. 12

[7] Lencioni P., (2002, pp. 8). Book Summary: The Five Dysfunction of a Team. Lund, Sweden: Lund Institute of Technology, Computer Science department. 13