Gällande tillförlitlighet måste empirin enligt Jacobsen (2002) uppfylla två krav:
1. Empirin måste vara giltig och relevant (valid)
2. Empirin måste vara tillförlitlighet och trovärdig (reliabel)
Vid appliceringen av giltighet och relevans (validitet) mäts det som önskas mätas. Dessutom måste den undersökning vara tillförlitlig och trovärdig, dvs. den måste kunna litas på. Det som studeras måste vara aktuellt i dagens sam-hälle, vilket är något som uppnåddes då de agila metoderna är något som är omdiskuterat (likaså vattenfallsmodellen). De frågor som diskuterades var av relevans för studien.
De två typerna av giltighet, dvs. intern giltighet och relevans respektive ex-tern giltighet uppnåddes. Detta på grund av att det som ämnades mätas var genomförbart samt att relevansen är giltig i andra situationer än den som finns inom Skandia. Tillförlitligheten och trovärdigheten uppnåddes i viss utsträckning, eftersom resultatet skulle kunna vara annorlunda än det som framkom i denna studie om en kvantitativ metod använts eller om andra per-soner intervjuats i Skandia.
3.6 Etiska överväganden
Etiska överväganden som gjorts i examensarbetet har inneburit att intervju-personernas integritet skyddas. Namn på personer nämns därför inte i studien. Istället står vilka arbetsroller som intervjuats och vad de sagt. Företagskritis-ka IT-projektbenämningar finns inte med i examensarbetet utav sekretesskäl. Detta för att personerna och IT-projekten inte ska kunna anknytas till de data som de bidragit med.
4 Empiri
I kapitlet empiri presenteras de data som framkommit från intervjuerna inom Skandia. De data som finns med har strukturerats upp i vilka arbetsroller som finns, dvs. projektledare, systemutvecklare 1, systemutvecklare 2 och team manager. Underrubrikerna under arbetsrollerna har anpassats till vad de sagt under intervjuerna. Observationen i Skandia finns beskriven i underrubriken Scrum möten i avsnittet om team managerns roll.
4.1 Intervju med projektledare
Det genomfördes fyra intervjuer med projektledaren i Skandia under våren 2011. De handlade om de agila metoderna, vattenfallsmodellen och projekt ”X”.
De agila metoderna
De agila metoderna är enligt projektledaren ”en verktygslåda med många
olika verktyg som kan användas. Det handlar ju hela tiden om att förbättra sig, det är ett starkt inslag i den agila verktygslådan, dvs. det här har de gjort och hur kan det förbättra sig”. Vidare nämner projektledaren att ”alla meto-der behöver skräddarsys eller anpassas till verksamheten i Skandia”, vilket
görs av en metodansvarig.
De agila metoderna syftar till att de anställda ska kunna utvärdera sig själva och förbättra sina arbetssätt. Granskningar sker gällande hur systemet ska se ut, vilka krav som finns och vilka lösningar som är lämpliga.
I Skandia bryts leveranser ner i mindre delar vilket är en fördel för styrgrup-pen och för projektledningen då man får en överblick över IT-projektets framskridande. De agila metoderna kan användas av de som ska kravställa, utveckla och testa. De kommer enligt projektledaren ursprungligen från sy-stemutvecklarna som ville delleverera funktioner istället för att leverera allt på en gång.
Uppdateringar (så kallade iterationer/sprint) genomförs för att få feedback, utvärderingar utförs för förbättring och en demo visas upp för verksamheten, dvs. de som är beställarna av funktionen. Projektledaren på Skandia beskriver de olika fördelarna med de agila metoderna:
• IT-projekt sker i nuet
• Leveranserna ska skapa verksamhetsnytta • Kritiska leveranser sker först
• Det går att kontrollera processerna • Verksamheten är närbeläget
• Det finns en djupare förståelse för vad som sker i genomförandefa-sen
• Det finns samarbete mellan kravställare och IT
Projektledaren sa att dennes arbete blir en mer coachande roll istället för en styrande men denne har fortfarande kvar ansvaret för IT-projektet. Detaljpla-ner görs inte längre åt andra projektmedlemmar för vad som ska ske i genom-förandet. Det är teamet själva som planerar vad det är som ska göras (de är sjävorganiserade team) och projektledaren får inte ändra i deras planeringar.
”Det som de säger att de ska genomföra det ska de göra”. Det handlar
istäl-let om att kunna hantera avvikelser och de rester som kvarstår efter att en leverans gjorts innan nästa sprint påbörjas. Projektledaren menar på att ”en
viss funktion ska levereras inom respektive etapp/sprint för att veta hur mycket som ska levereras”.
Det gäller att teamet är engagerade i IT-projektet för att de ska arbeta så ef-fektivt som möjligt. Detta är svårt eftersom projektdeltagarna ofta arbetar i linjeorganisationen och i IT-projektet. Projektledaren menar därför på att ”man får titta på vilka förutsättningar har det här systemet eller de här
per-sonerna”. Projektledaren sa vid en annan intervju att vid uppstarten av ett
IT-projekt ”kan du inte bara säga att nu ska jag jobba agilt som IT-projektledare
utan du måste titta på varje område, vilka personer som jobbar, prata med dem personerna och fråga om det här arbetssättet skulle fungera hos er”.
Vattenfallsmodellen
Vattenfallsmodellen är enligt projektledaren ett vedertaget sätt i Skandia att utveckla system. När Skandia använder vattenfallsmodellen utförs först ana-lysering och planering, inom vilka projektledaren eller projekttea-met/ledningsteamet bestämmer att ett system ska levereras efter ett specifikt antal veckor utefter det som tidsuppskattats. Projektledaren menar på att ”när
man kör vattenfall så är det att man gärna vill ha en viss funktion vid den här tidpunkten”.
Vid användningen av vattenfallsmodellen genomförs i analyseringsfasen och planeringsfasen följande moment:
• Krav detaljeras och färdigställs
• IT tidsuppskattar hur lång tid ett IT-projekt kommer att ta innan ett resultat kan redovisas
• Det fastställs hur mycket IT-projektet kommer att kosta
Nackdelen med att göra klart alla kraven från början är att om de vid ett annat tillfälle ändras så går det inte att ändra i IT-projektet senare, man förutsäger
vad som ska hända och planerar utifrån det. Stress uppkommer dessutom när tester, analyser, kravställning och utveckling inte blir färdiga. Tester blir inte klara när Skandia arbetar enligt vattenfallsmodellen. Projektledaren menar på att ”alla vill testa och man var samtidigt beroende av varandra, vilket bidrar
till att det är trångt i testmiljöerna”. Dessutom var det vid användningen av
vattenfallsmodellen svårt att få tag på verksamheten (de som var beställarna av funktionen) vilket gjorde att ledtiderna förlängdes eftersom de var utsprid-da i olika delar av Skandia.
Projekt ”X”
Skandia införde de agila metoderna under 2003 under projekt ”X”, som var ett stort projekt och där motsättningar fanns mellan systemutvecklare, krav-ställare och testare. I test hittade de många fel vilket bidrog till att åtgärder tillförskaffades. De fick även in väldigt många beställningar från verksamhe-ten, som medförde att det blev väldigt rörigt. I samband med det fick inte heller verksamheten det som de beställt utan det fanns vissa skillnader.
De tog in konsulter som redan arbetade med de agila metoderna. I projektet modellerade en person upp en process utifrån en agil synvinkel. De arbetade med denna process under ett halvår och kunde därefter presentera detta inför Skandia.
Kravformulering
Kraven formulerades i projekt ”X” först för att sedan brytas ner i så kallade ”user stories” eller funktionsblock, dvs. den funktion som ska utvecklas. Var-je funktion kravställdes, utvecklades och testades. Kravställningen utfördes på en mer övergripande nivå i planeringsfasen. Det följdes av en indelning i olika etapper där kraven detaljerades av projektteamet, vilket tydliggjorde vad som skulle levereras.
Utveckling
I projekt ”X” lämnade systemutvecklarna till att börja med över det som skul-le testas sist i kedjan. Det resulterade i att många fel uppstod i test, det fanns inte utrymme till att rätta något innan de skulle börja på nästa leverans och mycket arbete blev inte färdigställt. Projektet innefattade stora utvecklingsak-tiviteter vilket bidrog till att de inte kunde ta hänsyn till om förvaltningen ändrade någonting. Därför skapades en ”backlogg”, dvs. krav kom från både verksamheten och förvaltningen om vad som skulle prioriteras och vad som skulle designas.
Test
I projekt ”X” jobbade de med automatisering, dvs. de byggde in automatiska testfall. Samtidigt som en funktion konstruerades så kördes automatiska test-fall som kunde återanvändas för varje ny release och varje ny funktion.
Funktionstester flyttades från testperioden till utvecklingsperioden, dvs. de synkroniserade det som blev klart i utveckling och testade den funktionen direkt.
4.2 Intervju med systemutvecklare 1
Med systemutvecklare 1 genomfördes en intervju om vattenfallsmodellen, de agila metoderna, metoder i allmänhet och om IT-projekt. Underrubriken ”IT-projekt utifrån systemutveckling” utgår från informantens roll i Skandia.
IT-projekt utifrån systemutveckling
Systemutvecklaren menar på att ”de projekt som misslyckas mest är de som
är stora och som pågår under en väldigt lång tid, dvs. under flera år. Under tiden så förändras verksamheten och då har man hållit på att utveckla fel sak”.
Det är omfattningen och prioriteringen på IT-projekt och inte vattenfallsmo-dellen som det är fel på. ”Så egentligen finns, enligt min mening, inget fel
med vattenfallsmodellen bara i dimensionering i varje enskilt uppdrag, man ska bryta ner det i mindre uppdrag och det är egentligen vad agila practices är så därför är jag väldigt positiv till den här idén”. Egentligen är det
styr-modellen som det är problem hos samt om projektledaren inte är tillräckligt styrande, engagerad i sitt arbete.
På grund av att en prioritering saknas så hamnar de flesta projekt hos IT-avdelningen i Skandia som då designar och analyserar det. Istället för att mo-dellera hela kedjan av aktiviteter och göra verksamhetsanalyser behöver IT göra genomförandefasen på plats.
Om konstruktionen sker av en individ som inte dokumenterar genomförandet så blir det omöjligt att förvalta det eller vidareutveckla det. Det resulterar helt enkelt i att funktionen måste tas bort.
Ett finansiellt problem blir det inte om systemet skulle vara litet då en sådan vidareutveckling kostar lika mycket som att utveckla ett nytt system. System-utvecklaren anser däremot att ”Om vi pratar om stora system som innehåller
mycket regelverk och sånt där då kan man inte bara slänga det utan då måste man förvalta det och då måste man ha regler, styrning, metoder och mallar”.
Man kan inte arbeta enligt XP i sådana fall eftersom det då gäller att gå in i systemet, förvalta det och skapa regler, metoder och mallar. Det är viktigt att inspektera koden för att se vad den representerar och sedan vidareutveckla den.
Utvecklingsmetoder/modeller
Enligt systemutvecklaren finns vissa missuppfattningar kring modeller då de i grund och botten följer samma mall, dvs. oavsett modell sker en tillverkning av något. Om administrationen prioriterade t.ex. en vidareutveckling av en databas så skulle det skapa förutsättningar för både verksamhetsutveckling och affärsutveckling. Genom att fördela arbetet och lägga mer tid på varje del så skulle en tidsförlust kunna undvikas eftersom mängden arbete minskar.
Systemutvecklaren menar på att de ibland blandar ihop och jämför de agila metoderna och vattenfallsmodellen, och tycker att den ena inte kan vara bätt-re än den andra då det finns olika behov som de grundar sig på. Personen menar på att ”man måste se de här olika behoven och i små, lokala system,
bra för då är det bortkastat att försöka standardisera något som egentligen inte har någon livslängd, en one-off, en engångsföreteelse”.
Systemutvecklaren tycker att det kan vara bra om vattenfall, liksom görs inom agila metoderna delleverera funktionen. Det ska gå att leverera i tid även om man kör vattenfallsprojekt.
4.3 Intervju med systemutvecklare 2
En intervju genomfördes med systemutvecklare 2 om systemutveckling, de agila metoderna och den agila metoden Scrum.
Systemutveckling och de agila metoderna
Vid införandet av de agila metoderna upprättades det i Skandia en provgrupp, som systemutvecklaren inte var med i. Men systemutvecklaren uppfattade det som att vara passande då många olika människor var delaktiga. För ett par år sedan fick de ledningens stöd, det var inte bara projektledare som tyckte det var bra utan det var även ”vingcheferna” som godkände de agila metoderna.
Det har inte funnits något egentligt motstånd menar systemutvecklaren men det finns ändå risker och problem som kan uppstå om stödet inte finns. Det som skulle varit fördelaktigt hade varit att verksamheten gått samma kurser som IT. Men det slutade ändå med att det var tydligt vad som behövde göras och hur det skulle göras, man samarbetade bättre helt enkelt.
När man arbetar enligt de agila metoderna börjar de med att göra en utred-ning, sedan går de över till grov design för att därefter påbörja iterationen. Istället för att läsa ett papper som brukade vara aktuellt finns det nu en back-logg som en produktägare håller koll på.
Produktägaren kommer oftast från verksamheten och förstår inte riktigt alla de tekniska delarna utan då måste de meddela att de olika funktionerna som
utvecklas kan spara mycket tid i framtiden. Produktägaren godkänner funk-tionen och ger klartecken till teamet när produkten är flyttad. Godkännandet från produktägaren är viktigt och det måste ske snabbt för att kostnaderna annars kan öka. Verksamheten godkänner den för det mesta eftersom de kän-ner till arbetsuppgiften bäst.
Systemutvecklaren sa senare under intervjun att ”sedan kan man ju ändra sig
på vägen om det är några tekniska eller naturlig orsak som gör att man ska styva om men då ska produktägaren vara med på det och skriva på sitt accept på det då. Då ska även backloggen ändras om till det synsättet”.
Enligt systemutvecklaren har systemutveckling effektiviserats genom använ-dandet av de agila metoderna då arbetsuppgifterna nu är mer specificerade. Leveranserna sker dessutom mer effektivt och verksamheten får in nya funk-tioner, kvaliteten ökar i och med att rätt saker produceras.
Det iterativa arbetssättet passar in på systemutveckling eftersom det är lättare att komma igång med testerna och kraven. Det är dock svårt att ta med alla funktioner om förändringar kommer. Det medför att vissa funktioner ibland måste tas bort för att bli klar i tid. I varje sprint eller iteration står det klart vad det är som ska göras, arbetet påbörjas tidigare och det är då lättare att bli färdig.
Systemutvecklaren menade att det däremot finns en viss fara finns med att inte klara av en sprint eller iteration. Trots att en konstruktör har en månad på sig att utföra en arbetsuppgift, är det inte alltid så eftersom test samtidigt måste göras. Systemutvecklingen brukar dock bli klar när det är en vecka kvar och det gör att test kan påbörjas. Det går inte att vänta tills allt är klart för det kan ibland bli databasändringar eller annat som inte går att ändra på direkten.
Men det är inte möjligt att i praktiken kunna ha till förfogande 4 veckor efter-som test inte kan börja de sista dagarna av sprinten. Om test endast skulle ha någon dag på sig att testa skulle de inte kunna slutföra dessa. Testen som man gör kallas enhetstester. Det finns i Skandia både IT-testare och verksam-hets-testare, alla skriver sina egna testfall som passar dem.
Scrum
Vad gäller Scrum följer de inte den metoden slaviskt utan säger sig vara Scrumbut eftersom de inte följer det som metoden förespråkar om test, de har istället en stor testgenomgång. Det görs genom regressionstest och kan äga rum under 3 till 4 veckor innan produktionssättning.
”Då är det ju tänkt att det ska vara genomtestat, kodat, avlusat och jag tyck-er att vi kan se det. Vi har fel men vi hanttyck-erar det helt okej så det känns inte som att det blir värre och värre utan färre och färre eller åtminstone inte fler under ett regressionstest och då kör man igenom systemet”.
Varje team har en kvart var varje dag för ett Scrum möte. Scrum mötena är bra men de får inte bli för stora, runt 10 personer är bra medan 15 är för många. Alla som ska vara med samlas varje dag och säger om de har några problem eller om allt fungerar.
Systemutvecklaren menar att ”det är viktigt att man får teamkänsla, det är
viktigt att folk tar ansvar och det är viktigt att de förstår det. Vad är det jag ansvarar för själv för att driva framåt? Man kan inte bara sitta på en stol och vänta på en uppgift utan då är man som teammedlem skyldig att ta reda på det”. Om någon inte riktigt är intresserad av att arbeta så förlorar de både tid
och det tillkommer ökade kostnader. Om det blir för lite att göra så kan alter-nativet vara att börja med en ny uppgift istället för att vänta på att krav kom-mer. Det gäller att hela kedjan arbetar i ett flöde för att motverka att glapp uppstår hos systemutvecklare.
På Scrum mötena sätts lappar upp vilket gör att de kan se när något är påbör-jat och när något avklarats. I början av varje sprint sitter man ner och medde-lar vad det är som ska göras. Om det är nya personer som inte varit med i början så meddelas det igen.
På lapparna står det vad det är som ska göras, vem som gör vad och hur lång tid det kommer att ta (allt från tre timmar till tre dagar). Det gäller dock att lapparna inte blir för stora i omfattning eftersom de i sådana fall finns kvar på tavlan alltför länge.
Systemutvecklaren brukar göra så kallade ”burndowns”, vilket är en linje över hur många timmar som något kommer att ta. Den börjar från starten av sprinten och i den visas dagar. Om linjen följs så är det bra men om de ligger lite över så är de sena. Varje dag har en egen rad i en matris som säger hur många timmar det är kvar.
4.4 Intervju med team manager
Team managern som är en Scrum master intervjuades en gång. I detta inklu-deras den observation som genomfördes i Skandia i samband med intervjun. Detta avsnitt handlar om Scrum möten och om Scrum.
Scrum möten
Ett Scrum möte varar i 15 minuter. I det diskuteras vad som gjorts igår, vad som ska göras idag och vilka problem som finns. Scrum möten, ”Daily Scrums” körs av en Scrum master. En Scrum master är systemansvarig och har flera olika team. En systemutvecklare skulle kunna vara en Scrum master men de medverkar hellre som teammedlemmar.
Scrum möten visar exakt vad det är som pågår, det ger en överblick över vil-ka brister som finns, om det skulle komma in fler saker som de måste ta hän-syn till (”Unplanned Items”), om det finns några produktionsfel, om man har glömt något eller kommit på något som måste tilläggas.
Scrum mastern på Skandia menar på att ”man har allt framför sig istället för
att man sitter med något papper. Här ser man direkt alla grejerna, vad som är på gång och jag ser vad som ska göras och jag som icke-tekniker lär mig mycket om den tekniska biten”.
För Scrum mastern har arbetet blivit transparent, dvs. det blir synligt. Det har både för- och nackdelar eftersom det inte är alla som gillar att det som de gör eller inte gör blir synligt för andra. Genom att använda lappar på en så kallad ”whiteboard” tydliggörs vilka arbetsuppgifter som gjorts igår, vad som ska göras idag, om det finns några problem, om något måste delas in i mindre ”bitar” eller om det tillkommit några nya arbetsuppgifter som måste priorite-ras.
Scrum
Systemutvecklarna på avdelningen som Scrum mastern arbetar inom har svårt att arbeta enligt Scrum eftersom de har haft svårt att planera. Enligt Scrum mastern ”kan det ju vara så att för någon programmerare tar det 4 timmar
och för en annan 20 timmar för samma grej så att den där tidsplanering som man gör från början är jätteviktig men det är ju den som strular. Men det beror ju också på hur långt man har kommit i processen och hur fort man arbetar”.
Skandia har även regelverk vad gäller produktionssättning, vilket gör att de inte får utföra det när de vill. De måste ta hänsyn till budget, förvaltningspro-cesser, releasehantering, utredningsarbete, tid och hur mycket ett IT-projekt får kosta. Scrum mastern menar på att ”det finns kopplingar till olika system