Att effektivt strukturera, utföra och utvärdera spikes

Att effektivt strukturera, utföra och utvärdera spikes Oscar Rydh - psy13ory@student.lu.se, Axel Rosén - mas11ar1@student.lu.se, and Joel Klint - dat13jkl@student.lu.se Lunds Tekniska Högskola

Table of Contents 1 Introduktion.................................................. 3 2 Bakgrund..................................................... 3 2.1 Varför studien utförts...................................... 3 2.2 Om spikes................................................ 4 3 Frågeställning................................................. 4 4 Metod........................................................ 5 4.1 Meningsfulla och relevanta spikes............................ 6 4.2 Presentation av resultat från spikes.......................... 6 4.3 Tydlig definition utav spikes................................ 6 4.4 Wiki..................................................... 7 4.5 Enkäter.................................................. 7 5 Diskussion.................................................... 7 5.1 Har studenterna lärt sig något?............................. 7 5.2 Vad tycker studenterna är en bra spike?...................... 9 5.3 Presentation av spike...................................... 9 5.4 Dokumentation av resultat från spikes....................... 10 5.5 Framtida arbete........................................... 11 6 Sammanfattning............................................... 11

Abstract. I agila utvecklingsprojekt i grupp är det vitalt att ständigt kunna utvecklas inom områden som är svaga och områden som man upptäcker att gruppen är svag inom. I Extreme Programming hanteras detta delvis genom spikes. Det finns därför ett stort värde i att utföra spikes väl för att således ge så stor nytta som möjligt till gruppen. Värdet som en spike ger till en grupp kan variera beroende på ett antal olika punkter. Denna studie kommer fokusera på att undersöka om det går att optimera kunskapen som spikes ger till en utvecklingsgrupp för att sedan mynna ut i framgångsfaktorer för att uppnå denna optimering. 1 Introduktion Att lära sig av varandra, oberoende om det är inom idrott, akademi eller arbete, är viktigt för att kunna utvecklas och prestera så bra som möjligt. Detta gäller självfallet även för programmering och programmering i grupper. Agila utvecklingsmetoder finns det gott om, och i alla är gruppdynamik ett viktigt tema. Denna djupstudie kommer handla om utvecklingsmetoden Extreme Programming. Syftet med djupstudien är att undersöka om det går att optimera kunskapen som spikes ger till ett utvecklingsteam. Målet med djupstudien är att komma fram till framgångsfaktorer för att uppnå detta. Rapporten kommer således innehålla följande avsnitt: Bakgrund innehåller den information som krävs för att kunna följa rapporten på ett bra sätt. Frågeställning förklarar varför studien fokuserar på just detta ämnet samt specificerar detta till en frågeställning. Metod beskriver vilka metodologier vi använt samt hur arbetsflödet sett ut. Diskussion innehåller diskussion kring metod och resultat. Slutsats sammanfattar resultatet samt den diskussion som djupstudien berört. 2 Bakgrund 2.1 Varför studien utförts Denna studie har gjorts som ett fördjupningsarbete i kursen Coaching av programvarutteam (EDA270). Denna kurs utförs i kombination med kursen Programvaruutveckling i grupp - projekt (EDAF45). Upplägget är som sådant att vi studenter i EDA270 är coacher för andraårsstudenterna i EDAF45. De yngre studenterna är ihopsatta i grupper om ca 10 personer och försöker producera ett program för tidtagning av diverse motorcykellopp. Vi som coacher hjälper de yngre studenterna med att koordinera och strukturera arbetet, men hjälper aldrig till med själva utvecklandet. Studenterna i coachingkursen befinner sig i

