Reflektion i Agila Projekt Djupstudie Cornelia Jeppsson dat11cje@student.lu.se Alexander Wallin alexander@wallindevelopment.se Abstract Denna djupstudie undersöker hur reflektion ger stöd till utvecklarteam att kunna identifiera och lösa problem samt identifiera metoder för effektivare utveckling, inom ramen för ett akademiskt projekt. Detta kontrasteras mot vedertagen kunskap inom mjukvaruindustrin. Djupstudien tar även upp metoder för reflektion och väger metodernas uppfattade nytta utifrån coachernas samt utvecklarteamets upplevelse inom ramen för projektet. Studien visar att reflektion ger ett tydligt stöd till utvecklarteam, ovana vid agila projekt, att komma tillrätta med agila metoder. Den visar även med stöd av litteratur att behovet fortsätter långt bortom tidsramarna för det akademiska projektet. 1 Introduktion Reflektion och kontinuerliga processförbättringar beskrivs många gånger som en viktig aspekt i det agila manifestet och i synnerhet som värdefullt för extreme Programming, XP [BHN1]. Samtidigt faller reflektion ofta bort när företag prioriterar tid inom agila projekt [THDK]. Reflektion nämns inte explicit i all litteratur om XP [CDC3], men anses vara en väsentlig aspekt av alla agila ramverk [BHN1] med syfte att expediera effektivare förutsättningar för effektiv utveckling genom att finjustera hur teamet arbetar. De uppfattade fördelarna av reflektion till trots är det långt ifrån alla agila projekt som regelbundet använder sig av reflektion [THDK],[DMG1], trots att agila metoder och i synnerhet XP anses ha goda förutsättningar för att ha långsiktiga fördelar för ett team [HT3]. Vid tidigare studier av större XP-projekt framgår flera fördelar för projekt som kontinuerligt använder sig av reflektion; exempel på dessa är möjligheten att identifiera flaskhalsar i projektet, hantera större förändringar av projektet eller identifiera och motverka möjliga källor till konflikt under projektets livstid. De flesta utvecklare som medverkat i dessa studier uppfattade reflektion som något positivt [THDK]. Denna djupstudie undersöker olika metoder för användning av reflektion inom ramen för ett kortare akademiskt projekt, där äldre studenter agerar coacher och stöd för yngre studenter genom att försöka förbättra deras inblick i agila metoder och utöka deras förståelse för samarbete. Vi presenterar dels kvalitativa resultat i dagboksform, dels kvantitativa resultat från enkäter som samlats in löpande under projektets livstid. Resultaten kontrasteras mot likvärdiga projekt inom den akademiska världen samt vedertagen praxis inom industrin. Bakgrund Då XP och reflektion är de aspekter som ligger till grund för vår djupstudie kommer vi här att förklara vad dessa delar innebär..1 extreme Programming extreme Programming (XP) är ett agilt ramverk för programvaruutveckling som propagerar för korta releaser där man tar god praxis inom programvaruutveckling och gruppdynamik till extrema nivåer [CDC3].. Reflektion för processförbättringar Exakt när ett team bör reflektera är beroende på reflektionens syfte; exempelvis kan man reflektera innan en projektiteration för att identifiera framtida problem, under en projektiteration för att finjustera hur teamet arbetar eller efter en projektiteration för att reflektera över vad som hänt [DMG1]..3 Reflektion för kompetensutveckling Reflektion är en vedertagen agil praktik som traditionellt används av utvecklarteam för att göra processförbättringar, samtidigt är det varje utvecklarteams ansvarar att fördela tid för kompetenshöjning inom teamet [CDC3]. All reflektion behöver inte vara teameller processinriktad, då reflektion även kan användas för att stärka individuell programmeringskompetens genom att utmana och utveckla förutsättningarna för hur problem angrips. Exempelvis kan detta ge uttryck i så kallade code retreats, där mindre grupper utvecklare skriver samma applikation flera gånger med olika begränsningar varefter de reflekterar över kodens utformning samt skillnader och likheter mellan lösningsmetoderna. Målsättningen är då att iden-
tifiera för- och nackdelar med designval i större projekt [PMSL1]. Agila projekt använder korta iteration med fokuserat arbete som ger goda förutsättningar för reflektion över den enskilde utvecklarens egna arbete. Reflektion är en väsentlig del av Kolbs Learning Cycle som knyter ihop insamlade upplevelser till erfarenheter och kunskap [KK5].. REALM Då projektets syfte, både för coacher och utvecklare, är att lära sig snarare än att fokusera på produktutveckling är The Reflective Agile Learning Model, REALM, ett lämpligt ramverk att utgå från [BHN1] då detta är en modell som använder reflektion som nyckel till kontinuerlig kompetensutveckling i agila projekt. Processen som beskrivs av REALM-modellen är väldigt lik den vedertagna arbetsmodell som presenterats för pvg-projekt, men uppmärksammar tydligare varför reflektion är ett nödvändigt moment i lyckade agila projekt. Modellen talar inte bara om hur processen kan se ut, men också vilket värde varje moment av reflektion kan ge ett team. REALM-modellen innebär att under varje iteration estimerar teamet mål med projektet som kunden därefter väljer utifrån. Under iterationen arbetar teamet med dagliga stand-up möten och spikes. När iterationens stories är klara acceptanstestar kunden produkten, varefter teamet reflekterar tillsammans över iterationen. REALM uppmärksammar att reflektion i agila projekt antar flera skepnader; reflectionin-action och reflection-on-action, det vill säga att en utvecklare bör reflektera över sitt eget agerande och sin egen kod för att kunna förbättra sig själv, men teamet behöver också reflektera kollektivt för att de ska kunna arbeta bättre tillsammans. Med utgång från REALM strävar vi mot att i vårt projekt få med så mycket som möjligt av både reflection-in-action och reflectionon-action. Vi kommer att ha dessa som utgångspunkt när vi tar fram olika sätt att reflektera under och innan planeringsmötena. 3 Forskningsförutsättningar Vi är två studenter som agerar coacher för ett team bestående av 1 yngre studenter, vilka har rollen som utvecklare. Detta sker inom ramen för kurserna Coachning av programvaruteam samt Programvaruutveckling i grupp, och då kurserna har en symbiotisk relation beskrivs det kollektivt i denna djupstudie som pvg eller projektet. Projektet är tänkt att introducera XP i en praktisk miljö på ett sätt som simulerar verklig produktutveckling, men där fokus ligger på att förstå moment i processen snarare än att uppnå faktiska resultat, vilket är tvärtom mot verklig produktutveckling där produkten är målet och processen metoden. Projektet inleds med ett introduktionsmöte, där målet är att alla ska lära känna varandra och få en bild av vad projektet handlar om. Därefter ses gruppen varje vecka i veckor under två tillfällen; 8 timmar långlabb(även benämnt iteration) varje måndag, där gruppen arbetar tillsammans i en datorsal, och två timmar för planeringsmöte varje onsdag, där vi går igenom vad som komma skall under nästkommande iteration (i överenskommelse med kunden) samt reflekterar över den iteration som nyss varit. Utöver detta arbetar varje person i teamet timmar med spikes som presenteras av coacherna på varje planeringsmöte. Totalt varar projektet under en läsperiod, under vilken teamet alltså genomför iterationer med lika många planeringsmöten och totalt releaser till kund (där releaserna numreras som 1, 1B, och 3). Samtidigt som detta projekt pågår utför flera andra grupper samma moment med samma rollfördelning och likvärdiga tidsbegränsningar, vilket ger tillfälle för oss att göra jämförelser mellan teamen. Varje vecka skickas en enkät ut till alla team, komponerad av alla coacher tillsammans, där data kan samlas in för denna typ av jämförelse. Intervjuer med andra coacher kan också komma att ske löpande under projektets gång. Typer av reflektion Under projektets gång har vi valt ut ett olika sätt för teamet att reflektera på. Vi har introducerat dessa olika typer av reflektion vid olika tillfällen då vi efter magkänsla känt att det varit lämpligt. De olika typerna av reflektion som använts under detta projekt är; Diskussion i grupp - Vi tror att denna typ av diskussion kan gynna problemlösning inom gruppen. Att problem uppbådas i denna typ av reflektion tror vi kan göra att medvetenheten kring problem inom teamet ökar. Individuell åsikt inför grupp - Varje individ får presentera något de tycker var bra, dåligt eller behöver förbättras inför gruppen, där gruppen lyssnar. Vi tror att de som inte tar så stor plats under diskussionen som sker i grupp då kan få chans att säga sin åsikt. Enkätundersökning - Att använda enkäter tror vi kan synliggöra problem som ligger dolda under diskussioner som sker inom gruppen. Det kan finnas åsikter teamet inte vågar ta upp inför gruppen som vi tror kan få möjlighet att synliggöras i enkäter. Samtliga enkäter som används under projektets gång är anonyma för resten av teamet. Hemliga lådan - En låda där man får lägga anonyma lappar i under en pågående iteration. Vi tror att man kan fånga mer spontana tankar som uppstår under labben jämfört med att tänka tillbaka i efterhand. Det som samlas in i hemliga lådan under iterationen tas sedan upp på nästkommande planeringsmöte.
5 Användning av reflektion under möten I detta avsnitt presenterar vi dels hur vi valt att använda våra valda typer av reflektion inför varje planeringsmöte, dels presenterar vi resultatet och diskussion kring detta. 5.1 Introduktionsmöte Inför detta möte planerade vi att teamet skulle få springa en simulerad Endurotävlingdär en person fick vara registrerare av tider och två personer fick ha hand om en resultatlista, resten av oss skulle springa eller gå fram och tillbaka i korridoren. Vi tänkte att detta skulle hjälpa teamet att bilda sig en uppfattning om vilka problem som kan uppstå i en sådan situation och även för att de skulle få en klarare bild av vad de skulle jobba med. Det visade sig under mötet att den simulerade Endurotävlingen skapade en glad och avslappnad stämning i gruppen och att det även genererade en intressant diskussion efteråt. Det var många i teamet som inte hade en aning om vad projektet skulle innebära över huvud taget vilket vi kunde reda ut genom att de tillsammans, genom diskussion och lite av vår hjälp, fick ta fram en tankekarta över de delar som kunde tänkas ingå i Enduro-projektet. Teamet fick också reflektera över kunskaper de tagit med sig från tidigare kurser då vi bad dem tala om vilka designmönster de kunde komma ihåg. Resultatet blev en lång lista med designmönster som fick syftet att vara en tankeställare till det kommande första planeringsmötet. I slutet av introduktionsmötet, då vi gick igenom teamets förväntningar som en kort reflektion efter att ha gjort dagens aktiviteter och teamet svarade överlag att de kände sig mer säkra på vad projektet skulle innebära och verkade även mycket peppade inför att påbörja processen. 5. Planeringsmöte 1 På detta möte hölls ingen reflektion då vi inte gått igenom någon första iteration än. Istället fokuserades detta möte på att teamet skulle lära sig att estimera och planera stories, vi delade ut spikes och teamet fick träffa kunden för första gången. 5.3 Planeringsmöte Efter vår första iteration tillsammans beslutade vi oss för att använda oss utav två typer av reflektion för att ha något att jämföra med. Vi började med diskussion i helgrupp, och avslutade med en individuell reflektion där alla fick presentera en sammanfattad tanke om första iterationen. Reflektionen i grupp gav en bra diskussion där vi fick fram tankar om vad som kändes konstigt och hur det kunde göras annorlunda i framtida iterationer. När vi sedan använde den individuella reflektionen var det några få tankar som inte dykt upp under diskussionen i grupp, men de flesta åsikter hade redan tagits upp i gruppreflektionen. Vi tror att den främsta anledningen till att åsikter till stor del återupprepades under den individuella reflektionen var att plötsligt var all fokus på personen som skulle tala och därför blev de lite nervösa över att säga något de andra kanske inte höll med om. Vi beslutade oss för att testa denna metod (individuell reflektion) igen fast denna gång innan själva gruppreflektionen för att undersöka om det fanns några kvantitativa skillnader, se planeringsmöte 3. 5. Planeringsmöte 3 Inför detta planeringsmöte valde vi att ge ut en enkät till teamet att fylla i efter iteration. Där ställde vi frågor om hur de själva upplevde olika aspekter av projektet med hopp om att kunna gräva lite djupare i olika åsikter än tidigare. Detta följde vi sedan upp på planeringsmötet med en gemensam reflektion där vi senare jämförde resultatet från enkäten med de åsikter som togs upp under mötet. Under våra två första planeringsmöten estimerade vi först alla stories, varefter kunden fick välja de stories denne var intresserad av, vilket blev ganska tidskonsumerande. Då vi upptäckte att detta blev något teamet reflekterade negativt kring valde vi under planeringsmöte 3 att ändra processen så att kunden först fick välja de stories denne var intresserad av varefter teamet sedan estimerade enbart dessa stories. Detta sparade en del tid vilket gjorde teamet lite gladare, men också fick vi hade mer tid över för reflektion. Detta påvisade också att reflektion här varit ett viktigt verktyg för att kunna göra effektiviseringar i processen. Något som togs upp på mötet var bland annat att planeringsmötena kunde effektiviseras ytterligare om vi i framtiden estimerade i helgrupp istället för i två grupper, något vi kunde ta med oss. När vi gick igenom resultatet från enkäten upptäckte vi också några bra idéer som inte dök upp under gruppreflektionen på planeringsmötet, vilket indikerar att enkäten var nödvändig för att få ut värdefull information gentemot enbart gruppdiskussionen, och att enkät i samband med diskussion i grupp hittills varit en bra kombination för att få ut största möjliga mängd information ur teamet. 5.5 Planeringsmöte Då resultatet av enkäten visade sig vara positivt, valde vi att fortsätta med denna form av reflektion även inför detta och kommande planeringsmöten. Vi planerade inför detta möte även att försöka göra estimeringen av stories i helgrupp (efter att teamet önskat detta vid reflektion) och vi hoppades att detta skulle kunna ge oss lite mer tid över för reflektion inom gruppen. På detta planeringsmöte visade det sig att kunden inte hade önskemål om att få några nya stories tidsestimerade utan istället valdes några av våra redan tidsestimerade stories direkt. Detta innebar att vi fick större delen av mötet till att ägna oss åt reflektion, vilket visade sig ge mycket mer än tidigare då tiden
varit begränsat. Under tidigare gruppreflektioner, vilka tagit upp emot en halvtimme, har vi varit väldigt tidsbegränsade och då endast fått fram runt tre till fem punkter på diskussionen. Då vi inte var begränsade under detta möte kom det upp en väldigt lång lista samt många idéer och förbättringsförslag dök upp, vilka vi kunde utveckla så att de var genomtänkta och teamet verkade vara nöjda och taggade på att prova det vi kommit fram till på nästa iteration. 5. Planeringsmöte 5 Då det inte blev någon estimering under planeringsmöte planerade vi att prova göra tidsestimeringen i grupp på detta planeringsmöte istället. Vi hade en enkät där vi la till frågor om vad vi coacher kan göra bättre enligt teamet, för att vi skulle kunna få möjlighet att ta reda på om det är något vi kan förbättra. Två andra frågor som lades till i enkäten handlade om hur varje individ känt sig under långlabben med de programmeringspartners de satt med. Vi undersökte om personen kände sig respektfullt bemött eller om man blivit bemött med dålig attityd. På samma sätt handlade nästa fråga om de själva ansåg att de bemött andra respektfullt och med en god attityd. Vår baktanke bakom detta var att öka medvetenheten i teamet, att få dem att reflektera över sitt eget beteende inom gruppen. Under detta planeringsmöte valde kunden ut två stories som teamet fick estimera i helgrupp. Det fungerade ganska bra, men det kändes också som att gruppen tog ett ganska hastigt beslut. De var inte helt ense om sin röstning och majoriteten fick bestämma, och det blev inte lika djupgående diskussioner. Denna form av estimering i helgrupp hade nog varit bättre att ha i början av projektet då många stories behövde estimeras på kort tid och därför kunde inte lika väl genomtänkt estimering göras, men då endast två stories skulle estimeras denna gång hade nog estimering i två grupper varit bättre med tanke på att vi hade gott om tid över. Vi fick större delen av mötet över till reflektion, att noga gå igenom kommande aktiviteter, dela ut spikes i lugn och ro samt ta en paus då vi skrattade och skojade vilket var skönt då tidigare planeringsmöten ofta varit stressiga med mycket att göra. Då det blev väldigt avslappnad stämning kunde fler idéer och tankar dyka upp och pratas om i lugn och ro. 5.7 Planeringsmöte Vi coacher valde, för att få in en bredd av typer att reflektion som används, att på iteration 5 ta med en så kallad hemlig låda där teamet under iterationen skulle få lägga anonyma lappar med tankar som dykt upp under iterationen - exempelvis saker som känns frustrerande, förvånande, bra, dåligt, lustigt och så vidare - för att vi sedan skulle kunna ta upp lapparna på det sista planeringsmötet och se vad vi kunde komma fram till för diskussioner, idéer och lösningar för att göra den sista iterationen så bra som möjligt. Hemliga lådan visade sig vara något som uppskattades både stämningsmässigt och processförbättringsmässigt under mötet - många lappar var kanske inte något som gav något resultat i att processen kunde förbättras, som till exempel fikan var god eller cheesecaken var rinnig ; dessa kommentarer var däremot något som gjorde att stämningen lyftes i gruppen. Andra lappar var mer givande - de handlade om några uppenbara problem som uppstått på iterationen och som behövde förbättras till nästa gång - exempelvis teamet behövder vara mer lyhört och fokuserat vid stå upp möten. Hemliga lådan är däremot meningslös om man inte kombinerar den med en gruppdiskussion - det blir knappast meningsfullt att endast läsa upp åsikter utan att gruppen får ge ett gemensamt lösningsförslag eller tycke. Hemliga lådan kan således fungera som ett kul komplement till gruppdiskussion och enkäter, där hemliga lådan fungerar som pågående reflektion då det händer, enkäter bringar eftertanke och gruppdiskussionen sammanfattar och försöker att lösa det som uppbådats. Diskussion I denna del av djupstudien diskuterar vi kring de resultat vi fått fram under projektets gång, både personliga erfarenheter och kvantitativa resultat ur enkäter..1 Avslutande enkätundersökning Nedan följer histogram från frågor ställda till utvecklarteamet som sista moment innan den sista reflektionen för att utvärdera hur reflektion mottagits som moment under den löpande verksamheten. Frågorna som ställdes är en delmängd av frågor som ställts vid en tidigare utvärdering i en tidigare publicerad artikel om reflektion inom mjukvaruprojekt i arbetslivet [THDK]. Termerna för x-axeln är SA, A, I, D och SD som motsvarar en femgradig skala från Strongly Agree, starkt medhåll, till Strongly Disagree, stark invändning och valdes att vara identiska med den tidigare undersökningen.
8 Figur 1: Reflektion är ett effektivt sätt att lösa spänningar och konflikter inom teamet Figur : Jag skulle gärna se att reflektion används i framtida projekt jag medverkar i Figur : När man reflekterar kan alla säga precis vad de tänker, även om ingen annan håller med Figur 5: Jag förstår inte alls vad meningen med reflektion är 8 Figur 3: Reflektion känns relevant för det löpande arbetet Figur : Att ta upp och inom teamet lösa problem på reflektionsmöten är bättre än att låta beslut tas av enbart teamledarna/coacherna
Enkätsvaren indikerar att utvecklarna tydligt förstått och uppskattat reflektion inom ramen för utvecklingsprojektet samt att de uppfattat att reflektion gett positiva effekter för deras fortlöpande utvecklingsarbete. Resultaten från enkätundersökningen är synbart identisk med den tidigare enkätundersökningen, vilket ger en indikation att utvecklare uppskattar reflektion i mjukvaruprojekt oberoende av tidigare erfarenhet av programmering eller agila ramverk och oberoende av huruvida reflektion huvudsakligen använts för att förstärka förståelsen för agila metoder eller för att systematiskt förbättra utvecklarprocessen för utvecklare med större vana med agila ramverk.. Reflektion under projektets gång Gruppdiskussion har visat sig vara en nödvändig del av processen i ett agilt projekt för att få ut största möjliga värde för teamet. Gruppdiskussion gör att problem kan uppenbaras och bearbetas inom teamet, att teamet får en gemensam bild av problemet, och att hela teamet får chans att komma överens om en lösning. En nackdel med att använda enbart denna typ av reflektion är att alla åsikter inte alltid får ta plats och därför rekommenderar vi att använda fler än enbart denna typ av reflektion. Individuell reflektion avgränsar det andra tycker och ger möjlighet till att identifiera ytterligare problem som uppfattas mer på individnivå än i hela gruppen. I vår undersökning har dock denna form av reflektion inte varit särskilt uppskattad av teamet och inte heller gett någon ytterligare input till det som redan tagits upp i gruppreflektionen. Enkätundersökningar ger coacher/teamledare möjlighet att uppmärksamma problem som inte tagits upp under gruppdiskussioner och med hjälp av resultatet från undersökningarna kan diskussionerna styras i rätt riktning vid nästkommande möten. Att använda en hemlig låda är något som i denna undersökning uppskattats av teamet då lapparna innehöll både lättsamma och allvarliga saker teamet behövde fundera på vilket ger en bra avvägning mellan positiv och en mer allvarlig stämning under reflektionen. och om tiden är väldigt begränsad är reflektion i grupp den typ av reflektion som i denna djupstudie påvisats generera snabbast och effektivast resultat i form av förslag på förbättringar och lösningar på problem - med undantag av att alla åsikter inte alltid kommer fram då denna form av reflektion enbart används. Det är därför till klar fördel om man kan kombinera diskussion i grupp med någon form av anonym reflektion - vare sig det är via enkätundersökningar eller om det är via en hemlig låda. Vi rekommenderar inte att enbart använda individuell reflektion inför grupp då denna typ av reflektion inte påvisats ge ett positivt resultat i vår djupstudie. Tvärtom kan det ha negativ påverkan då flera individer känner sig pressade att tala själva inför gruppen. Reflektion kan avslöja om de förändringar som tidigare gjorts haft en positiv eller negativ påverkan på processen, och man kan på så vis med hjälp av den kontinuerliga reflektionsprocessen i små steg se till att man går i rätt riktning för att uppnå målet med projektet. Ett ämne vi anser intressant för framtida studier kring reflektion skulle är att gräva djupare kring om och hur reflektion påverkar coacher/teamledare i deras sätt att styra teamet. 7 Slutsats Trots publicerad tveksamhet om reflektion i agila projekt inom industrin påvisar denna djupstudie med stöd av tidigare publicerade undersökningar att reflektion uppskattas av utvecklare och uppfattas som ett effektivt verktyg för att identifiera och korrigera problem, oavsett om utvecklare arbetar inom industrin eller yngre studenter och oberoende av tidigare erfarenheter av agila ramverk. Reflektionens format och syfte erbjuder ett dynamiskt sätt att identifiera relevanta problem och låta utvecklarteamen själva identifiera optimala lösningar men minimal insatser från ledningsgrupper. Vår rekommendation för användning av reflektion i framtida projekt är att försöka använda sig av så många typer av reflektion som man om möjligt hinner med,
Referenser [BHN1] Jeffry Babb, Rashina Hoda, and Jacob Norbjerg. Embedding reflection and learning into agile software development. IE- EE Software, 31():51 57, 1. [CDC3] Chromatic, Tatiana Apandi Diaz, and Ward Cunningham. Extreme programming : pocket guide. Beijing : O Reilly, 3., 3. [DMG1] [HT3] [KK5] Tore Dyba, Neil Maiden, and Robert Glass. The reflective software engineer: Reflective practice. Software, IEEE, 31():3 3, July 1. O Hazzan and J Tomaykoz. The reflective practitioner perspective in extreme programming. EXTREME PROGRAMMING AND AGILE METHODS - XP/AGILE UNIVERSE 3, 753:51 1, 3. Alice Y. Kolb and David A. Kolb. Learning styles and learning spaces: Enhancing experiential learning in higher education. Academy of Management Learning & Education, ():193 1, 5. [PMSL1] David Parsons, Anuradha Mathrani, Teo Susnjak, and Arno Leist. Coderetreats: Reflective practice and the game of life. Software, IEEE, 31():58, July 1. [THDK] D. Talby, O. Hazzan, Yael Dubinsky, and A. Keren. Reflections on reflection in agile software development. In Agile Conference,, pages 11 pp. 11, July.