sitt fjärde eller femte år utav utbildningen. Under projektets gång arbetar teamet enligt Extreme programing (XP) metodiken. Denna metodik har flera olika grundpelare, så som kollektivt kodägandeskap, testdriven utveckling, kund på plats, med mera. Dock så kommer vi fokusera på punkten spike i detta arbete, och kommer därmed inte beskriva hela XP metodiken i detalj. Istället hänvisar vi den XP intresserade läsaren till Extreme Programming Pocket Guide, Team-Based Software Development (Chromatic 2003). 2.2 Om spikes Spike har sitt ursprung i utvecklingsmetodiken Extreme Programing. Shore och Warden definerar en spike som En liten undersökning i ett tekniskt problem (J. Shore 2008). Exempel på detta kan vara djupdykningar i svåra algoritmer eller utökningar av klasser. Dock anser vi, och många andra (exempelvis Don Wells XPs fader (Wells 1999), att denna definition är något snäv. Istället har vi valt att utöka en spike till alla problem som ett team ställs inför som behöver någon form av djupdykning. Exempel på detta kan fortfarande vara tekniskt tunga ämnen, men även saker som: Design och refaktoriseringsförslag, verktygsimplementation så som byggscript och testmetoder samt förslag för bra arbetsprocesser. Därmed ser vi på en spike som en djupdykning i ett godtyckligt problem som teamet har, där resultatet av spiken är ett förslag på hur problemet ska lösas. Notera vikten på att det enda man producerar under en spike är ett förslag på hur problemet ska lösas. Detta betyder att man under spiken inte utför några förändringar i exempelvis kodbasen eller testmetoderna. Anledningen till detta är att man hela tiden vill att teamet ska ha en chans att ställa frågor och hålla sig uppdaterad i hur systemet och dess uppbyggnad ser ut. Därmed är det bättre att låta teammedlemmarna notera sina förslag och upptäckter, och sedan presentera det för resten av teamet. Då kan alla ställa de frågor som krävs för att skapa full förståelse samt så ges en möjlighet att påpeka eventuella brister som kan finnas i de förslag som presenterats. Ytterligare så undviks eventuella mergeproblem och ett kollektivt kodägarskap bibehålls. 3 Frågeställning Vi författare av denna studie har själva tidigare deltagit i projektet som teammedlemmar under vårt andra år vid Lunds Tekniska Högskola. Under tiden som vi utförde projektet så märkte vi att spikes inte utnyttjades till det vi anser vara dess fulla potential. Istället för att bidra med ny kunskap, problemlösning, och avancerade verktyg till teamet så anser vi att de bidrog med ytterst lite. Spikes utfördes, men oftast försvann den nya kunskapen under projektets storm. Nyvunnen kunskap nådde sällan längre än den student som utfört spiken då resten av

teamet inte fick en grundlig presentation om vad som utförts. Dessutom ledde ofta en spike inte till några konkreta förslag på hur problem kunde lösas. Dessa faktorer bidrog till att man utvecklade en känsla för att spikes var något som utfördes för att det är det man ska göra, vilket i slutändan var dåligt utnyttjande av studentens tid. Vi tror att man kan göra detta bättre. Om man börjar med att titta på tidigare studier så är antalet kring spikes och deras användning mycket få. De är så få att den enda studien vi lyckades hitta var en gammal djupstudie inom samma område från ett par tidigare coacher! Författarna av den studien (Hedin och Lam) drog ett par slutsatser som vi har en möjlighet att utnyttja här. För det första så påstår de att de bästa spikesen fås genom ett kommunikationssamarbete mellan teamet och coacherna. Utöver det så ansåg de även att spikes som fokuserar på att bidra till projektet i allmänhet är de som teamet uppskattar mest. Slutligen anser de att varje spike bör resultera i en skriven sammanfattning då det bidrar till att kunskapen sprids bättre i gruppen. (J. Hedin 2015). Vi har även tittat på andra studier som vi anser relevanta för vår studie, som inte fokuserar huvudsakligen på spikes. En av dessa undersöker kunskapsspridning i ett team (S. Lindberg 2014). Med det sagt så ställer vi oss frågan: Hur skapar och utför man en spike sådan att värdet för teamet blir så stort som möjligt? Detta är i grund och botten en påbyggnad på den frågeställning som Hedin och Lam ställde sig i sin studie (J. Hedin 2015). Dock är vårt försök här att underbygga resultat med mer data, samt kombinera några av deras slutsatser med andra teorier så som vikten av uppföljning och tydliga leverabler (C. McChesney 2008). 4 Metod Våra metoder i denna studie har varit dynamiska. Vi bestämde från början några huvudsakliga tekniker som vi skulle använda oss av. Dessa har vi använt och utvecklat under hela studiens gång. Vi har även kommit på nya tekniker under studiens gång och då anammat dessa. Stort fokus har legat kring spikens livscykel. Vi har försökt bryta ner livscykeln till huvudsakliga faser, och för varje fas komma på metoder som bidrar till att proaktivt minimera problemen som kan uppkomma. Vi har identifierat dessa faser i spikens livscykel: 1. Formulering utav spike 2. Genomförande utav spike 3. Nyttjande utav spike

Vi anser inte att någon fas är viktigare än den andra. Alla dessa faser är lika viktiga för att spiken ska bli lyckad. Metoderna som presenteras nedanför menar att stärka en eller flera utav dessa faser. Våra metoder har haft stort fokus kring Lencionis fjärde dysfunktion, Avoidance of accountability (Lencioni 2002). 4.1 Meningsfulla och relevanta spikes Vi har arbetat för att alla spikes alltid ska kännas meningsfulla för teamet. Vi anser att detta hjälper under genomförandet utav spiken då vi anser att relevanta spikes bidrar till att studenten blir mer intresserad utav uppgiften, och därmed ser ett större värde i att utföra den. Det bidrar även till att maximera nyttjandet av spikes, då spiken har en mening och ett värde för teamet i den position det befinner sig i nu. Detta har vi gjort genom att ta fram spikes tillsammans med alla medlemmar i teamet genom öppen kommunikation. Vi som coacher har även kontinuerligt haft ögonen öppna efter svagheter kring teamets arbetsprocess och haft dessa som reserver, ifall övriga i teamet skulle ha brist på idéer till spikes. 4.2 Presentation av resultat från spikes Vi har inlett varje långlabb med en presentation av resultaten från veckans spikes. Detta har vi gjort av flera anledningar. Dels hjälper det mycket kring nyttjandet utav spiken genom att kunskapen sprids från den som utfört spiken till alla gruppens medlemmar. Vi tror även att presentationen bidrar till genomförandet utav spiken. När studenterna vet om att de ska stå på scen och föreläsa om vad de lärt sig, samt att deras kunskap kan bidra till teamet, så är de mycket mer benägna att utföra spiken högkvalitativt. Att kunskapen sprids till resten av teamet, tror vi även hjälper att motivera studenten. Det får den att känna att arbetet den utför är mer värdefullt. 4.3 Tydlig definition utav spikes En metod som vi arbetat hårt med kontinuerligt sedan första iterationen, är att alltid minska missförståndet i kommunikationen kring spikes. Vi har genom hela projektet, arbetat för att alltid ha väldefinierade spikes. Utmed projektet har samtliga spikes definierats enligt följande punkter. Vilka utför spiken? Vilket ämne spiken berör Vad som skall presenteras på långlabben En länk där studenten skall placera resultatet för de som vill läsa mer djupgående. En viktig punkt är punkt 3, som definierar vad som förväntas utav studenten, den definierar en leverabel. Detta ger studenten ett tydligt mål att jobba mot, samt en känsla av att något förväntas utav den, vilket vi tror leder till att den mer sannolikt genomför spiken med hög kvalitet. Den är även väldigt viktig för att undvika Lencionis fjärde dysfunktion, Avoidance of accountability (ibid.).

4.4 Wiki Utmed projektet har vi haft en intern wiki, som samtliga teammedlemmar haft tillgång till. Vi har använt bitbuckets inbyggda wikisystem. Här har vi skött skriftlig kommunikation vad gäller olika delar i projektet. Vi har haft en dedikerad sida för spikes, där vi för varje iteration skrivit ner alla spikes som skall utföras. När spiken är färdig lägger studenten till en länk till en skriftlig redovisning på respektive spike. Samtliga spikes från hela projektet finns på denna sida, sorterade i avsnitt utefter iterationer. Detta har fungerat som en kunskapskälla, och skapat möjligheten för vem som helst, att när som helst läsa in sig på valfri utförd spike. Spikesen berör olika områden vilket inneburit att kunskapskällan blivit väldigt bred. 4.5 Enkäter I slutet av långlabben under iteration 2-6, har vi bett studenterna svara på en enkät som vi tagit fram. Enkäterna har varit anonyma och det dess huvudsyfte har varit är att hjälpa oss identifiera hur studenternas kunskap har förändrats under iterationen baserat på spikesen. Enkäterna har sett liknande ut utmed iterationerna, de har alla följt samma struktur. Hur mycket kunde du om det område din spike behandlar INNAN du gjorde spiken? Hur mycket kunde du om det område din spike behandlar EFTER du gjorde spiken? Hur mycket tid la du ner på din spike? Hur mycket lärde du dig av andras spikes under genomgången imorse? Hur många gånger har du läst på wikin om någon spike? Vilken av spikes lärde du dig mest av? Varför lärde du dig mest av ovanstående spike? Om inget, varför? 5 Diskussion 5.1 Har studenterna lärt sig något? Enkäterna har vi sammanställt och utifrån de resultaten kommer vi nu komma fram till en del slutsatser (se figur 1). Ett tydligt resultat man kan se ifrån enkäterna är hur väl spikesen gav individuell ökning i kunskap. Nästan samtliga spikes gav ökad kunskap för den som utförde spiken. Den blå stapeln representerar hur mycket individen kunde om ämnet innan spiken och den röda stapeln representerar hur mycket den kunde efter. Den lägsta nivån 0 står för ingenting och den högsta nivån 4 står för expert. Att de studerande lärde sig mycket av sina egna spikes beror framförallt på att de la ner i snitt 2,8 timmar per spike, men en bidragande faktor tror vi är de tydliga leverabler vi la upp inför varje spike. Vi skickade även samma enkät

Fig. 1. Högre staplar, mer lärdom till andra team som inte fokuserade lika mycket på spikes som vi gjorde. Vi har gjort en jämförelse mellan hur mycket studenterna lärde sig i våra team och hur mycket studenter i andra team lärde sig. Vi fick fram att studenterna i våra team fick en ökning på ca. 42% och andra team fick en ökning på 50%. Från dessa två resultat ser man att spikes ökar kunskapsnivån hos de som gör spikesen. Dock kan vi inte dra en slutsats om att en uttalad leverabel i spikes ger en ökad kunskapsnivå till den som gör spiken själv. Vi har även gjort jämförelser mellan våra team och andra team på hur mycket studenterna lärde sig om spikes som de andra i gruppen gjorde. På en skala från 0-4 fick våra team ett snitt på 2,35 och de andra teamen fick ett snitt på 2,17. Att våra team fick högre snitt på denna jämförelse kan bero på de utförliga spikeredovisningar som vi hade i början av varje iteration. Precis som (S. Lindberg 2014) så håller vi med om att det krävs välstrukturerade spikes för att studenterna ska lära sig något om spikesen, en del i välstrukturerade spikes kan vara en tydlig redovisningsform. De första veckorna var våra teams inte så bra på dessa redovisningar men när vi styrde upp strukturen på redovisningarna blev redovisningarna bättre och då noterade vi att de andra i teamet lärde sig mer.

5.2 Vad tycker studenterna är en bra spike? Vad anser då studenterna är en bra eller dålig spike? Svaren som gavs där var mycket intressanta. De ansåg att de mest gynnsamma spikesen var de som löste någon form av tekniskt problem, bidrog med ny kunskap eller introducerade någon form av verktyg. Exempel på detta var spikes inom: branching, refaktoriseringsförslag och arkitekturförslag. Spikes som de ansåg var mindre värdefulla och blev minst använda var de som var något mer diffusa och mer nice to have, så som checklistor och diverse manualer. Det intressanta med dessa svaren är att de stämmer mycket väl överens med de slutsatser som Hedin och Lam drog i sin rapport. Som tidigare nämnt så påstod de redan förra året att spikes som just byggde på de ovan nämnda områden var de som bidrog mest till teamet(j. Hedin 2015). Detta betyder att det är tre team som ansett att samma typ av spikes är bra. Detta tyder på att spikes bör vara av en tekniskt bidragande natur, för att teamet ska få ut maximal nytta av de. Att det är just denna typ av spikes som är prominent bland studenterna anser vi stärker vår teori om att spikes bör vara väldefinerade och strukturerade. Anledningen till detta är att tekniska spikes är väldigt enkla att definera, det finns ett tydligt mål och ett tydligt slut. Studenterna vet till exempel att om man får i uppgift att ta fram refaktoriseringsförslag så har man en bild över vad man ska göra, och när man är färdig. 5.3 Presentation av spike En annan del av studien som vi blev något förvånade av, var hur svårt det var att få studenterna att vara engagerade under morgontimmen där spikes presenterades. Oftast så gick ett par upp, presenterade sina resultat, men inga frågor eller diskussioner följde. Vi trodde, och hoppades på, att en stor fokus på spiken skulle frambringa många intressanta diskussioner och att varje student skulle känna någon form av ansvar i det de producerade. Dock så verkar inte detta vara något som studenterna känt själva, då om man ser till resultatet från vår enkät så tycker varje student att de lärt sig relativt mycket av de andras genomgång (se figur 2). Därmed finns det risk att våra tankar kring presentationerna bara är en känsla vi coacher haft, och något som studenterna ej kan relatera till. Varför frågor och liknande uteblivit är lite svårt att analysera. En tanke som vi har är att det är svårt att snabbt sätta sig in i ett nytt område som man inte läst något om, och därmed är det även svårt att ställa frågor. Oavsett så är det bra att studenterna känner att de fick ut något av presentationen.

5.4 Dokumentation av resultat från spikes Som vi nämnt tidigare så har vi för varje spike alltid haft någon form av leverabel som man sedan visar för teamet. För att även sprida kunskapen inom teamet, och ge dem en chans att komma ihåg vad de lärt sig under alla veckor, har vi använt en wiki sida under hela projektet. Där har studenterna skrivit upp sina resultat så att de är lättförsåtliga och tillgängliga för resten av teamet. Under projektets gång har vi sedan bett studenterna att fylla i hur mycket de har använt sig av den information som finns (se figur 3). Här kan man tydligt se att studenterna behöver ha tillgång till den information som andra personer tagit fram. Detta är i grund och botten mycket förståeligt. Eftersom de flesta spikesen handlar om att ta fram problemlösningsförslag, refaktoriseringsförslag, git commandon, osv, så behöver teamet ha en lättillgänglig referens till den kunskap som finns mellan dem. Vi anser att den metod vi använt för att göra detta har fungerat mycket bra. Fig. 2. Ju högre på 0-5 skalan, desto mer anser man sig ha lärt sig Fig. 3. Studenternas svar

5.5 Framtida arbete Det finns en del saker som vi nu i efterhand tänker att vi skulle gjort annorlunda. För att liknande framtida studier inte ska göra samma misstag som vi gjorde tänkte vi prata om detta. Vi märkte att vissa spikes inte utfördes lika bra som vi hoppades på. Om vi skulle utfört studien igen, skulle vi när vi bestämde spikes även formulerat ett problem för varje spike som löses genom att utföra spiken, på så sätt skulle studenterna få ett tydligt mål att nå. Det fanns en känsla från oss coacher att studenterna utförde spikesen för att det var ett obligatoriskt moment i kursen, inte för att de utvecklades av det och blev bättre som team. Förslagsvis skulle man endast välja att ta spikes som studenterna själva kommit fram till, för att på så sätt få dem att själva vilja lära sig om ämnet. Vidare förbättringsmöjligheter finns vid enkätutskicken. Våra egna team följde vi från vecka 2 och framåt med enkäter, medan de andra teamen svarade på enkäten en gång under vecka 4. Med detta menar vi att mätvärden från enkäterna och således jämförelserna kan bli bättre. 6 Sammanfattning Det vi har kommit fram till med denna djupstudie är följande. Spikes är ett verktyg som ger den som utför spiken fördjupad kunskap inom det specificerade området. För att en spike ska ge ett team så mycket värde som möjligt behövs en del punkter uppfyllas; tydlig leverabel, väl genomförda presentationer av resultatet av spiken och dokumentation av spiken som finns lättillgängligt. Det finns en del potentiella problem med spikes, som möjligen härstammar från att vår studie är gjord med studenter. Det fanns en känsla från vår sida att när spike resultat presenterades för teamen var det som att de som lyssnade inte riktigt tog till sig informationen, det blev väldigt lite diskussion. Sammanfattningsvis är spikes något som ger ett team väldigt mycket kunskap, både på individuell plan och som grupp.

References C. McChesney S. Covey, J. Huling (2008). The 4 Disciplines of Execution: Achieving Your Wildly Important Goals. Free Press; 1 edition. Chromatic (2003). Extreme Programming Pocket Guide, Team-Based Software Development. O Reilly Media, Inc, USA. J. Hedin, V. Lam (2015). NyttoMaximering av spikes. J. Shore, S. Warden (2008). The Art of Agile Development. O Reilly. Lencioni, Patrick (2002). The Five Dysfunctions of a Team: A Leadership Fable. Jossey-Bass; 1st edition. S. Lindberg, F. Dib (2014). Kunskapsspridning inom ett XP-team. Wells, Don (1999). Extreme Programing. http://www.extremeprogramming.org/rules/spike.