Vilhelm Johansson, Björn Ressem, Andreas Svensson

Agila metoder i stora projekt inom två

svenska storbanker

Agile methods in large projects within two Swedish commercial

banks

Projektledning

D-uppsats

Termin: VT-14

Handledare: Tomas Gustavsson

Examinator: Lennart Ljung

iii

Sammanfattning

Det agila arbetssättet har på senare tid blivit allt mer implementerat i stora

projektmiljöer. Det uppkom i IT-branschen när vattenfallsmetoderna inte längre

ansågs vara lika effektiva och lönsamma. Istället utarbetades en ny projektmetod,

den agila projektmetoden.

Övergången från traditionella vattenfallsmetoder till det agila arbetssättet innebär

flera förändringar. Det som är karakteristiskt för vattenfallsmetoderna är att

detaljplanering genomförs innan genomförandet av projektet. Medan det agila

arbetssättet innebär att detaljplaneringen görs för kommande tidsintervall (etapp).

Det blir således en strävan att hela tiden förbättra det aktuella projektet. Genom att

ändra arbetssättet ifrån det traditionella vattenfallstänket med fasta milstolpar till

att istället använda det agila arbetssättet skapas kontinuerligt där resultatet kan

värderas och förbättras. Detta leder till att det blir enklare att hantera oförutsedda

problem och förändringar.

De svenska storbankerna har historiskt sett präglats av sekventiella arbetsformer i

IT projekt. SEB och Handelsbanken är två av dessa svenska storbanker, vars IT-

avdelningar som just nu genomgår en förändring från tidigare vattenfallsmetoder

till det agila arbetssättet. Hur SEB och Handelsbanken följer det agila arbetssätet i

dagsläget varierar för de två bankerna eftersom bankerna valt olika sätt i

implementeringsprocessen. SEB har gjort en friare övergång till skillnad från

Handelsbanken som tagit det aningen försiktigare.

SEB använder sig idag av små arbetsteam men bristen av koordinering mellan

dessa team försvårar genomförandet av projekt för projektledaren. Inom

organisationen finns det fortfarande behov att hantera projekt särskilda projekt på

ett traditionellt, sekventiellt sätt. Dessa är projekt där komplexiteten blir för

mycket att hantera med deras nuvarande agila modell och projekt som har en

deadline som inte under några omständigheter får missas. Inget agilt projekt hos

SEB ser likadant ut som det andra då det genomförandet beror på vilka grupper

som är involverade.

Handelsbanken använder små projektgrupper och är tillmötesgående vid

förändringar som rör projekten. Budgetprocessen för varje projekt följer i

dagsläget den sekventiella modellen eftersom produktägaren måste veta hur

mycket projektet kommer att kosta. Därför tar projektet fram en grov, långsiktig

plan i ett tidigt skede. Under projektets gång så utarbetas en kortsiktig

detaljplanering av projektmedlemmarna.

iv

Abstract

The agile approach has recently become increasingly deployed in large project

environments. It was first used in the IT industry when waterfall methods no

longer were considered efficient and profitable. Instead a new type of project

methodology, the agile project approach, was born.

The transition from traditional waterfall methods to agile approach involves a lot

of changes. Something that is characteristic of the waterfall method is that

detailed planning for the entire project is done before the implementation of the

project starts. While the agile approach means that a small team makes detailed

planning for the next time interval. It is a quest to improve throughout the current

project. By steering away from the philosophy with fixed milestones and instead

use an incremental and iterative approach creating results that can be measured

and improved all the time throughout the project. This means it becomes easier to

deal with unforeseen problems and changes from the client.

The major Swedish commercial banks have historically been characterized by

sequential IT projects. SEB and Handelsbanken are two of the major Swedish

commercial banks which are undergoing a change from the previous waterfall

methods to the agile approach. How then, are these major Swedish commercial

banks following the agile approach in the current situation? One can see that it

produced different outcomes because the two banks have chosen different ways in

the implementation process. SEB left it to the individual teams in the bank with

little in the way of guidelines. Handelsbanken took a somewhat more cautious

approach.

SEB utilizes small teams but the lack of coordination between these teams

hampers the project manager’s ability to implement the project. In the

organization there still exists a need to handle certain projects in a traditional,

sequential manner. These are project where the complexity becomes too much to

handle with their current agile method and projects with a deadline that must not

under any circumstances be missed. No agile project at SEB is the other alike

seeing how the implementation depends on the teams involved.

Handelsbanken utilizes small teams and is accommodating towards changes

related to the project. But the budget process is in the current situation similar

with a sequential model since the product owner needs to know how much the

project will cost. A plan must also be presented to the product owner in the start

of the project so a crude long-term plan is laid out. However, during the project

short-term detailed planning is used which is developed by the project members.

v

Förord

Tillsammans med Tomas Gustavsson formades idén att undersöka hur två av de

svenska storbankerna i dagsläget arbetar med agila modeller i stora

projektmiljöer. Ett arbete som är intressant eftersom de svenska storbankerna har

en lång historia av att arbeta efter sekventiella modeller i projekt och har på senare

tid börjat fått upp ögonen för det agila arbetssättet.

Rapporten ingår i examinationen av Magisterprogrammet i projektledning vid

Karlstads Universitet och har utförts under vårterminen 2014.

Vi vill tacka vår handledare Tomas Gustavsson vid Karlstads Universitet som

genom rådgivning, dialoger och sin kunskap inom ämnet har varit till stor hjälp.

Vi vill även tacka våra respondenter Jan Lundqvist och Elina Jönsson från SEB

samt Conny Johansson från Handelsbanken.

Karlstad, maj 2014

vi

Innehållsförteckning

1. Inledning ..................................................................................................... 3

1.1 Bakgrund ............................................................................................................. 3

1.2 Problemdiskussion .............................................................................................. 4

1.3 Forskningsfråga ................................................................................................... 6

Syfte och förväntat resultat ............................................................................................. 6

1.5 Avgränsningar ..................................................................................................... 7

2. Teori ............................................................................................................ 7

2.2 Generellt om vattenfallsmodeller ........................................................................ 7

2.3 Agila modeller ..................................................................................................... 8

2.3.1 Scrum ........................................................................................................ 10

2.3.2 Large-scale Scrum ..................................................................................... 13

2.3.3 SAFe- Scaled agile framework ................................................................. 18

3. Metod ........................................................................................................ 28

3.1 Teoriunderlag för metodval ............................................................................... 29

3.1.1 Intervju ...................................................................................................... 29

3.2 Metodval ........................................................................................................... 32

4. Empiri ........................................................................................................ 36

4.1 SEB ......................................................................................................................... 36

4.2 Handelsbanken ........................................................................................................ 42

5. Analys ....................................................................................................... 47

5.1 Storlek ............................................................................................................... 47

5.1.1 SEB ........................................................................................................... 47

5.1.2 Handelsbanken .......................................................................................... 48

5.2 Kommunikation ................................................................................................ 49

5.2.1 SEB ........................................................................................................... 49

5.2.2 Handelsbanken .......................................................................................... 50

5.3 Planering ........................................................................................................... 51

5.3.1 SEB ........................................................................................................... 51

5.3.2 Handelsbanken .......................................................................................... 52

5.4 Genomförande ................................................................................................... 53

5.4.1 SEB ........................................................................................................... 53

5.4.2 Handelsbanken .......................................................................................... 54

6. Diskussion ................................................................................................ 55

6.1 SEB ......................................................................................................................... 56

vii

6.2 Handelsbanken ........................................................................................................ 57

6.3 Slutsatser ................................................................................................................. 59

6.4 Vidare forskning ..................................................................................................... 60

Figurförteckning

Fig. 1 Beskrivning av LSS för små organisationer. .................................. 14

Fig. 2 Large scale Scrum i en stor organisation. ...................................... 17

Fig. 3 SAFe Big Picture (Leffingwell, 2014). .............................................. 19

Fig. 4 Beskrivning av PSI. ........................................................................... 21

Fig. 5 Förenklad bild av metoden. .............................................................. 35

Fig. 6 Förenklad bild på hur SEB jobbar med agila projekt. ..................... 36

Fig. 7 Visualisering av kommunikation i agila projekt. ............................. 37

Fig. 8 Visualisering av kommunikationsvägar i agila projekt hos

Handelsbanken. ............................................................................................... 43

Fig. 9 Grov planering för hela projektet från portföljnivå. ........................ 45

Fig. 10 Detaljplanering sker för varje sprint på teamnivå. ...................... 45

Fig. 11 Projektkontoret har Scrum of Scrums varje vecka samt möte för

lägesrapport varje en gång per månad för kontroll av samtliga projekt. .... 46

3

1. Inledning

Uppsatsen ska visa hur två av de svenska storbankerna i dagsläget arbetar med

agila modeller i stora projektmiljöer. Detta har skrivits förhållande till tidigare

forskning och teori kring ämnet.

Teorigrunden utgår ifrån agila projektmetoder och vattenfallsmetoder. De olika

projektmetoderna förklaras och tydliggörs genom att beskriva fördelar samt

nackdelar. Utifrån teorin kring de olika projektmetoderna gjordes sedan en

fallstudie kombinerat med en kvalitativ intervjustudie med anställda personer för

båda storbankerna. Personerna som intervjuades besatt den kunskap som behövs

för att jobba i stora projekt med en agil tillämpning.

1.1 Bakgrund

Projekt leds av en temporär organisation och styrs av en projektledare som skall

ska samverka med övriga ledare i företaget för att nå ett mål eller resultat inom

ramen för tid och kostnad.(Jansson & Ljung, 2004).

För att skilja projekt från övrig organisation använder Antvik & Sjöholm (2005)

fyra kännetecknande drag:

Målstyrt. Tydliga mål och visioner så att arbetsgruppen har något att

sträva mot och för att kunna föreställa sig resultatet.

Unikt. Uppgiften gruppen skall lösa är av engångskaraktär.

Begränsat. Som nämns ovan styrs projektet av tid och kostnad.

Temporärt. Projektet har en tydligt start och slut.

De första tecknen på projektliknande arbetssätt växte fram på 1930-talet då

amerikanska flygvapnet upprättade ett projektkontor för att bättre kunna hantera

utvecklingen för aktuella flygplansmodeller. Det amerikanska försvaret lade då

grunden för projekt som arbetsform och denna metod fick sitt genomslag på 1950-

talet. Då handlade det om effektiva och resultatinriktade tillvägagångssätt som

senare skulle komma att kallas projekt. Projekten blev flera gånger framgångsrika,

så som till exempel Manhattan-, Atlas- och Polarisprojektet. (Berggren, 2001,

s.21). Den svenska försvarsmakten tog efter USA och började använda denna nya

metod för stora projekt. För att göra detta besökte Saab den amerikanska

försvarsmakten. Saab applicerade senare den nya projektmetodiken för

genomförandet av Sveriges första storskaliga projekt, flygplanet Viggen

(Berggren, 2001).

I början användes projektmetodiken enbart för stora resursslukande projekt. Dessa

metoder kan med en gemensam benämning kallas vattenfallsmodeller.

Vattenfallsmodellerna präglas av detaljerade planeringsfaser, där

4

projektdeltagarna arbetar efter milstolpar, så kallade stage-gate. (Jansson & Ljung,

2004).

Med tiden har projekt som arbetsform blivit allt vanligare och applicerats på allt

mindre arbeten. Inom it-branschen växte ett flertal flexibla metoder fram som

lämpade sig för branschens ständiga förändringar, dessa fick år 2001

samlingsnamnet agila metoder. På senare tid har dessa även börjat användas inom

de svenska storbankerna för större projekt.

Det är relativt nytt att använda sig av de agila metoderna i större projekt. Med

större projekt syftas det här på projekt som använder sig av mer än en arbetsgrupp

där arbetsgruppen omfattas av fler än 3-9 personer (Schwaber & Sutherland,

2011).

Utifrån vattenfallsmodellen och agila metoder ska de svenska storbankerna

undersökas hur de med agila metoder arbetar med större projekt. Detta är

intressant ur två perspektiv. Dels då bankerna har en lång historia av att arbeta

med vattenfallsmodellen och dels då det i dagsläget inte finns någon väldefinierad

metod för hur stora agila projekt ska genomföras.

1.2 Problemdiskussion

Med avseende på användandet av de agila metoderna sker i stora projekt där det

normalt används vattenfallsmetoder syns direkt flera skillnader. Utöver att de

agila metoderna inte arbetar efter en detaljerad plan som i vattenfallsmetoderna

ska förändringar av kraven i det agila arbetssättet välkomnas, även sent under

projektet för att kunna ge kunden en konkurrenskraftig produkt (Gustavsson,

2011). Förändringar av kraven under projektet kan komma att ställa till problem i

större projekt som involverar flera projektgrupper. Detta eftersom större projekt

ofta är beroende av att de andra projektgrupperna levererar resultaten vid en

angiven tid för att arbetets ska kunna fortskrida. Detta innebär hela konceptet med

timeboxing motsägs då milstolpar återigen behöver införas (Nils & Olsson, 2005).

En av de agila principerna är att den bästa kommunikationen sker ansikte emot

ansikte, det är således bäst om projektdeltagare är samlande tillsammans

(Schawber & Sutherland, 2011). Vilket skiljer mot den klassiska

vattenfallsmetoden där kommunikationen inte behöver ske ansikte emot ansikte

eftersom arbetet sker efter en detaljerad och utarbetad plan (Wysocki, 2009).

Vattenfallsmodellen och det agila arbetssättet har även olika syn på hur

projektgruppen ska vara uppbyggt ur ett kompetensmässigt perspektiv. De agila

metoderna anser att projektgruppen skall ha verksamhetskunniga projektdeltagare

under hela projektet (Gustavsson, 2011). Wysocki menar däremot att

projektdetagare som arbetar enligt vattenfallsmetoden inte behöver ha

spetskompetens, det vill säga vara specialister, inom ämnet då det är lätt för den

enskilde individen att följa projektplanen eftersom den är skriven på detaljnivå

(Wysocki, 2009).

5

Genom att studera det agila manifestet utläses fyra följande punkter som utgör

grunden för vart fokus ska läggas inom de agila metoderna:

Individer och samspel framför processer, metoder och verktyg.

I en rapport från 1998 ämnade två forskare vid namn Dobbins och Donnelly att

identifiera kritiska faktorer som vanligen förekommer i stora förvärvnings projekt

inom regeringen. Ett antal projektledare fick i studien svara på vilka faktorer som

de upplevde som viktiga för att ett projekt skulle lyckas. Studien mynnade ut i 18

faktor som projektledarna ansåg vara viktiga för att projekten skulle lyckas.

(Dobbins & Donnelly, 1998).

I listan finns ett flertal processer och metoder som påstås vara kritiska för att ett

projekt skall lyckas. Bland annat nämns tydliga krav, planering och mål samt risk

hantering. Författarna ger en lista på åtgärder för att maximera chansen att lyckas

hantera de kritiska faktorerna. Författarna poängterar att det är extra viktigt att

hantera avvikelser i schema och budget.

En av grupperna Dobbins & Donnelly intervjuade uppgav Continuous meaningful

visibility using measures som den viktigaste faktorn för framgång i projektet. Det

kan liknas de agila metodernas möten och arbete med färdiga inkrement (Dobbins

& Donnelly, 1998).

Användbart resultat framför omfattande dokumentation.

Enligt Jansson och Ljung (2004) spelar dokumentationen en viktig roll för hur

kommunikationen inom projekt ska se ut som följer en vattenfallsmodell. Den

skriftliga dokumentationen är speciellt viktig för de som inte deltar i det

vardagliga arbetet. Janson & Ljung uttrycker även det är viktigt att ha en satt

referensram kring hur dokumentationen ska skötas kring projektdirektiv,

projektspecifikation, progressrapport och slutrapport.

Vattenfallsmodellen som använder dokumentationen som ett verktyg för att

kommunicera med projektdeltagarna har såldes ett annat tänk kring

dokumentationen gentemot de agila metoderna. De agila metoderna säger att det

är viktigare att leverera ett inkrement så att projektarbetet kan fortgå än att ödsla

onödig tid på att dokumentera i detaljnivå. Det agila arbetssättet har således en

stark kontrast gentemot vattenfallsmetoderna ur ett dokumentationsperspektiv.

Ett av problemen som behöver åtgärdas när projektet arbetar enligt de agila

metoderna är hur kommunikationen skall skötas dagligen i en situation där alla

projektdeltagare inte kan ses ansikte mot ansikte.

Kundsamarbete framför kontraktsförhandling.

6

En studie gjord åren 1984-1987 visade att införa incitament i

kontraktsförhandlingen kunde hjälpa till att minimera projektkostnader i stora

projekt. Studien visade att användningen av incitament kan användas som ett

användbart verktyg för projektledaren och klienten i kontraktsförhandlingen.

(Herten & Peeters, 1986)

2003 utfördes en empirisk studie på 93 off-shore projekt som visade att detaljerna

i kontraktet bidrar starkt till lönsamheten i projekten. I sin analys påpekades ett

flertal variabler som alla bidrog till det slutliga vinsten. (Gopal,

Sivaramakrishnan, Krishnan & Mukhopadhyay)

De två ovan nämnda studierna visar att kontraktsförhandling kan ge betydligt

bättre lönsamhet i ett projekt. Hur skall då kontraktsförhandlingar genomföras

som enligt studierna är en viktig faktor för att ett projekten skall vara

vinstdrivande när det men det agila manifestet säger att de agila metoderna ska

fokusera på kunditeraktionen över kontraktsförhandlingar?

Anpassning till förändring framför att följa en statisk plan.

2002 skrev en projektledare vid namn Lynn Crawford en rapport med målet att

profilera en utmärkt projektledare. Detta gjorde hon bland annat genom att hitta

och utröna kritiska framgångsfaktorer i projekt och huruvida det är sådana att

projektledaren direkt kan påverka dem. Resultatet gav att planering alltid var

listad bland de topp 5 viktigaste faktorerna. (Crawford, 2002)

Hur skall då planeringen hanteras i stora projekt som arbetar enligt det agila

metoderna?

1.3 Forskningsfråga

Hur arbetar SEB och Handelsbanken agilt i multiprojektmiljöer med stora IT-

projekt i en miljö som haft en lång historik av att arbeta efter vattenfallsmetoder?

Syfte och förväntat resultat

Att ta reda på hur de svenska storbankerna jobbar med de agila modellerna i

multi-projektmiljöer i stora projekt där bankerna tidigare arbetat efter

vattenfallsmetoder. Vi tror att vår empiriska studie kommer att visa att bankerna

har ett arbetssätt som liknar teorin för Scaled Agile Framework (SAFe), SAFe är

en modell som används för att arbeta agilt i stora projekt och förklaras

genomgående i kapitel 2.6. Samtidigt tror vi att bankerna att ha egna lösningar

och metoder specialanpassade efter bankens egen organisation.

7

1.5 Avgränsningar

Arbetet behandlar de två svenska storbankerna, SEB och Handelsbanken och hur

dessa arbetar agilt med stora IT-projekt i multiprojektmiljöer. Hur bankerna

fungerar som organisation har enbart behandlats där det är nödvändigt för att

förstå hur de fungerar och gör som projektorganisation. Hur de enskilda teamen

arbetar inom bankerna behandlas inte utan rapporten är skriven från projektledare

och projektkontorens perspektiv.

2. Teori

I kommande kapitel beskrivs och jämförs de stora skillnaderna mellan

vattenfallsmodeller och agila modeller i stora projektmiljöer där varje arbetssätt

avslutas med fördelar och nackdelar. Scrum har i rapporten valts som exempel för

de agila metoderna och SAFe har valts som exempel för agila projekt i stora

projektmiljöer så kallade Large Scale Scrum (LSS). Vi är medvetna om att

skillnaden mellan en modell och en metod är diffus. Därför har vi i den här

rapporten valt att för enkelhetens skull säga att en modell är en abstrakt

avbildning av verkligheten medan metod är ett konkret tillvägagångssätt, en

strategi för att nå sitt mål.

2.2 Generellt om vattenfallsmodeller

Om projektet skall genomföras inleds först planeringsarbetet. Planeringsarbetet

börjar normalt med att ta reda på vem eller vilka som berörs av projektet (det kan

både vara positivt och negativt berörda parter) så kallade intressenter. När

intressenterna är framtagna undersöks och analyseras vad varje intressent

förväntar sig av resultatet. Så kallad intressentanalys. Eftersom det ofta är

omöjligt att tillgodose alla inblandades behov behöves redan i ett tidigt skede

prioriteras mellan resultat, kostnad och tid. När kraven och behoven för projektet

är definierade skall kunden få en beskrivning av vad som är tänkt att levereras

(Jansson & Ljung 2004).

Därefter behöver projektet diverse strategier för hur ”problemet” skall lösas När

projektet har beslutat vilka strategier och lösningar som skall användas delas

arbetat upp i så kallade arbetspaket. Varje arbetspaket uppskattas i resurs- och

tidsåtgång. Detta innebär att projektets totala resurs- och tidsåtgång kan

uppskattas (För att uppskatta totala tidsåtgången tas hänsyn till vilka arbetspaket

som kan ske parallellt). Därpå görs en tidplan och budget för projektet (Jansson &

Ljung 2004).

Innan projektet påbörjar genomförandefasen är det viktigt att

projektorganisationen definieras. Ansvarsområden inom projektgruppen delas upp

8

och projektorganisationen planerar även för kommunikation dvs. vart/vem som

skall kontakta om någon stöter på problem (Jansson & Ljung, 2004). Under

genomförandefasen genomförs ständiga riskanalyser för att kunna undvika

empiriska hinder (Jansson & Ljung, 2004).

Fördelar och nackdelar med vattenfallsmodellen. (Wysocki, 2009):

Fördelar:

Hela projektet är planerat innan genomförandefasen.

Resurserna är definierade från start.

Behöver inte det mest erfarna teamet – eftersom alla vet vad som

behöver göras och i vilken ordning är det lätt för den enskilde att följa

planen utan tillsyn.

Teamet behöver inte arbeta från ett och samma kontor. Nackdelar:

Svårt att anpassa sig efter förändringar.

Kostar för mycket - Kunden kommer inte kunna se ”produkten” förens

hela planen är färdig. Detta kan upplevas som att kunden betalar för

onödig tid

Tar för lång tid att leverera resultat – Planeringsfasen tar längre tid än

andra metoder.

Behöver färdiga och detaljerade planer.

Måste utföras i ordning efter planen.

Saknar kundfokus - Modellen är driven av att få projektet gjort i tid till

den planerade kostnaden och till kundens specifikationer. Under

utförandet kan det vara svårt att göra förändringar efter kunds begäran

2.3 Agila modeller

I och med att projektarbetsformen fick ett större fäste och blev allt mer vanlig

arbetsform blev följden att metoden även applicerades på mindre projekt. När

projektstorleken avtog minskade även projektteamen.

Organisationer som inte längre ser projekt som en engångsföreteelse utan snarare

som ett standardiserat arbetssätt benämns som organisationer som arbetar i

multiprojektmiljöer. Detta är ett arbetssätt som härstammar från IT-branschen och

togs fram för att öka styrningen i projekt (Gustavsson, 2011).

Uppkomsten av att arbeta i multiprojektmiljöer innebar att de tidigare

vattenfallsmetoderna som var anpassade till stora projekt inte längre ansågs

effektiva och lönsamma. Istället utarbetades en ny typ projektmetod, agila

projektmetoder (Gustavsson, 2011).

Att arbeta agilt innebär en hel del förändringar jämtemot den traditionella

vattenfallsmetoden. En skillnad emot vattenfallsmetoden är att inte bara styra efter

milstolpar. Istället för att arbeta mot flera milstolpar definieras i de agila

9

projektmetoderna tydliga mål för en viss tid och projektgruppen gör det bästa

möjliga under den tiden, detta kallas timeboxing. En deadline tvingar fram

prioriteringar för projektet och är en viktig del av projektgruppen och

projektbeställarens samarbete. Kunden får enbart ändra kraven för projektet

mellan varje timebox. För att detta ska fungera måste projektgruppen veta exakt

vad som behöver uppfyllas så att projektgruppen prioriterar rätt. Det blir en

strävan att ständigt förbättra projektet. Genom att styra bort tänkandet med fasta

milstolpar och istället använda ett inkrementellt och iterativt arbetssätt skapas hela

tiden resultat som kan värderas och förbättras. Detta leder till att det blir enklare

att hantera oförutsedda problem och förändringar från kunden (Schwaber, 2004).

De agila modellerna tillåter ett litet team att arbeta flexibelt och med hög chans att

förutse och hantera eventuella problem (Gustavsson, 2011).

Fördelar och nackdelar med agila metoder (Wysocki, 2009):

Fördelar:

Klienten kan överblicka de färdiga delarna och ge förbättringsförslag.

Det finns inget bättre sätt för en klient att klargöra att projektet rör sig i rätt

riktning än att få prova de färdiga delresultaten. Detta arbetssätt resulterar i att

klienten kan se till att arbetet rör sig efter dennes önskningar.

Kan behandla omfattande förändringar i kraven mellan iterationerna.

Trots att metoden kan ta emot och behandla omfattande krav förändringar

mellan iterationerna bör arbetat behålla kontrollen hela tiden. Detta genom att

presentera klienten med alternativ och idéer under varje cykel. Dock kommer

det alltid komma tillfällen där kunden ser förbättringar där projektledaren inte

gör, vilket kommer innebära att förändringar måste accepteras.

Anpassningsbar för yttre förändringar.

Världen står inte still bara för att ett projekt genomförs. De agila metoderna

tillåter hantering av just detta faktum.

Nackdelar:

Kräver en involverad klient.

Ju troligare det är att förändringar kommer behöva göras desto större är vikten

att klienten är närvarande och kapabel att ta beslut som kommer vara bra för

slutprodukten. Med detta kommer även ägandeskapet av projektet. Om inte

både involveringen och ägandeskapet finns kan projektet lätt hamna i kläm.

Klienter som bara är flyktigt involverade tenderar att bryta planen för saker de

vill ha snarare än de behöver.

Projektteamet behöver vara samlat.

I projekt där förändring förekommer dagligen är kommunikationen

varierande. Kan inte projektgruppen samlas på ett och samma ställe kommer

projektledaren få spendera onödig tid för att få den interna kommunikationen

och dialogen med klienten att fungera.

10

Svårt att genomföra dellösningar.

När dellösningar implementeras bör organisationen förmå att hantera

förändringar och support systemet som finns inom organisationen.

Det slutgiltiga resultatet kan inte definieras i början av projektet.

Resultatet kommer variera. Ju mindre som framgår av målet desto mer kan det

komma att variera under projekttiden. Det kan bli så att bara delar av

problemet löstes på grund av att budgeten eller tiden tog slut, eller att en viss

del visa sig vara betydligt mer svårlöst än förväntat.

2.3.1 Scrum

Rapporten kommer att behandla Scrum eftersom det är en av de vanligaste och

mest spridda accenterna av de agila metoderna. Scrum utvecklades av Schwaber

och Sutherland tidigt 90-tal. De baserade Scrum metoden på artikeln ”The new

new product development game” skriven 1986 av Takeuchi och Nonaka.

Schwaber och Sutherland (2011) nämner tre verktyg i sin rapport Scrum guide

som används för att öka chansen för framgång i projektet:

Transparens: Allt som är av vikt för projektets framgång skall alltid

finnas tillgängligt för alla som ansvarar för projektets resultat. Aspekterna

av dessa måste vara en väl definierad standard så alla i teamet delar

samma uppfattning om vad som är transparens.

Mandat: De som arbetar närmast problemet skall ha mandat att ta beslut

rörande vad som behöver göras för att åtgärda problemet.

Snabbhet: Täta möten behövas utifall ett problem eller förändring i

kraven skulle påträffas behövs ett beslut om hur det skall hanteras snabbt

tas.

Scrum använder sig av små, intima team bestående av 3-9 personer som sköter

utvecklingen av produkten, utvecklingsteam, samt produktägare och Scrum

master. Scrum mastern existerar som en stödjande roll snarare än en traditionell

projektledare och finns till för att underlätta och hantera problem som utvecklings

teamet kan stöta på. Produktägaren är oftast den som finansierar projektet vilket

även innebär att denne har övergripande mandat (Schwaber & Sutherland, 2011).

I Scrum sker arbetet enbart med detaljplaneringen för de närmaste veckorna,

arbetet sker sedan i sprints här kallade för etapper, tidsintervaller på 4 veckor eller

mindre, med förbestämda uppgifter. Detta skapar regelbundenhet och minimerar

nödvändigheten för möten som inte är definierade av Scrum. Varje etapp skall

resultera i ett inkrement, en så kallad klar som kan definieras som en användbar

inkrementell av produkten. Etapper är konsekventa och består av timeboxar. En

avslutad etapp följs genast av nästa.

11

En etapp innehåller ett antal steg: planeringsmöte för etappen, dagliga möten,

genomförande, etapp granskning och retrospektiv på etappen (Schewaber &

Sutherland, 2011). Under en etapp gäller även följande:

Inga ändringar som skulle ändra målet för etappen får ske.

Målet och teamets medlemmar hålls konsekvent.

Omfattning kan förtydligas och förhandlas om allt eftersom mer blir känt.

Den enda som får avbryta en etapp är produktägaren.

Genom att skapa en inkrementell för omedelbar återkoppling kan varje etapp ses

som ett projekt med maximalt en månads livslängd. I och med att

detaljplaneringen inte sträcker sig längre än 4 veckor visualiseras hela tiden att

projektet och utvecklingen går i rätt riktning. Kostnader för fel minimeras även till

en kalendermånad (Schwaber & Sutherland, 2011).

Planeringsmötet hålls i början av varje etapp och är timeboxat till maximalt 8

timmar och motsvarar då en 4 veckors etapp. I mötet tar alla medlemmar av scrum

teamet del och hjälps åt med planeringen. Mötet är uppdelat i två delar som båda

ägnas lika tid (Schwaber & Sutherland, 2011).

Del 1: Vad skall bli färdigt denna etapp?

Projektdeltagarna försöker förutse funktionaliteten som skall utvecklas under

etappen med hjälp av produktloggen samt den senaste klar.

Del 2: Hur skall arbetet ske?

Efter projektdeltagarna bestämt vad som skall göras behandlas sedan frågan hur

projektdeltagarna skall åstadkomma nästa färdiga klar.

När planeringsmötet avslutats bör Scrum teamet kunna beskriva arbetet för

kommande etapp för Scrum master och produktägaren.

Daily Scrum är ett kort möte, á 15 min, som hålls varje dag där deltagarna

uppdaterar övriga medlemmar i projektgruppen vad som åstadkommit, vad som

skall göra och ifall någon har stött på hinder eller problem. Syftet med daily

Scrum är att bedöma framstegen mot etappmålet (Schwaber & Sutherland, 2011).

Produktlogg är en innehållsförteckning på allt som kan komma att behövas i den

färdiga produkten. Det är produktägaren som ansvarar för loggen, detta inkluderar

dess innehåll och tillgänglighet. Loggen listar alla funktioner och krav på

12

produkten samt korrigeringar som kommer att göras i framtiden. Den skall även

innehålla beskrivning, ordningsföljd på inkrementell och uppskattning av resurser.

Det är utvecklingsteamet som ansvarar för resursuppskattningen (Schwaber &

Sutherland, 2011).

Etappgranskning hålls efter varje sprint där deltagarna inspekterar vad som har

återkommit under etappen och gör därefter ändringar i produktloggen. Syftet är att

få återkoppling och de som bör vara närvarande är Scrum teamet samt

kundrepresentant. Granskningen skall innehålla följande (Schwaber & Sutherland,

2011):

Produktägaren fastställer vad som resulterat en klar och vad som inte har

det.

Diskussion kring vad som gått bra, vilka problem som uppstått och hur

dessa löstes.

Presentation av klar och svar på frågor kring denna.

Produktägaren ger återkoppling på det som hunnits med.

Alla närvarande deltar i en diskussion angående vad som skall göras

härnäst. Genom detta får projektgruppen värdefull input till nästa

planeringsmöte.

Detta möte är timeboxat till 4 timmar för en 4 veckors sprint.

Retrospektiv på etappen är ett tillfälle för självgranskning för teamet och skapa

en plan för förbättring till nästa etapp (Schwaber & Sutherland, 2011). Syftet är:

Fastslå hur föregående etapp gick med avseende på individer, relationer,

processer och metoder.

Fastslå vad som gick bra och möjliga förbättringar.

Skapa en plan för hur implementeringen framförda förbättringar för

projektgruppen. Scrummaster skall uppmuntra projektgruppen att

utvecklas inom ramarna för de agila metoderna.

Mötet är timeboxat till 3 timmar för en 4 veckors sprint.

Produkt backlog refinement (PBR) är enligt Larman & Vodde ett värdefullt

verktyg i Scrum. PBR innebär att mellan fem till tio procent av varje etapp skall

dedikerads av projektgruppen att förfina produktloggen. Detta ske genom att

analysera kraven, dela upp större objekt och uppskatta nya mål. Scrum nämner

dock inget om hur detta kan genomföras. (Larman & Vodde, 2009).

13

2.3.2 Large-scale Scrum

Vilket har beskrivits tidigare så är vattenfallsmodellen anpassad för stora projekt

och ett stort projektteam medan agila metoder tillämpas bättre för mindre projekt

och mindre projektteam. Hur skall då en organisation behålla det agila arbetssättet

i stora projekt?

Så kallade nya och förbättrade versioner av Scrum som ersätter den tidigare

versionen bör betraktas med en nypa salt. En sådan metod kommer aldrig att

utvecklas då de missar poängen med den empiriska processen och delaktigheten

som Scrum innebär, Scrum går aldrig att slutfört utan det skall kontinuerligt

utvecklas till det bästa möjliga för organisationen. (Larman & Vodde, 2009).

Larman & Vodde har utvecklat en metod för att arbeta med Scrum i stora projekt

och kallar metoden för Large-Scale Scrum (LSS). LSS är inte en ny och förbättrad

version av Scrum, utan följer samma mönster som tidigare Scrum. LSS är ett

samlingsnamn för metoder som kombinerar fördelarna med Scrum och fördelarna

med att arbeta i stora team och stora organisationer. (Larman & Vodde, 2009)

Denna modell är tänkt att fungera för såväl små organisationer med enbart ett fåtal

team som stora organisationer som kan innehålla hundratals projektdeltagare.

(Larman & Vodde, 2009)

Beroende av hur stor organisationen är föreslår Larman & Vodde två alternativ för

att arbeta med LSS, nämligen LSS för mindre organsitatoner och LSS för stora

organisationer (Larman & Vodde, 2009)

LSS – små organisationer

Modellen är lämplig i mindre organisationer som oftast uppgår till tio

projektgrupper och har en produktägare. Tio projektgrupper är ingen fast gräns

utan det beror snarare på produktägaren. I större organisation tenderar

produktägaren att tappa överblicken för projektet och PÄ kan inte längre samspela

med projektgrupperna på ett effektivt sätt. (Larman & Vodde, 2009)

Modellen Ser ut enligt följande figur 1.

14

Fig. 1 Beskrivning av LSS för små organisationer.

Modellen använder av olika typer av roller, loggböcker och aktiviteter.

Roller

Produktägaren - Prioriterar vad som skall genomföras av produktloggen och

träffare prohejtgrupperna varje iteraktion för att presentera målen och granska

resultaten av projektet. Om det förekommer många projektgrupper föreslår

Larman & Vodde att projektgrupperna eller annan spetspersonal hjälper produkt

ägaren.

Scrumteam – Självgående projektgrupper som självständigt slutför

arbetsuppgifterna som återfinns i produktloggen.

Scrummaster – Varje Scrummaster ska agera som en coach för projektgruppen

och produktägaren, lösa konflikter som uppstår i projektgrupperna och

återkommande upplysa projektgrupperna om projektets mål och visisoner.

15

Loggböcker

Produktlogg – Identisk med produktlogg i Scrum, se 2.4.

Etapplogg – Varje projektgrupp (Scrumteam) har en egen etapplogg som redogör

vilka moment av produktloggen som skall genomföras under etappen.

Potentially Shippable Product Increment (PSPI) – En utmaning med Scrum är

att få varje interaktion att bli en PSPI. PSPI skall resultera i en klar och skall även

innehålla sprint review (etappgranskning), sprint retrospective (Retrospektiv på

etappen) och joint retorspecitive. Larman & Vodde påpekar att alla

projektgrupper tillsammans skall göra en gemensam PSPI. Detta innebär att

projektgrupperna måste kontinuerligt integreras med varandra.

Aktiviteter

Planeringsmöte – Påminner om planeringsmötena som används i vanliga Scrum.

Skillnaden finns i vilka personer som deltar i mötena. I LSS för små

organisationer deltar produktägaren tillsammans med alla projektdeltagare eller

några projektdeltagare ur varje projektgrupp beroende på organisationens storlek.

Daily Scrum – Daily scrum följer samma principer som i vanlig Scrum. Dock kan

det i multiprojektmiljöer vara fördelaktigt att veta de andra projektgrupperna

arbetar med och därför kan en medlem ut team-A sitta med i team-Bs daily scrum

för att öka transparensen.

Product backlog refinement – Larman & Vodde förslår att i en kontext med

multiprojektmiljöer ska genomföras med hjälp av långa (flera timmar om så

behövs) diskussionsgrupper efter varje interaktion där projektdeltagarna erbjuds

möjligheten att diskutera med produktägaren.

Etappgranskning – Följer samma principer som vanligt Scrum, men vilka som

deltar kan variera.

Retrospektiv på etappen – Identiskt med vanliga Scrum men beakta att varje

projektgrupp gör ett eget retrospektiv på etappen.

Joint Retrospectiv (valfri) – Är ett möte för att ta till vara på lärdomar av

systematiska hinder under projektet. Mötet sker efter retrospektivet på den

genomförda etappen och Larman & Vodde har observerat att mötena fungerar

bäst i små grupper.

LSS – stora organisationer

LSS för stora organisationer introducerar två nya roller: område produktägare

(area product owner) och område produktägarens arbetsgrupp (product owner

16

team) samt en ny loggbok, områdeslogg (area backlogg). Områdesloggen är inte

en separat loggbok utan en produktlogg för ett specifikt område.

I stora organisationer (tio/hundra/tusentals teams) kan inte produktägaren längre

arbeta med varje enskilt team eller alla detaljer i produktloggen. I ett sådant läge

underlättar det att identifiera projektets avgörande områden och dela upp

produktloggen inom de olika avgörande områdena, varje område ska tilldelas en

egen produktägare så kallad områdes produktägare (APO i figur 1) och få en egen

projektgrupp (Scrumteam). (Larman & Vodde, 2009).

Hur modellen ser ut för LSS för stora organisationer presenteras i figur 2.

17

Fig. 2 Large scale Scrum i en stor organisation.

Några aktiviteter skiljer i LSS små organisationer och LSS stora organisationer

Företappsplanering – Före etappen ska planeras behöver område produktägarens

arbetsgrupp prioritera produktloggen. Produktägaren vill vanligtvis diskutera

18

prioriteringar inom varje områdeslogg med områdets olika deltagare, vilka som

deltar i diskussioner utöver produktägaren framgår inte.

Planeringsmöte – Varje område gör en egen planering, annars idetiskt med

etapplaneringen i Scrum

Product backlog refinement – Det sker en separat förfining för varje område

med områdets produktägare och projektgrupp.

Etappgranskning - Varje område gör en egen etappgranskning om involverar

områdets produktägare och projektgrupp, annars identiskt med etappgranskningen

i Scrum.

Joint Review (valfri) – områdenas projektgrupper samlas och diskuterar problem,

förbättringar och andra intressen.

Joint retrospecive (valfri) – identisk med LSS små organinsationer men kan

både ske på områdesnivå och hela nivån.

Sammanfattningsvis kan LSS för- och nackdelar sammanfattas som (Wysocki,

2009):

Fördelar:

Håller alla dörrar öppna så länge som möjligt.

Möjliggör att i ett tidigt skede se flera olika lösningar

Nackdelar:

Letar efter lösningar på fel ställe.

Ingen garanti att värdet av resultatet kommer från delresultaten

2.3.3 SAFe- Scaled agile framework

En projektmodell som följer LLS struktur är SAFe. SAFe är en projektmodell som

används framförallt inom mjukvarubranschen. Anledningen att SAFe har valts

som jämförande modell är för att det är en kommersiell modell som är

lättåtkomlig för allmänheten. SAFe modellen har utvecklats eftersom

förutsättningarna för att snabbare kunna utveckla komplexa mjukvarusystem

kräver större arbetsgrupper och kontinuerlig förbättring av arbetsmetoderna.

Enligt Dean Leffingwell (2011) har SAFe använts framgångsrikt i projektgrupper

omfattande 50-150 personer men också i projektgrupper omfattande tusentals

mjukvaruutvecklare.

SAFe avser att täcka hela organisationen och arbetar på tre nivåer: portfölj-,

program- och arbetsgruppnivå.

19

Teamnivån avser varje enskilt Scrum team medan programnivån består av flera av

dessa Scrum team och ser dessa som en gemensam projektgrupp. Portföljnivån

överser organisationens projektportfölj och arbetar med att förmedla

organisationens visioner och mål till grupperna.

Nedanstående figur 3 åskådliggör en överblick över hur SAFe är uppbyggt. I

Figuren syns tydligt de tre olika nivåerna och vilka beroenden som ingår i vilken

nivå. Modellen kommer att förklaras ingående i nästkommande underrubriker.

Fig. 3 SAFe Big Picture (Leffingwell, 2014).

2.3.3.1 Ordlista SAFe

För att enklare kunna beskriva SAFe som projektmodell behöver först några

begrepp förklaras.

Epics - större sammanhängande användar historier: Inom SAFe används två

typer av epics, affärs-epics och arktitekts-epics.

Affärs-epics är stora, övergripande kundinriktade initiativ som

sammanfattar en ny utveckling som är nödvändig för att realisera

affärsframsteg. Dessa kan uppstå proaktivt, internt, eller reaktivt, externt.

Arkitekt-epics är stora, övergripande, teknologiska initiativ för att utveckla

portföljs lösningar för att hjälpa nutida och framtida affärsbehov. Dessa

20

kan uppstå från sammanslagningar, teknikförändringar, internförändringar,

kostnader och ekonomiska drivkrafter.

Epics förvaras och behandlas i portföljloggen (Portfolio). Se figur 3.

Agile Release Train, ART: ART är en långlivad sammansättning av ett flertal

agila team och fungerar som leveransmekanism på programnivå. ART är den agila

utvecklingsorganisationen som realiserar värdet i värdeflödet. Ett ART har de

team som behövs för att fullfölja arbetet, nödvändig specialkompetens samt precis

rätt mängd av projektledning och arkitekturkunskap. ARTs är normalt begränsade

till 50-150 individer, en storlek som tillåter ett effektivt socialt nätverk samt att

logistiken, interaktionen och beroenden som kan förväntas inom ett stort IT-bolag

kan skötas på ett bra sätt.

Potentially Shippable Increments, PSI: Ett färdigt inkrement som motsvarar en

milstolpe. Skall kunna utvärderas och säkra integrering samt testas mellan alla

mjukvarutillgångar. Se figur 1.

User stories - användar historier: Det primära sättet som för kundernas behov

via värdeflöden till faktisk skriven kod och ett genomförande. Det är viktigt att

veta att user stories till skillnad från krav är en avsiktsförklarning och inte skrivit i

sten.

Value flows - värdeflöden: Värdeflöden är en abstraktidé som används för att

förstå och kunna leverera lösningar samt optimera tid till implementering av

särskilda lösningar. Dessa lösningar implementeras utav arbetsgrupper kallade

ART.

2.3.3.2 SAFe som modell

Det är viktigt att förstå att SAFe är uppbyggt för att starta implementering av agila

principer och att organisationer sannolikt behöver anpassas efter verksamheten.

Potentially shippable increment (PSI) - Team PSI

Team PSI är en sammanfattad lista av affärs- och tekniska mål som arbetsgruppen

ämnar klara av under tiden för PSI. Under planeringsfasen för PSI beaktas

visionen, user stories och krav. Därefter planeras PSI iterationerna tills

kapaciteten är full. Resultatet från PSI används sedan för att reflektera och

syntitisera specifika teknik- och affärsmål för arbetsgruppen under kommande

PSI.

Varje team PSI är vanligtvis bestående av två delar och är vanligtvis fem

iterationer lång. Den första delen består av fyra iterationer som är liknande

etapperna som återfinns i Scrum. Den andra delen, tillika den femte iterationen,

kallas för HIP, Hardening, innovation samt planning. Se figur 4. HIP är en

iteration som är bestående av tre steg.

Hardening: En sista kontrollering av resultat, är målen för PSI uppnådda?

Resultatet testas med bland annat prestandatester.

Innovation: Många företag börjar mogna i rollen som agilt företag finner

att det kan vara svårt att få plats med innovation och fri sammanslutning.

21

Av den anledningen försöks projektgruppens kreativitet och förmåga att

utveckla idéer gynnas.

Planning: Består av tre delar. Redovisa vad som har uppnåtts, underhåll

genom att retrospektiv se vad som kan förbättras under nästa PSI samt

planera nästa PSI.

Fig. 4 Beskrivning av PSI.

Konceptet bakom att planera in och använda sig av en HIP motiveras med tre

viktiga punkter:

Om HIP inkrementet föregår en release ger hardening aktiviteterna tid för

ett sista godkännande av produkterna, system och prestanda tester,

säkerhets godkännande och alla andra godkännande krav som kan behöva

testas innan en release men som inte är ekonomiskt hållbart att genomföra

efter varje iteration.

Den agila formen är optimerad för snabba leveranser av värde, speciellt

när det är understött av infrastrukturen. Men den högst disciplinerade

modellen kan påtvinga brådska i iterationerna. Därför kan det vara bra att

schemalägga tid för innovation, pröva idéer och nytänkande.

PSI planering, inspektion och anpassning av workshopen samt tiden avsatt

för lärande och infrastrukturellt arbete är rutinmässig och kontinuerlig.

Genom att lägga de här aktiviteterna under HIP kan utvecklingen ske

kontinuerligt under hela året utan att göra några förändringar i schemat.

Det finns även en fjärde anledning som Leffingwell argumenterar användandet av

HIP för. Ur ett organisationsperspektiv innebär 100 % användning av resurserna

att oförutsägbarheten av resultatet ökar. Att ha en planerad hardening som inte är

full av förbestämda aktiviteter, ger en buffert för att enklare kunna arbeta med

oförutsedda händelser i en annars svårplanerad miljö. Detta tillåter arbetsgrupper

att möta etapptidsgränsen trots osäkerheten som kan finnas i en utvecklande miljö.

22

Agile Release Train, ART: ART är den långlivade sammansättningen av alla

projektteam under programnivån bestående av normalt 50-150 individer och

fungerar som leveransmekanism för programnivån.

Metaforen tåg används av ett antal anledningar.

Tåget avgår och ankommer till station efter ett tillförlitligt schema (bestäm

kadens).

Det lämnar sin last till kunder (release) eller används för intern

utvärdering och bevis för det inkrementella systemets robusthet

(PSI/Release).

Om ett agilt team vill ha sin last (kod, dokumentation) skickad, så måste

den finnas på plats i tid. Tåget kommer inte att åka till dem, ej heller

kommer det att vänta på dem.

Detta innebär att tåget hjälper projektgrupperna att tillsammans synkronisera och

använda samma kadens på programnivå så att riskerna med projektet minimeras.

Detta uppnås genom att projektgrupperna använder gemensamma bestämmelser:

Täta, regelbundna planerings och release datum för lösningar är fasta.

Datum är bestämt, kvalitet är bestämt, omfattning varierar.

Omfattning och schema bestäms av teamen och programnivå,

decentralisering av planering.

Arbetsgrupperna använder sig av lika långa iterationer och standardiserad

hastighet för att underlätta planering och integration på programnivå.

Kontinuerlig integrering görs av alla team på programnivå.

Testade system finns tillgängliga vid varje iteration och PSI intervall.

HIP iterationer kan användas för testning och validering av versionsnivåer.

Komponenter som angår infrastrukturen så som gränssnitt och

gemensamma komponenter måste i regel planeras i förväg.

Att leda ett projekt agilt tenderar att släppa lös all den kreativitet, inre motivation

och innovativa kraft som högtravats under tidigare modeller. Det räcker dock inte,

då arbetsgrupperna kommer dras mot lokala mål. De kommer sträva för att uppnå

kraven satta av kunderna men de har inte nödvändigtvis ett globalt perspektiv. På

det sättet kan hela organisationens massa riktas i en och samma riktning och då få

betydligt större kraft att adressera problem med. (Leffingwell, 2011)

När SAFe implementeras in en organisation är en huvudaktivitet att bestämma hur

ART-domänen skall läggas upp. I mindre organisationer kan de personer som

arbetar tillsammans delas in i samma ART. I större organisationer med hundratals

individer behövs ett flertal ART. Det kan då vara fördelaktigt att rikta in alla tåg

efter samma tidsgräns för att underlätta implementeringen av epics.

Vad som bör beaktas när de enskilda tågen ska designas är:

23

Tåg fungerar bäst med 50-150 individer som arbetar mot samma primära

värdeflöde.

Grupper som arbetar med funktioner och komponenter som till hög grad

beror på varandra bör höra till samma tåg.

När det går bör arbetsgrupper som hör till samma tåg vara

samlokaliserade.

När tåget (ART) har bestämt etapplängden och de andra parametrarna kan release

datumet sättas långt i förväg. Detta sänker tiden och kostnaden normalt associerad

med release event enligt Leffingwell. Dock ger Leffingwell ingen förklaring

varför det skulle bli billigare att ha bestämda release datum. Efter att etapplängden

och de andra parametarna är bestämda tilldelas de olika roller för PSI releasen

inom tåget. Många av rollerna är även huvudansvariga för att hålla tåget på rätt

spår. Rollerna återfinns på programnivå och är:

Release train engineer (RTE) arbetar heltid och fungerar som Scrum

master för tåget.

Release train management team har relevant mandat för att ta beslut

angående omfattning och planera inför marknadssläpp för tåget (ART).

Product managers är direkt involverade och arbetar tillsammans med

produktägarna för att övervaka omfattning och resultat.

System teamet integrerar tillgångar, genomför över-linjer tester,

utvärderar överenstämmelse med icke funktionella krav samt hjälper med

systemnivås demos.

UX (user interface) designers och system arkitekter hjälper till att

stödja utvecklingen av nya funktioner genom verksamhetsinsikt.

Rapportering av fortskridning av projektet skall rapporteras till release

management team av RTE på veckobasis. RTE skall typiskt hålla ett Scrum of

scrums, ett möte där samtliga Scrum masters samlas, två gånger i veckan.

Portföljnivå - Högst upp i projektorganisationen finns ett flertal element som

tillsammans representerar portföljvisionen. Portföljvisionen reflekteras främst av

utarbetande och dedikation till främjande av organisationens affärsplan. Arbetet

sker först och främst i hantering av värdeflöden som innefattar identifikation av

värden hos primära, långlivade produkter och tjänster. Dessa värdeflöden blir

sedan implementerade i ART efter tidigare satt budget. En annan uppgift som

ligger på portföljnivå är att föra vidare arkitektur- och affärsförändringar som

krävs för att uppnå större, organisatoriska mål. I projektportföljen behandlas och

sparas även produktloggarna i en så kallad portföljlogg.

Portföljnivån motsvarar den högsta nivån för en instans av SAFe och besluten

som tas här driver den gemensamma ekonomin för projektportföljen. Därför är det

kritiskt att portföljnivån kan bedrivas på ett effektivt, agilt sätt.

24

För att vara säkra på att IT-avdelningens mål är inriktade mot organisationens

överspännande mål måste det finnas insyn i organisationens affärsstrategi. Det är

den strategin som definierar affärsmål, driver organisationsmodellen och

identifierar de stora utvecklingsinitiativen. Det är alltså portföljnivåns ansvar att

identifiera och förmedla de strategier och mål uppsatta av chefer och

verkställande styrgrupper

Det första beslutet som måste tas på portföljnivå är hur resurser skall bli

distribuerade till portföljens värdeflöden. Varje värdeflöde är en upprepande,

långlivad process som behöver upprepning av bedömning, utveckling och

distributionsprocess vilket har som mål att leverera ett system av särskilt värde.

Ibland, och speciellt i större organisationer, kan det vara svårt att identifiera

värdeflödena och då är analysen av dessa en viktig aktivitet då de kan hjälpa till

att förstå hur SAFe bäst kan implementeras.

Om ett värdeflöde involverar hundratals utvecklare är det oftast nödvändigtvis att

dela upp arbetat i flera ART. Investerings tema används som term för att beskriva

målet och mängden resurser varje ART har. Dessa teman ger portföljnivån ett

verktyg för att allokera budgeten till varje ART.

Genom att allokera budgeten för en tidsperiod uppmuntrar det ART att göra de

lokala beslut som krävs för att snabbt avancera i projektet. Detta för att ART inte

behöver gå till portföljen för att få resurserna de behöver för sitt nästa initiativ.

(portfolio Decentralization)

För att hantera de affärsstrategier som är övergripande för flertalet ARTs användes

kanbanprocesser för att övervaka affärs- och arkitektsepics. Affärs- och

arkitektsepics identifieras, analyseras och senare efter dem blivit godkända,

planeras implementeringen av dessa i portföljloggen. På så sett visualiseras värdet

på epics under hela processen från analys till implementation.

Programnivå – Det är på programnivån som flertalet av de agila

projektgrupperna synkroniseras och integreras och bildar ett gemensamt ART för

att enklare kunna skapa ett större värde åt företaget och intressenterna. För att

kunna applicera det agilatänket på programnivån behöver områdena värde, team

och timebox sättas i en större organisations perspektiv. (up-scale, blir det rätt

utryckt?)

Värde: Ytterligare områden behöver införas under värde vid stora och komplexa

system. Dessa är:

Featureprogram i produktloggen.

Visionen om vart programmet är på väg.

En karta som beskriver hur lösningar kommer utvecklas under tiden.

Team: Sättet att hantera projekt behöver fler personer och olika kunskaper.

25

Produkthantering för att slå fast vid visionen och hålla kontakten mot

marknaden.

Ett system team som knyter ihop alla mjukvarutillgångar i alla led.

Ett release team med auktoritet att definiera och utvärdera kvalitet och

release kriterierna samt koordinera faktisk release.

Timebox: Även om en timebox på 2-3 veckor fungerar utmärkt på

arbetsgruppsnivå är det alldeles för kort tid för att kunna leverera ett betydelsefullt

system för återkopplings skull. Det är därför lämpligare att lägga upp planeringen

efter PSIs som sker med jämnt mellanrum var åttonde till tionde vecka. Även om

materialet kan släppas fritt efter en sådan rytm (8-10 veckor) så att det har visats

att lösningar som släpps först när marknaden efterfrågar dem är mer lönsamma.

Därför väljer de flesta företag som arbetar med SAFe att använda dessa längre

timeboxar åt planering, utvärdering av programvaran på högre nivå samt

inspektera och utvärdera kommande förbättringar. Detta har gett uppov till ett

mantra inom SAFe; Develop on candence. Release on demand.

Det är här på programnivå som ART lämnar den metaforiska stationen. För att

hålla avgångarna i tid, se till att det håller sig på spåret och att alla delar av tåget

funkar tillsammans innehåller programnivån ett flertal roller.

Product manager som är ansvarig för det funktionella innehållet. Detta

innehåll styrs av portföljmålen, värdeflöden och klienters återkoppling.

Release management team har auktoritet att avgöra om en lösning är

lämplig för släpp och att det är en lämplig tid för att adressera affärs- och

klientbehov.

System teamet jobbar med att utvärdera och integrera den testade kod

som regelbundet levereras av arbetsgrupperna. Löpande integrering,

automatiserade testsviter och över-alla-linjer tester är verktyg som system

teamet använder för att ge snabb återkoppling till de agila teamen och

intressenterna.

Release train engineer huvudsakliga ansvar är att hålla tåget på rälsen.

Vilket kan vara en omfattande uppgift då ett ART kan innehålla 50-150

individer.

DevOps: Verkligt, påtagligt värde fås inte inom mjukvaruvärlden förrän

slutanvändaren använder sig av det i sin miljö. För att försäkra om ett

snabbare flöde av värde till slutanvändaren behövs ett sätt att arbeta nära

med slutanvändaren. Detta åstadkoms genom att integrera slutanvändare i

de agila teamen i ART. Det skall också ges förslag på hur det skall hålla

kontinuerligt beredskap gällande marknadsrelease under hela

utvecklingsarbetet. Detta ger företaget möjlighet att släppa produkten med

så hållbart kort ledtid som möjligt.

26

Inom programnivå finns det ytterligare verktyg för att stödja och underlätta

arbetet.

Program backlog är den enda definitiva platsen och innehåller allt arbete

som förväntas utföras av programnivån. Produktloggen drivs del av

portföljloggen, arkitekts-epics och slutanvändarnas återkoppling. Icke

funktionella krav finns med för att ställa krav på kvalitet, säkerhet,

stabilitet, tillgänglighet med mera.

Release planning är för PSI vad planeringsmötet i Scrum är för en etapp.

Närhälst det är praktiskt möjligt träffas alla involverade ansikte mot

ansikte över en till två dagars konvent där de delar visioner, planerar, reder

ut inbördes beroenden, PSIs på team nivå och mål på programnivå.

PSIs and Releases: Motsvarar det jämna intervall där planering,

retrospektiv, utvärdering och ofta leverns av inkrement genomförs.

Emedan det inte finns krav på exakt längd för varje PSI etapp

rekommenderar SAFe ett satt intervall på åtta till tolv veckor. Planering,

resursintegration och systemnivå utvärdering görs under PSI etappen men

frisläppning av mjukvara kan göras asynkroniskt då den styrs av interna

affärs- och externa marknadsbehov.

Inspektera och anpassa: Liknande ett teams retrospektiv genomför

programnivån en inspektera och anpassa workshop vid slutet av varje PSI.

Normalt krävs det att alla medlemmar av programnivån närvarar för att

kunna utreda hur programnivån kan förbättras. Workshopen är

strukturerad för problemlösning och använder flera olika typer av verktyg

med syftet att skapa förbättrings stories som kan läggas till i

produktloggen inför nästa PSI planering. På detta sätt blir den ständig

förbättring av programnivån en del av ART och är ett fundamentalt sätt för

hur SAFe ständigt förbättrar sin arbetsleveransförmåga.

Arbetsgruppnivå – Arbetsgruppnivån skapar processer, modeller och en

organisatorisk miljö för varje agilt team att arbeta i. Varje enskilt team är

ansvariga för att arbeta med de user stories de har i sina produktloggar under

etapper med förbestämd tidslängd. Arbetet från ett flertal team integreras sedan på

programnivå för att skapa något av större värde. För att åstadkomma detta arbetar

de efter exakt lika långa etapper. På det sättet får de en gemensam planerings och

genomförande cykel, vilket gör det lättare att vid behov planera tillsammans och

integrera tillgångar.

Inom SAFe är de agila teamen, både individuellt och kollektivt, ansvariga för

implementeringen av grundläggande agil projektledning och extreme

programming som krävs för att skapa högkvalitativ mjukvara i varje etapp/PSI.

Det är på arbetsgruppnivå vi finner den utvecklande processen för

mjukvaruutvecklingen. Då teamen skall arbeta agilt har de maximalt 7-9

medlemmar och innehåller den expertis som behövs för att skapa en klar för en av

27

mjukvarans funktioner. Teamet innehåller rollerna produktägare, Scrum master,

ett antal utvecklare, testare (DevOps) och möjligen en tech lead. I sitt dagliga

arbete assisteras arbetsgrupperna av programnivån i form av personal från

arkitekter, tech writers, supportpersonal, intern IT och vem mer det kan krävas för

att definiera, utveckla, testa och leverera fungerande mjukvara.

Roller i arbetsgruppnivån utgörs av:

Produktägare är den gruppmedlem som är ansvarig för bestämma och

prioritera användarkrav samt upprätthållandet av produktloggen.

Scrum master är den i teamet fungerar som en stödjande och skall hjälpa

teamet med deras övergång till den nya metoden och kontinuerligt

underlätta gruppdynamiken, snarare än att maximera prestation.

Utvecklare och testare: resten av teamet består av utvecklare och testare

som skriver samt testar koden. Då teamen skall hållas agila är de oftast

begränsade till 3-4 utvecklare och 1-2 testare som ideellt är

samlokaliserade och som arbetar tillsammans för att definiera, skriva, testa

och leverera stories till ART.

Verktyg och processer de enskilda teamen har till sitt förfogande är följande:

Iterationer: teamen använder sig av korta timeboxar, precis som

etapperna i Scrum, för att utveckla och leverera kod. Inom SAFe har

teamen samma start och slut på etapperna så att mognadsgraden för koden

producerad av alla team kan jämföras i slutet av varje etapp. Även om det

inte finns någon sagd längd på dessa etapper så har de flesta konvergerat

till 2 veckors etapper.

Varje iteration representerar en värdefull klar, detta åstadkommit genom

ett upprepat mönster: planera iterationen, dedikera sig till en

funktionalitet, skriva och testa kod utifrån stories, demonstrera den nya

funktionaliteten för relevant intressant, hålla retrospektiv och repetera.

Antal iterationer per PSI: Ett antal iterationer används för att generera

något av större värde, en PSI. Antalet iterationer per PSI är ett beslut som

lämnas till programnivån och bör och skall vara release on demand.

User stories är det primära sättet som för kundernas krav via värdeflöden

till faktisk skriven kod och genomförande. Tillskillnad från krav som är

något systemet måste göra, kan User stories säga att vara en

avsiktsförklaring som beskriver något som systemet behöver göra för

kunden.

28

Team produktlogg består av alla user stories som teamet har identifierat

för implementation. Varje team har en egen som sköts och prioriteras av

produktägaren. Även om produktloggen kan innehålla ytterligare saker,

defekter, omstrukturering av kod, arbete med infrastruktur med mera, så är

det user stories som bär med sig värdeflödet och är därför målet för

teamets primära fokus. Arbetet med dessa är således den primära

kravhanteringen man arbetar med.

Arbetsgruppernas arbete skall underlättas internt genom att arbetet tas till

projektgrupperna. På så sätt blir det lättare att hålla kvar samma individer i

projektgrupperna och projektgrupperna blir mer långlivade. En effekt av att

projektgrupperna behålls under en längre tid blir att projektgrupperna blir mer

sammansvetsade, effektivare och snabbare på att leverera bättre mjukvara.

Nackdelar

Det är i dagsläget svårt att hitta objektiva beskrivningar av SAFe, både för- och

nackdelar med modellen. Därför bör det poängteras att nackdelarna som kommer

tas upp här är sådana som har tagits upp av praktiker och som vi själva har sett

med modellen.

Flera led mellan arbetsgrupperna och de verkliga beslutsfattarna. –

Inom Scrum sägs att utvecklingsgrupperna skall arbeta direkt mot

produktägaren för att få en så tydlig dialog som möjligt. Inom SAFe måste

alla förändringar gå igenom ett flertal poster innan problemet når de som

har det verkliga mandatet.

User stories kan bli normaliserade mellan teamen. – Om

arbetsgrupperna tvingas normalisera sin planering finns det en risk att de

förlorar kontroll över sin egen process.

Inget enskilt team kan anpassa sig. – Genom att låsa alla team med sina

synkningar kan inte ett enskilt team anpassa sin egen process då det skulle

bryta mot ramverket.

Ingen metod för att hantera konflikter eller kulturella skillnader. –

Modellen SAFe saknar helt verktyg för att hantera de sociala aspekterna

som finns i projektmiljöer. Dessa inkluderar konflikter, skilda verklighets

uppfattningar och motivation för att nämna ett fåtal.

Processer och verktyg. – SAFe består av processer och verktyg och den

första grundsatsen av det agila manifestet lyder; Individer och samspel

framför processer, metoder och verktyg.

3. Metod

I följande kapitel beskrivs metoder för att lösa problemformulering. Kapitlet

avslutas med metodval och motivering av metodval.

29

3.1 Teoriunderlag för metodval

Intervjuer går att särskilja på två olika nivåer beroende av frågeställningen. Dessa

två kallas kvalitativ studie och kvantitativ studie. Den kvantitativa intervjustudien

eller enkät används för att reda på "hur många". Den kvalitativa intervjustudien

används istället för att få material som innehåller åsikter, beteenden och

bakomliggande tankemönster till svaren på en kvantitativ studie (Trost, 2010).

För att besvara en problemformulering är genomförande möjligt på olika sätt.

Främst genom intervjuer och enkäter men också genom observation eller

inläsning. Alla dessa benämns tillsammans som observationer (Kylén, 2004).

En enkät består av ett frågeformulär där frågorna är mer riktade än en kvalitativ

intervjustudie. I frågeformuläret eller enkäten besvaras av en enskild individ. Det

görs en datainsamling och en sammanställning av resultatet.

Inläsning kring ett ämne görs genom att ta reda på tidigare forskning. För att få

fram sådan information studeras facklitteratur, uppslagsverk på internet och

rapporter.

Eftersom denna studie görs för att ta reda på bakomliggande tankegångar och

mönster i det agila tänket hos de svenska storbankerna kommer intervju och

observation behandlas nedan.

3.1.1 Intervju

Intervju är en så kallad symbolisk interaktion mellan en eller flera människor.

J,Trost (2010) beskriver symbolisk interaktionism som en verktygslåda med

verktyg för att förstå människors känslor och beteende och hur detta påverkar

andra. Eftersom symbolisk interaktionism är en viktig del att ta hänsyn till i

intervjuer tas det upp kortfattat nedan. Symbolisk interkationism delas in i fem

beståndsdelar. Nämligen:

1. Definitionen av situationen

Beroende på hur situationen definieras medförs konsekvenser. Det innebär att

individen beter sig efter klimatet i till exempel ett samtal.

2. Att all interaktion är social

30

På samma sätt fungerar social interaktion, beroende av hur vi uppfattar den vi

integrerar med agerar vi också därefter. Detta gäller inte bara konsten att hantera

språket utan även handlingar och kroppspråk. För att undvika missuppfattningar

bör därför skoj och sarkasm undvikas

3. Att vi integrerar med hjälp av symboler,

Ord tillsammans med en definierad situation benämns som en symbol. Till

exempel att ord har gemensam betydelse för båda parter i en integration.

4. Att människan är aktiv,

5. och Att vi handlar, beter oss samt befinner oss i nuet (Trost, 2010)

Hur dessa verktyg använts beror enligt J.Trost (2010) på hur människan agerar i

nuet och att människan är aktiv. Detta tolkas som att en människa inte tillskrivs en

viss personlighet, eller hur personen kommunicerar, utan istället att individen

byter mellan roller beroende av situation och interaktion just för stunden. I ett

intervjusammanhang skulle det kunna betyda att neutrala frågor som varken

uppmuntrar eller nedslår intervjuobjektet ger neutrala svar som inte påverkas av

stämningen.

Standardisering

Standardisering kallas det begrepp som beskriver normen i

datainsamlingssammanhang. Normen i en intervju kan vara till exempel

formulering, kategorisering, utläggning och tonfall. Standardisering kan göras på

olika nivåer. En hög nivå av standardisering i en intervju menar att alla frågor har

samma genomgående mönster. Det motsatta, låg standardisering kan vara att

hänsyn inte har beaktas till detta och tonfall, kategorisering och formulering

blandas hur respondenten väljer att svara. Då är variationsmöjligheterna stora.

Strukturering

Även strukturering görs på olika nivåer. En hög grad av struktur är då intervjuaren

redan förbestämt svarsalternativ på sina frågor. Motsatsen är då istället där

respondenten får spåna fritt i sina svar.

31

Sammanfattningsvis kan tilläggas att en låg nivå av standardisering och en hög

nivå av strukturering motsvarar en kvalitativ intervju.

Anonymitet

Med anonymitet menas att respondenten har möjlighet att vara helt anonym i den

mån att namn, yrke och ursprung så som företag inte kommer att skrivas som

källa för intervjun eller i studien som helhet. Full anonymitet är desto svårare

eftersom intervjuaren ofta måste veta yrke och arbetsområde för att få den

relevant för studien. Dock kan tystnadsplikt erbjudas. Det kan också vara viktigt

att visa på att insamlad data inte kommer föras utanför studien, att informationen

är så kallad konfidentiell.

Anonymitet av alla dess slag kan underlätta att respondenten pratar mer öppet om

det berörda ämnat och kan erbjudas anonymitet i det syftet.

Intervjuplats

För att underlätta en intervju bör den ske ostört utan yttre inverkan för att hålla

fokus på intervjun. Det är därför viktigt att intervjun sker ostört och i en miljö där

respondenten känner sig trygg. Ifall en potentiell respondent ställer upp på

intervju bör därför denne också få bestämma platsen för den.

Flertal intervjuare

Är det fler intervjuare kan det vara viktigt att en person i huvudsak håller i

frågorna. Resterande används som stöd för denne och hjälper till när det behövs,

vilket är en klar fördel mot om intervjuaren är ensam. Ur respondentens

perspektiv skulle detta dock kunna rubba tryggheten eftersom denne kan känna

sig undergiven och istället se det som ett maktövertag att bli intervjuad av flera

personer.

Intervjuguide

Intervjuguide är en guide med olika samtalsämnen som är relevanta för studien.

Dessa bör vara förberedda och intränade inför intervjun. Däremot måste det inte

finnas föreberedda frågor under varje samtalsämne.

32

3.2 Metodval

Rapporten bygger på facklitteratur och uppslagsverk för att kunna besvara

frågeställningen. Följande sökord användes; Project Management, Agile projects,

Traditional projects, Projektledningsmetodik, Projekt metoder, Agila projekt,

Scrum Guide, Scale-up Agile, Critical success factors, Department of defence,

Kvalitativa intervjuer och intervjuguide.

För bedömning av tillförlitlighet har källorna jämförts mot varandra.

För att kunna svara på hur bankerna arbetar agilt har det använts en teoristyrd

tematisk analys. Det innebär att empirin ställts emot teorin för de agila metoderna

och vattenfallsmetoderna. Tydligast skillnad mellan de olika projektmetoderna

gick att utläsa i följande punkter: storlek, kommunikation, planering och

genomförande. Eftersom att de största skillnaderna mellan det traditionella och

agila återfinns inom något av de fyra områdena blir det naturligt att bygga

intervjuguiden efter dessa områden.

Storlek på projekt: Synen på projektens storlek och projektgruppernas

sammansättning ser annorlunda ut för de olika projektmetoderna. Agila

projektgrupper ska vara små, flexibla och ha hög förmåga att hantera

förändringar.

Som ett resultat av att kunna placera vart bankerna ligger i hänsyn till storlek på

projekten i det agila arbetssättet användes bland annat följande frågor:

Är storleken på projektet en faktor för att inte arbeta agilt?

Hur stora är arbetsgrupperna? (generellt)

Hur skapar ni projektgrupperna?

Kommunikation: Hur kommunikationen rörande projekten sköts har en tydlig

skillnad mellan projektmetoderna. Scrum och SAFe följer samma principer där

ska kommunikationen ske dagligen, ske ansikte emot ansikte och hela

projektgruppen ska vara närvarande vid mötena.

För att kunna svara på hur banken hanterar kommunikationen med avseende på

det agila arbetssättet var det därför av värde att ställa följande frågor:

Hur hanteras kommunikation inom grupperna?

Hur frekvent har ni möten och avstämningar inom grupperna?

Hur hanterar ni placering av deltagare i projekten?

Hur hanterar ni utspridda deltagare?

Hur hanterar ni kommunikation mellan grupperna?

Hur ofta hålls möten mellan grupperna?

Hålls möten med alla grupper och vilka av medlemmarna är då delaktiga?

33

Planering: En av de största skillnaderna mellan vattenfallsmodellen och agila

projektmetoderna är synen på planering och förändring. I Scrum och SAFe

förespråkas en planering över den närmaste tiden med användning av timeboxing.

Vattenfallsmodellen fäster grunden i långsiktigt detaljerad planering.

För att svara på hur banken arbetar agilt i förhållandet till planering resulterade i

följande frågor:

Hur går planeringen till, Vilka deltar?

Hur arbetar banken med timeboxing i förhållande till milstolpar?

Hur hanteras budgetering?

Hur ser banken på förändringar?

Hur hanterar banken förändringar under projektet?

Har de som arbetar närmast problemet befogenhet att göra förändringar

utan att gå till högre chefer?

Genomförande: I genomförandefasen skiljer involveringen av kunden och

slutanvändaren. Vattenfallsmodellen involverar kunden i slutet av projektet

medan Scrum och SAFe håller en kontinuerlig dialog med kunden och

slutanvändaren. Agila arbettsättet förespråkar en kontinuerlig testning av

produkten och att mandaten att besluta förändringar rörande projektet ska finnas

för projektdeltagarna närmast projektet.

Omfattningen på dokumentationen skiljer också. I vattenfallsmodellen fungerar

dokumentationen som ett verktyg för kommunikation och ska vara väldigt

omfattande. I det agila projektmetoderna ska dokumentationen vara kortfattad.

För att svara på hur genomförandfasen under projektet förhåller sig till den agila

projekt teorin användes följande frågor:

Beskriva hur banken involverar klienten eller slutanvändaren i projekten

Beskriva hur banken använder slutanvändarens återkoppling för

förbättring

Hur arbetar banken med kontinuitet gällande internt mjukvarusläpp?

Beskriv hur banken arbetar med dokumentation under och efter projektet.

Hur detaljerad är denna?

Hur är projektledarens mandat?

För att försöka förstå metoden hur svenska storbanker arbetar agilt i stora projekt

är det viktigt att förstå hur nyckelpersoner resonerar kring deras egna sätt att

arbeta. Utifrån detta valdes en kvalitativ metod. Kvalitativa metoder används för

att ta reda på bakomliggande tankegångar och mönster till varför personer har valt

att agera på ett visst sätt och hur. Därför förbeddes en intervju av låg

standardisering och låg strukturering (se 3.1.1 Intervju för beskrivning av denna).

34

För ökad validitet jobbar respondenterna i agila projekt- eller utvecklar metoder

för projekt hos SEB respektive Handelsbanken. Det gjordes två intervjuer hos

SEB samt en intervju hos Handelsbanken. Anledningen till det gjordes två

intervjuer hos SEB är för att täcka kompetensområdena projektledare och chef

över projektkontor. Det gjordes dock en intervju hos Handelsbanken eftersom

denna respondent jobbat väldigt länge som projektledare och har jobbat ett flertal

år som chef över projektkontoret.

Dessa kompetensområden är viktigt att fylla i intervjuerna eftersom

projektledaren ger insyn i hur projekt fungerar i praktiken och chef över

projektkontoret kan beskriver teorin bakom denna.

För att undvika att bli störda och att respondenten skall vara trygg har denne fått

valt intervjuplats. Alla intervjuer genomfördes därför på plats hos bankernas

huvudkontor i Stockholm. Alla intervjuer skedde på någon typ av konferensrum i

huvudkontoret för respektive bank.

I början av varje intervju erbjuds respondenten och banken att svara anonymt ifall

denne skulle vilja ta upp känsligare ämnen. Efter att varje samtalsämne i

intervjuguiden diskuteras ges respondenten en chans att lägga till något kring det.

För att underlätta att respondenten håller en röd tråd gjordes en karta med alla

rubriker vi tänkt prata om, det vill säga intervjuguiden. Hela metodprocessen kan

beskrivas på följande sätt:

35

Fig. 5 Förenklad bild av metoden.

Fallstudie

Studien valdes att genomföras som en fallstudie. En fallstudie definieras av

Högskoleverket som en undersökningsmetod för att nyansera, fördjupa och

utveckla begrepp och teorier genom undersökning av ett eller flera typfall. Vi

ansåg att det här var den undersökningsmetod som var mest lämpad för vår

forskning. Fallstudier har länge fått kritik då det anses att de inte kan ge insikt i

orsakssamband och generella förhållanden (Flyvberg, 2003/04). Däremot kan det

argumenteras att fallstudier fungerar utmärkt för att de lämnar kompletterande och

fördjupad insikt i de studerade fallen (Gerring, 2004). Där av valde vi denna

undersökningsmetod då det vi var intresserade av var en fördjupning i de fallen

som tas upp i denna rapport.

36

4. Empiri

4.1 SEB

Det som är viktigt att veta kring empirin för SEB är att intervjuerna omfattar två

personer med olika uppgifter och således kan deras uppgifter variera. Den ena var

högt uppsatt projektledare och den andra chef för SEBs projektkontor.

Bilden nedan är till för att ge förståelse för hur SEB arbetar med sina agila

projekt.

Projektkontoret övervakar projektportföljen.

PL: Projektledare.

RM: Release manager.

TL: Testledare.

ST: Scrumteam.

Fig. 6 Förenklad bild på hur SEB jobbar med agila projekt.

Det är viktigt att beakta att SEB är i en tid av reform, då införandet av de agila

metoderna skedde cirka 1½ år innan studien är gjord. När SEB införde agila

metoderna i banken släpptes arbetssättet fritt på arbetsgruppnivå, utan några

gemensamma riktlinjer för hur arbetet skulle bedrivas. Som ett resultat av detta

varierar de olika projektgruppernas arbetssätt. Detta skapar problem för

projektledaren då det saknas en bestämd sprintlängd och plan på hur

kommunikationen skall skötas inom banken. Därav blir det svårt att synkronisera

projektgrupperna och projektledarens arbete blir således att sköta gränssnitten

37

som skapas mellan Scrumteamen. Ju fler team som involveras i dagsläget desto

komplexare blir projektet, eftersom projektet får fler gränsytor att förhållas till.

Bilden nedan skall ge en bild för hur kommunikation sköts i de agila projekten

hos SEB. I bilden nedan skall de röda markeringarna (markeringarna mellan ST)

visa på den bristande kommunikationen och synkningen mellan Scrumteamen i

projektet. Den gröna (markeringen mellan PL, RM ,TL ner till ST) skall visa att

det faller på projektledaren och eventuell RM att synkronisera och sköta

kommunikation mellan teamen.

Fig. 7 Visualisering av kommunikation i agila projekt.

Storlek på projekt

Storleken på projekten har ingen inverkan på ifall projekten ska bedrivas i agil

form eller inte utan det är snarare komplexiteten. Även om komplexa projekt

automatiskt inte behöver bedrivas agilt. Oftast är det vissa avgörande faktorer som

gör att projektet väljs ifall det ska bedrivas i agil- eller klassikform.En avgörande

faktorer till att projekten inte genomförs agilt kan exempelvis vara att projekten är

vad SEB kallar för mandatory projekt (för SEB betyder det att det är projekt som

är obligatoriska på grund av till exempel uppdrag från EU). En anledning till att

köra agilt kan vara att projektet är litet eller att det finns stor sannolikhet att

förutsättningar eller krav kommer förändras under projektets gång.

38

SEB tilldelar inte projektledaren en arbetsgrupp efter affärskunskap eller

erfarenhet. SEB ägnar inte någon större tanke på hur projektledarna ska fördelas

mer än att projektledaren ska tillhöra ett team och att teamet inte får vara för stort,

SEB vill inte äventyra projektledarnas förmåga att kunna ha utvecklingssamtal

eller liknade samtal med projektets deltagare.

SEB har dock tankar på att börja dela in projektgrupperna efter erfarenhet och

kompetens. Speciellt vid mandatory projekt eller projekt från en annan instans där

projekten oftast är tidsmässigt tvingat att leverera samtidigt som det är högt ställda

krav. Det finns en känsla på SEB att dessa projekt bedrivs på ett speciellt sätt

jämfört med andra projekt i banken och därför skulle det kunna underlätta att göra

en gruppering som fokuserar på denna typ av projekt.

Enligt respondenten på positionen projektledare varierar SEBs storlek på

projektgrupperna men som exempel på ett projekt som bedrivs i banken jobbar en

projektledare emot tre Scrumteam där varje Scrumteam vanligtvis innehåller

mellan 6-15 personer. Å andra sidan finns det andra projekt där en projektledare

jobbar med 18 Scrumteam.

SEB går allt mer ifrån stora-, resursslukande- och tydligt kravspecifika projekt.

Istället försöker SEB bryta ner projekten och göra mindre satsningar. SEB

hänvisar till statiskt från Standish Group Chaos manifesto 2013 som generellt

visar att projekt mellan 10-20 miljoner kronor ofta genomförs lättare. Standish

Group har kartlagt att projekt där budgeten uppgår till ca 1 miljon dollar (7 mkr)

tenderar att bli lyckade i 80-90 % av fallen (levererad i tid och på budget) kontra

projekt med en budget på 10 miljoner dollar (70 mkr) och uppåt där enbart 7 % av

projekten att lyckas. Baserat på denna studie försöker SEB att stycka ned

projekten.

Att lyckas skala ner projekten är dock svårt eftersom affärssidan inte delar samma

synsätt, när affärssidan vill förändra/utveckla en produkt som är av värde inför de

oftast extra önskemål som ursprungligen inte fanns på kravlistan. SEB vill börja

prioritera tydligare för projekten och leverera det som är det viktigast för

projektet. SEB är inte riktigt där i dagsläget men jobbar aktivt med det tankesättet.

Kommunikation

Hur kommunikationen fungerar inom de olika Scrumteamen ser sannolikt väldigt

olika ut i banken. Enligt respondenten med positionen projektledare hanteras den

absolut största andelen av bankens Scrumteam kommunikationen platsbaserad och

ansikte mot ansikte. Scrumteam som har kommit långt använder dagliga

avstämningsmöten eller tavlor som visualiserar vad som gjorts, görs och skall

göras. Banken har även utvecklare placerade i Litauen och dialogen med de

utvecklarna baserade i Litauen framförs genom telefon eller virtuellt delade

tavlor. Frekvensen på avstämningsmötena varierar för Scrumteamen, en del

Scrumteam har dagliga möten medan andra team har veckomöten.

Hur kommunikationen ska fungera inom Scrumteamet är inte helt färdigställt men

SEB försöker hitta en struktur där produktägaren ska föra en aktiv dialog med

Scrum master. Mycket av hur dialogen ska skötas inom Scrumteamet är upp till

egna teamet att bestämma. Eftersom att SEB har noterat att projekten som har

39

engagerade produktägare som spenderar mycket tid i projekteten lyckas i högre

utsträckning än de projekt som har en oengagerad produktägare försöker SEB att

få produktägaren att bli mer engagerade i projekten.

SEB har i dagsläget ingen utarbetad modell eller metod för hur kommunikation

mellan de olika Scrumteamen ska se ut. Kommunikation mellan de olika

Scrumteamen sker genom projektledaren och eventuellt release manager.

Synkningen mellan de olika Scrumteamen blir väldigt lidande som följd av detta

och banken är underförstådd med att det måste finnas någon typ av transparens för

alla led.

I och med att det inte finns någon bestämd modell för hur kommunikation skall

skötas varken inom eller mellan grupperna är det ett problem att få till

kommunikation i projektet. Det faller då på projektledaren och eventuell release

manager att få teamen att synkronisera och tala med varandra. Detta försvåras

ytterligare då banken även har personal i andra länder.

I samband med att SEB började implementera det agila arbetssättet upprättade

SEB ett projektkontor. Projektkontoret använder sig av veckomöten för att överse

projekten som utförs i banken. SEB har även delat in projektkontoret i olika

grupperingar, där en grupp fokuserar på att genomföra implementeringen av de

agila metoderna i banken och för en dialog med projektledarna så att

projektledarnas åsikter noteras. En annan grupp studerar hela bankens

projektportfölj och analyserar vilka projekt som är genomförbara så att inte

likartade projekt samkörs.

Innan projektkontoret upprättades saknades rapportering och känsla för hela SEBs

projektportfölj och uppsikten över projekten har varit utspridda på olika personer.

Efter projektkontorets etablering har SEB ett samlat grepp på alla projekt och

banken får en konstant statusuppdatering på projekten som bedrivs i hela banken.

Med hjälp av projektkontoret visualiseras också efterfrågan från affärssidan samt

bankens kapacitet så att banken effektivare kan leverera vad banken efterfrågan

samtidigt som flaskhalsar för banken åskådliggjorts.

Kommunikationen på banken missgynnas av den skilda synen inom bankens olika

delar. Affärssidan har en mer öppen dialog och en konstant interaktion mellan

människor och fokus ligger mot kunden. IT-sidan är mer sluten och fokus ligger

på att utveckla systemen kunden önskar.

Planering

Planeringsarbetet i banken genomförs av projektledaren och en intern arkitekt.

När de behöver en tidsuppskattning för en uppgift kontaktar de det team som har

relevant kompetens och får således tidsuppskattningen av de som troligen kommer

genomföra arbetet senare. SEB gav tidigare uppgiften till varje enskilt

systemområde att strukturera upp deras egna agila planering. Nu försöker SEB att

strukturera upp gemensamma riktlinjer för hela organisationen. Många på banken

arbetar fortfarande med att göra väldigt omfattande kravspecifikationer och det är

just denna del som är svår för banken att luckra upp. Banken är väldigt fastkörda i

att projekten måste ha en tydlig kravspecifikation och vara planerade lång tid

framöver istället för att planera den närmaste tiden, här har SEB en väldigt stor

utmaning enligt chefen för projektkontoret. Planeringen har idag generellt mer

traditionella drag som planering efter milstolpar och affärsbeslut.

40

Ett annat problem som banken har är att arbetssättet skiljer mellan de olika Scrum

teamen. Detaljnivån på kravspecifikationerna och längden på etapperna varierar

för varje enskilt Scrumteam. SEB försöker styra Scrumteamen mot användandet

av user stories. En del projektledare har anammat det nya tänket men det är

fortfarande svårt att genomföra då projektledarna måste övertyga affärssidan att

planera kortsiktigare.

Det är viktigt för banken att kunna förutse värdet för banken att genomföra ett

projekt. En division i banken får en bestämd mängd pengar och för dessa pengar

vill divisonen se vad värdet blir av de pengarna som investeras i projekt.

Divisonen får en uppfattning av vad som ska levereras men egentligen går det

bara att förutspå vad som ska levereras inom de närmsta fyra-fem månaderna.

SEB har utvecklat en projektstyrningsmodell som kom fram första gången för 1 ½

år sedan i samband med reformen till agila modeller. Projektstyrningsmodellen är

anpassad efter det agila arbetssättet och med den nya projektstyrningsmodellen

räcker det i implementeringsfasen att planeringen är specifik för den närmaste

tiden. Om projektet skall gemomföras erhåller projektet pengar för den planerade

sträckan och när det planerade sträckan är genomförd framläggs en ny planering

och projektet erhåller nya pengar. SEB försöker med projektstyrningsmodellen att

styra åt en suggestiv planering och budget. Det är projektledaren som har till

uppgift att följa upp budgeten månadsvis.

Budgeteringen för projekten sker alltid i årscyklar, även om projekten sträcker

över flera år. När budgeten för ett projekt ska fastställas cirkulerar budgeten flera

varv i banken. Ska till exempel IT-sidan utveckla en ny mjukvara cirkulerar

budgeten mellan IT-sidan och affärssidan. Om förändringar eller andra hinder

uppstår i projektet och budgeten behöver utökas kan det bli svårt då

budgetprocessen involverar flera parter.

I dagsläget ser det i SEB ut som så att 85-90 % av alla Scrum team planerar in 100

% aktivitet under etappen. Något som har tagits upp många gånger är huruvida det

skall finnas riktlinjer för hur planeringen av aktiviteter skall se. Ett förslag är att

etapperna enbart ska planeras till 70 % och lämna resterande till att arbeta ikapp

förseningar och testa nya lösningar, för att på så sätt öka kreativiteten inom

banken.

Genomförande

Tidigare har förändringar på projektets krav under genomförandefasen haft en

negativ innebörd. När kraven för ett projekt är satta har kraven ansetts vara heliga

och inget som ska omarbetas. Budgeten har tillåtits att ändrats men inte

projektkraven. I dagens läge har projektledarna ändrat uppfattningen att kraven

måste få tillåtas att ändras vid behov.

Tidigare var banken indelade i olika divisoner. När en divisons resurser tog slut

var det inte divisonen som fick prioritera vad som skulle genomföras, utan det var

snarare IT, det verkställande organet, som tog beslutet vad som skulle prioriteras

då. Sett ur ledningsperspektiv ansåg respondenten på projektkontoret att detta är

helt galet då banken måste utgå efter vad som är bankens bästa. För att motverka

att divisionerna slogs om samma resurser ersatte SEB divisionerna med

41

compartments. Compartments delar in banken efter arbetsuppgifter till exempel

arbetar compartment Wealth med betalningar. Om det sker en stor förändring

under projektet diskuterar deltagarna inom varje compartment vad som ska

prioriteras.

Efter att SEB implementerade de agila metoderna gjorde banken om hur

projektgrupper struktureras upp. Tidigare, i klassiska vattenfallsprojekt, har

banken gått in i varje enskilt system och tagit ut den kompetens som behövs för

att genomföra projektet. Det var således ingen garanti att projektdeltagarna

återgick till förvaltningen efter projektet, särskilt efter längre projekt. Istället

kunder projektdeltagarna förflyttas mellan flera olika projekt och därmed kunde

viktiga kunskaper för förvaltningen försvinna och erfarenheterna från projektet

återfördes inte till systemet. Idag i de agila projekten lämnar inte

projektdeltagarna förvaltningen, utan några deltagare från förvaltningen ansvarar

för genomförandet av projektet, projektet ses i dagsläget som en extra

arbetssyssla. Personerna som förvaltar projektet varierar med tiden efter ett

rullande schema. På så sätt får flera deltagare erfarenheter om produkten som har

utvecklats samt att alla får projektvana.

Denna utveckling har haft både positiva och negativa effekter för personerna som

ansvarar för förvaltningen. Några anser att projekten kommer in och stör för

förvaltarnas vardagliga sysslor medan några uppskattar möjligheten att arbeta i

projekt. För banken som helhet har den nya utvecklingen av hur förvaltningen ska

genomföras fått en positiveffekt. Eftersom personerna som ansvarar för den

färdiga produkten har fått direkt kunskap om produkten under utvecklingsfasen.

Däremot använts fortfarande traditionella projektgrupper vid mandatory projekt

på grund av komplexiteten i organisationen i dagsläget, och eftersom förseningar

inte är ett alternativ vid mandatory projekt.

Om förändringar i projektet sker har deltagarna i Scrumteamen mandat att fatta

beslut rörande tekniska förändringar i projektet. Vid förändringar av större

karaktär är det alltid på styrgruppsnivå som besluten fattas.

Kunden och projektbeställare involveras i en högre utsträckning i dagsläget.

Tidigare har de involverats huvudsakligen i projektets kravspecifikation, nu

försöker SEB att behålla dem genom hela utförandet av projektet. Detta har

förändrat lite hur de arbetar med krav. Förr var kraven extremt detaljstyrda när de

lämnades över till IT från beställaren, idag försöker de gå mot en mer successiv

planering. SEB engagerar produktägaren (kunden) i projektet genom att

kontinuerligt under projektet redovisa en klar för produktägaren för att undvika att

utveckla en produkt som kunden inte vill ha.

Kundens, och ofta tillsammans med projektsponsorns återkoppling tillförs

projektet genom retrospektiv i slutet av varje sprint och det är projektledaren som

ansvarar för att retrospektivet genomförs.

42

SEB har enligt respondenten alltid varit bra på att utföra tester på utvecklad

mjukvara. Detta görs på olika sätt beroende på storlek på projektet och arbetet

som utförs. Om det är ett väldigt stort projekt eller att det är tester som sträcker

över ett flertal månadsskiften kan projektledaren få en testledare och ett team

enbart för tester till förfogande. Om det är mindre projekt är det däremot oftast

förvaltningen själva samt möjligen slutanvändaren eller en mindre testpanel som

är med och testar produkten.

Enligt respondenten, projektledaren, har SEBs arbetsmodell krav på en viss

dokumentation under projektet men efter att projektet är slutfört finns det inget

krav på att dokumentationen måste sparas. SEB har införskaffat databaser där

varje projekt ska bevaras. SEB har också börjat med att samla alla projektledare

en gång i månaden där projektledarna håller muntliga föredrag och delar

erfarenheterna som har införskaffats under projekten.

4.2 Handelsbanken

För Handelsbanken har enbart en person blivit intervjuad. Denna person är chef

för projektkontoret på IT för Handelsbanken och har tidigare jobbat som

projektledare.

Andelen agila projekt har för Handelsbanken de tre senaste åren ökat från 18 %

till strax över en fjärdedel. Enligt tabellen 1:

År 2011 2012 2013

Andelen agila

projekt (%) 18 20 26

Tabell 1 Visar andelen agila projekt hos Handelsbanken från 2011 till 2013. (Ref.

Conny Johansson, Handelsbanken 2014).

De projekt Handelsbanken definierar som agila måste uppfylla tre krav. Delvis att

projektgruppen jobbar aktivt med en product backlog, som skall prioriteras inför

varje sprint. Dessa sprintar skall vara definierade efter innehåll och vara tre till sex

veckor, och delvis att arbetet sker med regelbundna möten. Dessa möten behöver

inte ske varje dag men det bör göras om det är möjligt.

Bilden nedan är till för att ge förståelse för hur Handelsbanken arbetar med sina

agila projekt.

Projektkontoret övervakar projektportföljen.

PL: Projektledare.

PÄ: Produktägare.

RÄ: Resursägare.

ST: Scrumteam med Scrummaster.

43

Fig. 8 Visualisering av kommunikationsvägar i agila projekt hos Handelsbanken.

Storlek på projekt

Storleken på projekt är inte en faktor för att inte jobba agilt hos Handelsbanken.

Däremot anser respondenten att Scrumteamen inte bör innehålla fler än 8

medlemmar. Kostnaden är inte heller en faktor för att inte arbeta agilt. Istället

menar Handelsbanken att kort ledtid är en framgångsfaktor för att lyckas med

projekt generellt. Detta eftersom det kan komma upp störande moment efter

projektets gång, såsom nya krav och att omvärlden förändras. Då kan den långa

ledtiden leda till att projektet misslyckas och kan brytas upp i mindre enheter och

det som från början var ett projekt blir flera nya.

En framgångsfaktor för att lyckas med att arbeta agilt är att projektet har ett rörligt

krav-scope. Med detta menas projekt där kraven inte är konkretiserade direkt från

start, eller tenderar att ändra sig under projektets gång. Då kan det vara större

chans att lyckas ifall projektet bedrivs efter en agil metod istället för en

sekventiell sådan.

Mål på längre sikt tenderar dock för att bli allt för komplext för att arbetet ska ske

i projektform, där sker arbetet istället i så kallade program som består av flera

projekt som strävar mot samma mål. Projekten skall gemensamt nå upp till

programmålet.

I ett program kan projekt komma till allt eftersom programmet fortgår. Speciellt i

förstudien där projekt arbetar i utredningar med krav som blir alltför komplexa att

hantera i ett projekt. I dagsläget har Handelsbanken 6-7 program igång.

Kommunikation

Det finns tre viktiga roller som brukar kallas för midjan i projekt hos

Handelsbanken. Dessa är projektledaren, beställaren och projektansvarig

linjechef(resursägare). För att lyckas i projekt är kommunikation och gott

samarbete mellan dessa tre en mycket viktig förutsättning enligt Handelsbanken.

Eftersom det tillsätts resurser från förvaltning underlättar det för överlämnandet

44

av produkten projektet ger. Resursägaren verkar ju då över resurserna som tillsätts

i projekt från sin organisation. Behöver då projektledaren fatta ett beslut om

resurser måste denne ta frågan till resursägaren, det är även så projektledarens

mandat fungerar.

”Och att man tillsätter resurser från själva organisationen. Så att det är väl lite så

mandatet är. Man har inget mandat att liksom gå ut och hämta resurser extra och

sådär själv, utan då går man till den personen som har det ansvaret att säkra

resurser.”- Conny Johansson, chef projektkontor Handelsbanken, 2014-04-03.

På Handelsbanken kommunicerar Scrumteamen genom så kallade daily scrums,

baserat efter Scrum guide. Det innebär att Scrumteamen kör dagliga möten där

gruppen uppdateras om vad som är gjort och vad som skall göras. För att hålla

kommunikationen mellan Scrum teamen i större projekt hålls möten på

veckobasis. Där samlas Scrum mastrarna från varje team tillsammans med

projektledare, projektansvarig linjechef och eventuellt programledare. Detta för att

behålla synkroniseringen och transparensen i projektet. För att underlätta

kommunikationen sker möten på plats. När detta varit omöjligt har det tidigare

använts en typ av projekttavla med delad skärm för att visa vad som är gjort, vad

som är under genomförande samt vad som skall göras. Utöver detta användes

även telefon för mötena. Om det är ett större projekt som bedrivs agilt involveras

även projektledare och programledare för att synkronisera grupperna att arbeta

mot det gemensamma målet.

Tavlor för att visualisera arbetsuppgifter används primärt i förvaltning hos

Handelsbanken. Det används inte i varje projekt men dyker upp i en del av dem.

Handelsbanken tittar på olika verktyg att hantera dessa och backlogs elektroniskt,

men detta existerar inte för tillfället. Vanligaste verktyget för att hålla vad som har

gjorts, görs och skall göras synligt är vad banken kallar för Scrum-tavlor. En

fysisk tavla med post-it lappar för varje aktivitet som flyttas mellan fälten har

gjorts, görs och skall göras beroende i vilket stadie aktiviteten är.

För att underlätta kommunikation och transparens har Handelsbanken en databas

för att söka i tidigare projekt. Där hamnar alla slutrapporter och det går i ett senare

skede att utläsa vad som har varit framgångsfaktorer för projekt och vad som varit

mindre bra. För att hitta i denna databas taggas till exempel den använda metoden;

sekventiell eller agil, hur mycket projektet kostat och projektnamn. För att hitta i

denna databas taggas till exempel den använda metoden; sekventiell eller agil, hur

mycket projektet kostat och projektnamn. Dessa filer får projektledare testledare

och kravledare tillgång till i strävan efter en lärande organisation, så att

Handelsbanken drar lärdom av misstagen, menar respondenten.

Generellt tycker respondenten att kommunikationsspridingen är mycket viktigt för

att ha roligt och att lyckas i agila projekt. Den agila kommunikationsspridningen

ger ett naturligt kommunikationsflöde där alla projektmedlemmar känner till vad

som sker. De dagliga mötena där problem och framgångsfaktorer kartläggs gör att

problem bulbblar upp.

”Det är inget som ligger som en sur deg utan att det kommer upp på något sätt.

Och just kommunikationsspridningen som många lyfter upp som en viktig del och

45

att det är kul.”- Conny Johansson, chef projektkontor Handelsbanken, 2014-04-

03.

Planering

För att kunna tillfredsställa alla intressenter kring projekt görs en långsiktig plan

inför alla projekt. När Handelsbanken arbetar agilt sker detta på en grövre nivå.

Detta görs av erfarna projektledare, utvecklare och testare från verksamheten som

skall arbeta i projektet. Denne kommer in som en resurs från

organisationen(resursägare) för att bottna de kraven som är ställda av en

kravställare i det aktuella projektet. Skall exempelvis ett nytt bankomatkort

utvecklas sätts ofta någon från den verksamheten i projektet som vet vilka resurser

som krävs för att kraven för projektet skall bli uppfyllda.

När kraven är beskrivna färdigställs den grova planeringen med fördelning av

resurser och bemanning för kommande projekt. Då diskuteras vilka projektledare

som kommit loss från projekt och vilka projekt som skulle kunna passa för en

specifik individ, utan att denne får för mycket arbete men att det fortfarande blir

utmanande. Detta sker på portföljnivå med möten på veckobasis. Under projekts

gång arbetar portföljnivån även med problem som har dykt upp i olika projekt

som inte går att lösa på team-nivå. Då använder Handelsbanken sitt verktyg för

riskanalyser.

Fig. 9 Grov planering för hela projektet från portföljnivå.

Detaljplaneringen i projekt sker dock på arbetsgrupp-nivå inför varje intervall.

Där bryter arbetsgruppen ner den grova planeringen som gjorts i förstudien för att

sedan planera för sprinten. Detta sker succesivt under hela projektet.

Fig. 10 Detaljplanering sker för varje sprint på teamnivå.

För att hålla koll på om projekten följer den grova planerna från portföljnivå och

de mer detaljerade planerna på team-nivå har Handelsbankens projektkontor ett

möte varje månad där de går igenom läget för varje projekt. Detta resulterar i en

gemensam progressrapport innefattande alla dessa. Dessa rapporter är inte

speciellt djupodlade utan är snarare rapporter som koncist beskriver läget i varje

projekt.

Grov plan för hela projektet

Sprint Sprint Sprint Sprint Sprint Sprint

Sprint Sprint Sprint Sprint Sprint Sprint

46

Fig. 11 Projektkontoret har Scrum of Scrums varje vecka samt möte för

lägesrapport varje en gång per månad för kontroll av samtliga projekt.

Genomförande

För att kraven skall motsvara kravställarens förväntningar används

verksamhetsresurser från den verksamhet arbetet skall förvaltas i. Kravställaren är

med under projektets gång för att testa och ge direkt feedback så att produkten

kommer att fungera som förväntat. För att underlätta förvaltningen och

acceptanstester finns det en strävan att ha förvaltningsresurser med i

projektgenomförandet, tidigare nämnd som projektansvarig linjechef eller

resursägare. På så sätt sker ingen överlämning till förvaltningen. Det är inte alltid

det går, men det är något Handelsbanken trycker väldigt hårt på. Speciellt om

banken bygger nya system, eller göra stora förändringar. Gör banken små

förändringar så kan förvaltningsresursen komma in på slutet. För att då ta över

överlämningen av dokumentation och mjukvara.

Under projektets genomförande fryses kraven vid en specifik tidpunkt.

Sannolikheten att kraven ändras mycket är en avgörande faktor som

Handelsbanken tar hänsyn om banken ska använda en sekventiell eller agil

projektarbetsform. Tenderar kraven att förändras mycket under projektets gång

kan det alltså vara idé att arbeta agilt eftersom detaljplaneringen sker allt

eftersom.

För förändringshantering har Handelsbanken ett verktyg som stöd. Skulle till

exempel beställaren vilja veta vad ett nytt krav innebär för projektet rent

ekonomiskt och tidsmässigt, används verktyget för denna typ av analys. Skulle det

ändå vara svårt att avgöra huruvida läget är i projektet anlitas en oberoende part

med huvuduppgift att få upp fokus där det saknas. Anledningen till att

Handelsbanken anlitar en oberoende part är att Handelsbanken menar att

processen att fatta beslut blir förenklad då denne person inte är färgad av

omgivininge. Undersökningen presenteras för beställaren eller produktägaren och

denne fattar beslut. Beslutet resultera i att projekt stoppas om det inte går att lösa

problemet eller förändringen på ett tillfredställande sätt.

Förändringar och problem som inte berör krav från beställare utan kanske istället

arbetsgruppen som sådan, fattar dem som är närmast problemet beslut.

Handelsbanken har som filosofi att fatta beslutet så långt ner som möjligt i

organisationen, så att den som förstår förändringen eller problemet även får

handskas med det. Skulle arbetsgruppen vara oense fattas inte beslut och frågan

bubblar upp igen.

Angående resurserna kan det dock inte sägas att Scrum mastern eller en team

medlem som fattar beslutet om resurser, trots att de ofta ligger närmast problem i

projekt. Då återkommer vi istället till ”midjan” i projektet som beskrivits tidigare,

nämligen; projektledaren, beställaren och projektansvarig linjechef(resursägare).

Mandatet beror av kommunikationen mellan dessa eftersom projektledaren kanske

definierar problemet, medan projektansvarig linjechef som är resursägare, klargör

problemet och produktägaren tar beslutet. På så sätt får då projektledaren verka

indirekt genom produktägaren för att handskas med problem. På samma sätt

fungerar det om produktägaren kommer med nya krav på produkten. Då fastställs

kravet i verktyget och hos resursägaren. Projektledaren får då fram vilka resurser

47

som behövs för det nya kravet. Den nya tiden och nya kostnaden presenteras

sedan för produktägaren som får fatta det slutgiltiga beslutet.

Ambitionen för Handelsbanken är att efter varje intervall skall något kunna visas

upp som representerar vad som presterats för produktägaren. Detta görs genom

demos eller när något är färdigt för produktionssättning. En annan ambition de har

är att varje Scrumteam skall innehålla utvecklare, testare och kravare, det vill säga

alla delar för att få ut något komplett direkt från varje team. Då blir det betydligt

lättare att få kontinuerlig feedback och transparens enligt respondenten.

Under genomförandet vi stödjer chefer över portföljen projektledaren under hela

projektets gång. Projektledaren har en personlig kontakt dessa chefer och kan

direkt be om vägledning ifall denne skulle fastna. Denna modell är extra nyttig då

oerfarna projektledare som tar steget att köra större projekt, då är det ännu

viktigare att ha en stödjande personen. Denna stödjande person från

projektportföljen är alltså till för att coacha, stödja, indirekt hjälpa och komma

med förslag till projektledaren. Det är dock inte av chefen över projektledarens

intresse att själv gå in och göra förändringar projekten.

5. Analys

Det här kapitlet kommer att använda en teoristyrd tematisk analys där empirin

kommer att ställas emot teorin för att kunna svara på hur bankerna arbetar agilt i

multiprojektmiljöer.

5.1 Storlek

Scrum guide säger att ett team bör innehålla mellan 3 till 9 utvecklare och enbart

ett team för projektet. Teamet skall innehålla all den kompetens som krävs för att

slutföra projektet (Schwaber & Sutherland, 2011).

SAFe modellen säger däremot att ett team bör innehålla 5 till 9 utvecklare och

testare. På projektnivå säger SAFe att projekten bör hållas inom 50 till 150

individer. Om projektets komplexitet däremot kräver ytterligare resurser delas

projektet upp det i flera tåg, dessa efter kompetens och målområde. På team nivå

behöver inte all kompetens finnas för att ett projekt ska slutföras, utan det är

därför tåget finns där alla delar integreras(Leffingwell, 2011).

5.1.1 SEB

Empirin visar att vid agila projekt inom SEB får projektledaren ett antal

Scrumteam och möjligtvis en release manager och testledare tilldelade till sig, där

48

varje Scrumteam består av 6-15 individer och teamen är indelade efter

kompetensområde. Projekten hos SEB kan innehålla allt från 3 till 18 Scrumteam

under projektledaren.

SEBs projektkontor försöker att skala ner projekten och hålla dem under 7

miljoner kronor. Men affärssidan har ett annat synsätt på projekt, oftast när de

beställer något kommer det ofta med överflödiga krav som drar upp tid och

kostnad för projektet.

SEB eftersträvar att storleken inte skall vara en anledning för att köra agilt. Utan

det är snarare komplexiteten som bestämmer ifall projekten bör utföras agilt eller

inte. Detta är en följd av att det ser så olika ut i Scrumteamen så när projektet får

för många gränsytor att förhålla sig till blir det svårt för projektledaren att styra

projektet. Det som gör det svårt för projektledaren är bristen på styrning som är en

direkt följd av att det inte finns några riktlinjer för kommunikation och längd på

sprinterna. Idag finns det dock projekt som utförs/utförts med upp till 18

Scrumteam efter deras agila modell.

Hos SEB är det så stor variation i deras agila projekt att det är svårt att ge en

generell bedömning. Men rent allmänt är SEBs Scrumteam större än de

rekommendationer som både LSS och SAFe ger.

Gällande projektgruppens kompetens är de organiserade likt SAFe och LSS är

uppbyggt, att varje grupp ansvarar för en särskild kompetens.

5.1.2 Handelsbanken

Handelsbanken har gällande storlek på projekten liknande drag med Scrum guide.

Scrumteamen för Handelsbanken skall helst inte innehålla fler än 8 medlemmar.

Ur ett ekonomiskt perspektiv finns det inte någon begränsning huruvida projekten

skall bedrivas agilt eller inte. En avgörande faktor för att bestämma om projekten

skall bedrivas i agil form är exempelvis projektens krav. Ett projekt där kraven

tenderar att förändras under genomförandefasen kan för banken vara optimalt att

bedriva agilt. Det finns således ingen bestämd gräns inom banken som bestämmer

huruvida ett projekt skall bedrivas agilt eller inte. Dock så har det inom banken de

tidigare åren generellt varit relativt små projekt som har bedrivits agilt men det

senaste året (2013) bedrivs en del stora projekt i agil form. Det är något som

återfinns i Scrum guide, LSS och SAFe, att metoderna anses bra för projekt med

rörliga krav.

Handelsbankens större projekt innehåller även ett flertal roller som återfinns i

SAFe; testledare och programledare. De har även vad de kallar för midjan av

projektet, den utgörs av projektledaren, projektbeställare och projektansvarig

linjechef. Att dessa tre har ett bra samarbete anses viktigt för projektets framgång.

I något av de större projekten var det uppemot 50 deltagare, då utspridda i flera

Scrumteam som samordnars med ett Scrum of scrums möte. Här finns det

likheterna med SAFe. SAFe har systemen med 50-150 projektdeltagare och

projektdeltagarna är uppdelade i flera team som synkroniseras med Scrum of

Scrums möten.

49

För mål och visioner som sträcker sig över en längre tid och innehåller flera olika

projekt går under benämningen program och delas upp efter verksamhetsområde.

Detta kan liknas vid SAFe – modellen där projekt delas upp i flera tåg efter

kompetensområde.

5.2 Kommunikation

Kommunikationen i Scrum guide sköts inom projektgrupperna genom dagliga och

platsbaserademöten (Schwaber & Sutherland, 2011). SAFe följer samma principer

inom projektgrupperna, mellan de olika projektgrupperna ska kommunikationen

underlättas med att arbeta efter lika långa iterationer inom hela företaget. För att

synkroniserar arbetsgrupperna används också Scrum of Scrums samt RTE och

release managers. Inom SAFe är det projektkontorets uppgift att förmedla

företagets affärsmål och företagets visioner till projekten som skall genomföras

(Leffingwell, 2011).

5.2.1 SEB

Hos SEB är kommunikation ett genomgående problem just för att de släppte den

agila organiseringen fri på teamnivå. Varje team har sitt eget sätt att sköta

kommunikation inom teamet och det finns inget bestämt system för att sköta det

mellan teamen. Det är upp till projektledaren att få en dialog med alla team och

även att få dessa team att kommunicera med varandra. Detta är dock prövande då

det skiljer sig från team till team hur öppna de är till projektledaren. På

arbetsgruppsnivå följer de flesta team Scrum guide med täta möten ansikte mot

ansikte som överses av en Scrum master. Däremot ser vi skillnader mot LSS och

SAFe där det finns utarbetade metoder och projektroller för att hantera detta.

På grund av att det släpptes fritt så varierar det från grupp till grupp med

frekvensen för avstämningsmöten. Några Scrumteam har dagliga möten medan

andra använder veckomöten. Det är inte det enda som skiljer sig rörande intern

kommunikation för teamen, vissa team låter inte projektledaren vara med alls på

sina möten medan andra tillåter dem vara med och föreslå förändringar etcetera.

Även om vi inte hittar den traditionella projektledaren inom LSS och SAFe skall

det alltid finnas en motsvarande roll med i mötena eller på annat sätt ta del av

informationen.

Projektkontoret har i SEB översikt över hela projektportföljen och använder sig av

veckomöten för att granska alla bankens projekt. Projektkontoret visualiserar även

affärssidans efterfrågan, något som IT tidigare inte haft tillgång till. Om något av

intresse uppdagas förs sedan en dialog med ansvarig projektledare. Vi hittar

tydliga liknelser med SAFe i användandet av ett övervakande projektkontor.

50

Implementeringen av ett projektkontor har för SEB hjälpt till att förmedla

affärssidans mål och visioner till IT sidan. Här finns en tydlig koppling till SAFe

där portföljnivån skall hjälpa till att förmedla företagets visioner och mål till

arbetsgrupperna.

Angående kommunikationen är det svårt att säga något generellt då det inte finns

några bestämmelser eller modeller inom banken och varje grupp gör lite som de

själva vill. Vad som går att konstatera är bankens avsaknad av fasta iterationer och

att ett utarbetat sätt att synka grupper saknas försvårar kommunikationen. Ett

annat problem är avsaknaden av riktlinjer inom banken för hur transparensen i

projekten ska se ut. Allt arbete för att få till en dialog mellan grupperna faller

istället på projektledaren. Hur arbetet med kommunikationen sker mellan

grupperna och allmänt inom projekten blir därför situations anpassat för varje

projekt och beror på hur de enskilda grupperna ser ut vilket beror på hur de valde

att arbeta i och med att reformen släpptes.

Det går att likna SEBs projektledare med SAFes RTE-roll, i den mån att deras

uppgift synka alla projektgrupper samt att hålla projektet på rätt spår. Att SEB i

större projekt även använder sig av en release manager har även liknelser med

SAFes release management team som skall underlätta implementeringen av de

olika inkrementen som fås av Scrumteamen. LSS har ingen roll som är direkt

ansvarig för att knyta ihop allt. Istället finns det ett kollektivt ansvar att under den

gemensamma retrospektiven försäkra sig om att allt går mot produktägarens

önskningar.

5.2.2 Handelsbanken

Scrumteamen i Handelsbanken använder sig av daily Scrum för att hantera

kommunikationen inom gruppen. Om det är flera team inom ett projekt använder

sig banken av möten på veckobasis för att kommunicera mellan Scrumteamen och

få till transparens. Mötet är av typen Scrum of scrums där Scrum masters från

varje team deltar tillsammans med projekt-, test- och eventuellt programledare.

Mötena sker om möjligt ansikte mot ansikte, är det inte geografiskt möjligt sker

det istället på elektronisk väg. Att ha täta möten med alla inblandade påträffas

inom både LSS och SAFe.

Handelsbanken använder sig idag främst av Scrumtavlor för att visualisera för

hela projektgruppen vad som har genomfört och vad som är under genomförande.

Banken har tittat på flera olika metoder/verktyg för att hantera dessa Scrumtavlor

och elektroniska backloggs men i dagsläget finns inga sådana metoder eller

verktyg. Generellt passar Handelsbankens sätt att hantera kommunikation inom

och mellan Scrumteamen överrens med hur LSS, SAFe och Scrum guide anser att

kommunikationen skall hanteras.Handelsbankens sätt att involvera en

projektledare och programledare när större projekt genomförs agilt är likt hur

SAFe hanterar styrningen av ART på programnivå.

51

Hos Handelsbanken fungerar projektkontoret som ett övervakande organ. De

övervakar hela projektportföljen och kan bidra med tips samt hjälp men

projektkontoret går aldrig in och petar direkt i projekten. Här syns en tydlig

skillnad till SAFe där projektkontoret fungerar som ett styrande och verkställande

organ.

5.3 Planering

Scrum och LSS säger att det bör finnas en grov planering på lång sikt för att sedan

succesivt detaljplanera det som behöver göras den närmsta tiden.

I SAFe sköts planeringen för projektet på programnivå, och innehåller allt arbete

som behövs för att få projektet att rulla. Detaljplaneringen för funktionerna i

projektet sker sedan på arbetsgruppsnivå och fungerar då som i Scrum.

Budgetering sker decentraliserat och allokeras allt eftersom projektet genomförs.

Kritiskt för planering av projektet är att alla team arbetar med samma

etapplängder. På teamnivå i SAFe lämnas plats i varje HIP (som är en del av PSI)

för infrastrukturellt arbete, utveckling och kreativt arbete (Leffingwell, 2011).

5.3.1 SEB

Gällande planeringen så är det som med tidigare nämnda områden, det är i

startskedet och det finns ingen satt modell för hur det skall gå till i organisationen.

Det som finns nu i organisationen är en blandning av traditionell planering och

den succesiva agila. Intressenter och produktägare har ett intresse av att veta när

de kommer få sin leverans och därför finns det fortfarande ett behov av det gamla

systemet. Men då det ser så olika ut inom varje team har projektledarna svårt att

sätta upp milstolparna för projektet då de inte får reda på hur och när saker och

ting kommer ske. Däremot försöker SEB styra in sina Scrumteam att arbeta mot

användandet av user stories som även hittas i SAFes arbetsgruppsnivå.

Ett annat problem som stör planeringen är att varje Scrumteam hanterar

kravspecifikationer olika. Ett team vägrar börja arbeta innan de har alla detaljer

produktägaren vill ha medan ett annat team bara vill ha en grov bild och inte

arbeta efter detaljer. I LSS, SAFe och Scrum önskas att kraven succesivt arbetas

fram tillsammans med produktägaren, eller i större LSS projekt, en behovs

produktägare.

SEBs projektkontor har utvecklat en modell för planering som ska stödja succesiv

planering och budgetering. Pengar allokeras till ett projekt först efter att en

planering lagts fram och blivit godkänd, då erhåller projektet pengar till det som

skall genomföras härnäst.Efter att den planerade del har genomförts får

projektledaren redovisa för projektkontoret vad som skall ske härnäst, och erhåller

förhoppningsvis nya pengar för nästa del av projektet. Cykeln repeteras igenom

hela projektet. Budget planeras efter årscyklar oavsett projektets längd. Det är

52

projektledarens ansvar att månadsvis rapportera hur projektet ligger till i

förhållande till budget.

Budgetprocessen har liknelser med SAFe och Scrum, men planeringen är inte lika

snabb och rörlig som för de båda metoderna. Idén att allokera pengar succesivt

liknar både SAFe och Scrum, men att årsbudgeteringen sker i årscykler återfinns

inte.

SEB vill få in riktlinjer för planeringen så att teamen inte planerar för 100 % av

sin kapacitet utan att projektgrupperna istället planerar 70 % av kapaciteten. Detta

ska lämna tid i planeringen för att släppa kreativiteten fri och samtidigt underlätta

hanteringen av förseningar. Här syns tydliga likheter med SAFe som anser att

användandet av HIP är av största vikt. Även Scrum och LSS anser att inte 100 %

av tiden bör allokeras till arbete. LSS och Scrum anser att 5-10 % bör allokeras till

finslipning av produktloggen.

Hos SEB fungerar Scrumteamen efter Scrum guide, men i och med att de saknar

en fast kadens fallerar samarbetet mellan teamen och då även planeringen. I och

med att det saknas en bestämd kadens blir det svårare för projektledaren att

planera släpp av mjukvara och således blir det svårt att planera in milstolpar,

något som produktägarna behöver se. Innan implementeringen av de agila

metoderna hade banken inga problem att visa upp en sådan typ av plan, även om

den aldrig hölls.

5.3.2 Handelsbanken

Handelsbanken följer inte tankarna bakom decentraliering av budgetering som

finns i Scrum och SAFe. Eftersom produktägaren behöver veta vad projektet

kommer att kosta för att gå med vinst görs en planering av kostnad för hela

projektet redan innan eventuellt godkännande att starta projektet. Då följs alltså en

mer sekventiell modell.

Planeringen i förstudien är dock förhållandevis grov ner på detaljnivå. Den

långsiktiga planeringen finns främst till för intressenterna i projektet. Men

planeringen genomförs ändå av verksamhetskunnig personal, så det finns

fortfarande en riktig tidsuppskattning. Tirsuppskattningen sätts sedan ihop av

projektledaren för att få ut en kritisklinje för projektet. Detaljnivån planeras sedan

successivt på team nivå efter Scrums principer. Banken har ingen modell för hur

det skall göras utan det är till viss del upp till teamen själva hur detta skall

hanteras.

Planeringen för Handelsbanken är således speciell. Banken använder dels

successiv planering à la agila metoder och SAFe när det gäller detaljnivå för

genomförandenivån för teamen.Men innan projekten startas gör Handelsbanken

även en traditionell tidsuppskattning för att kunna redovisa en kritisklinje för

intressenterna.

Inom Handelsbanken är idén och tankarna bakom att inte planera 100 % aktivitet i

varje sprint känd men det är inget som Handelsbanken arbetar med idag. Detta

skiljer mot SAFe eftersom SAFe yrkar för att en sprint aldrig ska uppnå 100 %

53

aktivitet, så att projektgruppen kan ta igen förlorad tid, genomföra interna

förbättringar och brainstorming utan att projektets rytm distraheras.

5.4 Genomförande

Både Scrum guide och SAFe säger att arbetet ska ske med kontinuerligt testande

av mjukvaran. Särkslit i SAFe anser Leffingwell det viktigt att testerna

genomförs eftersom de olika projektgruppernas levererade kod måste vara

kompatibla med varnadra. Tester utförs av personal som sitter med i

utvecklingsgrupperna och för att utföra tester när allt har blivit integrerat används

DevOps. SAFe trycker även på att man bör ta arbetet till arbetsgrupperna. På så

sätt kan man skapa långlivade arbetsgrupper som med erfarenheten de får av att

arbeta tillsammans kommer bli snabbare, effektivare och kunnigare i sitt arbete

(Leffingwell, 2011).

När det gäller mandat säger både Srum och SAFe att de som är närmast problemet

bör ha befogenhet att göra de ändringar som behövs.

I SAFe är det värdeflöden och epics på portföljnivå som bestämmer vad som skall

genomföras på organisationsnivå. Detta kan liknas med hur SEB jobbar med sina

compartments och hur det är de som väljer vilka projekt som skall genomföras

och hur dessa prioriteras (Leffingwell, 2011).

5.4.1 SEB

I och med att SEB införde compartments kan de i banken lättare se flaskhalsar i

utvecklingen och se till att det inte bedrivs två projekt med samma mål. Det är

även i compartmentsen som diskussionerna sker om det förekommer stora

förändringar i projektet.

SEB har tidigare arbetat med väldigt låsta krav, projektet har kunnat ändra tid och

budget men inte målet. I och med implementeringen av de agila modellerna har

synen på förändringar ändrats. Tidigare användes enbart projektbeställaren under

förstudien och därefter var projektbeställaren del i projektet över, nu försöker

banken behålla projektbeställaren under hela projektets gång. Det var först efter

den agila reformen som slutanvändaren började involveras under hela projektet

och detta har lett till att förändringar kan genomföras på ett enklare sätt. Innan den

agila implementeringen kunde hela projektet genomföras utan att slutanvändaren

tillfrågades om projektet var på rätt väg. Nu för tiden försöker SEB att få en högre

grad av involvering från slutanvändarens sida så att banken tidigare kan upptäcka

om projektet går åt fel håll.

Praxis att få återkoppling under hela projektet är en kritisk del av alla de agila

modellerna då det är ett av ledorden i den agila världen, att producera det som

verkligenen vill ha.

54

Projektledarens mandat har förändrats något med den agila reformen. I de projekt

som bedrivs enligt vattenfallsmetoden med ett ihop plockat team fungerar

projektledaren fortfarande som chef. I de projekt som utförs agilt varierar det från

team till team. Det är då teamen som sätter projektledarens mandat. I de agila

projekten har projektledaren främst en administrativroll, åter igen kan den liknas

med SAFes RTE. Inom Scrum och LSS finns inte den klassiska projektledarrollen

så det finns ingen direkt liknelse med de metoderna.

En fördel som uppstod när SEB omorganiserades efter de agila metoderna är att

nu lämnar inte projektdetagarna i förvaltningen för projektet och banken har infört

rutiner så att personerna som arbetar med projektet varierar. På så sätt får

projektdeltagarna nya erfarenheter och det är inte bara ett fåtal personer som får

utökad kompetens. Att SEB låter förvaltningen sköta utvecklingen stöds av tanken

som finns i SAFe där arbetet bör tas till gruppen. Detta hjälper till att skapa

långlivade agila team som med tiden blir snabbare och effektivare. I Scrum guide

och LSS hanteras däremot inte teamen på det sättet. I Scrum guide och LSS

skapas de agila teamen efter den kompetens som behövs för att få arbetet klart.

Rörande test av mjukvara kör de ut koden som får gå ett antal gånger innan

produktion. Vissa system som skall rapportera vid månadsskiften kan behöva

ligga upp till 3 månader. Ofta vid större projekt finns det en testledare och

testgrupp till projektledarens förfogande som har hand om hela testflödet.

I dagsläget ställer SEB krav på en slutrapport av sina projektledare samt att de

skall kunna hålla en lessons learned efter projektet.

SEB har idag ett väldigt väl fungerande sätt att hantera intern release av

mjukvaran även om det ser lite olika ut från projekt till projekt har de funnit ett

sätt att hantera det. Just i och med att det ofta är förvaltarna som utvecklar

mjukvaran så får de hela tiden se hur mjukvaran tar form och tar då del av

testerna. Så även om det i mindre projekt inte finns en särskild enhet dedikerad

enbart till tester så har de ändå ett utarbetat system just för det.

5.4.2 Handelsbanken

Handelsbanken försöker att alltid hålla projektbeställaren aktiv under hela

projektets gång och även använda sig av resurser från den avdelning som sedan

kommer hantera förvaltningen av projektet. Genom att göra detta kan de snabbare

få återkoppling från projektbeställaren. Deras sätt att engagera projektbeställaren

under hela projektet för omedelbar återkoppling är något som både Scrum guide,

SAFe och LSS trycker på. Det anses nödvändigt inom de agila metoderna att hela

tiden styra utvecklingen mot vad intressenterna vill ha.

Handelsbanken har även speciella verktyg och processer för att hantera

förändringar. Handelsbanken arbetar efter filosofin att de som är närmast

problemet skall vara de som fattar beslutet. Det är de som förstår och kan beräkna

kostnaden för förändringarna samt personen som håller i pengarna som beslutar

ifall en förändring skall göras. Detta ger en tydligare transparens, vilket är ett

ledord i Scrum guide.

55

I Handelsbankens projekt finns alltid en tidpunkt i projektet där kraven stänger för

förändringar

Handelsbanken försöker använda förvaltningen i projekteten så att banken kan

styra bort ifrån att hantera interna överlämningar i slutet av projekten. Det

återkommer även i SAFe. Men till skillnad från SAFe så skapar Handelsbanken

projektgrupperna för projektets skull så de arbetar inte med tanken om att skapa

långlivade Scrumteam. Ej heller stöds tänket att arbetet skall tas till gruppen. Vid

mindre förändringsprojekt kan förvaltningen komma in på slutet av projekteten

för att kunna överblicka projekteten och på så vis göra en intern överlämning

överflödig.

Handelsbanken arbetar med målet att varje sprint skall resultera i något de kan

visa upp för beställaren. Det som skall visas upp skall återspegla prestationen som

gjorts under sprinten. Ambitionen att varje sprint skall resultera i något av värde

som kan visa för beställaren är själva definitionen för en sprint i Scrum guide.

Att låta de närmast problemet ha mandat kring de beslut som behöver göras är en

central del av agil projektledning. Att i organisationen behöva involvera

projektbeställare och styrgrupp ifall kraven behöver ändras är dock inget som är

konstigt. Scrum gudie säger att förändringar får göras enbart av produktägaren

vilket i Handelsbankens fall blir projektbeställaren.

Handelsbanken ambition att varje sprint skall resultera i något av värde som kan

visas för beställaren är definitionen för en sprint i Scrum guide.

Handelsbanken arbetar med slutrapporter efter varje projekt där slutrapporten

skall beskriva vad som gått bra och vad som gått mindre bra under projektet.

Detta kan liknas vid SAFes inspektera och anpassa workshop. Handelsbanken har

märkt att användningen av slutrapporter har bidragit till att fler och fler

projektledare pratar positivit om de agila metoderna då de agila metoderna

underlättar kommunikationen under projektet. Projektledarna anser att genom de

naturligt täta mötena fås en transparens som inte fanns tidigare i projekten.

6. Diskussion

I följande kapitel presenteras slutsatser som dragits under studiens gång, egna

reflektioner samt förslag till vidare forskning. Under diskussion och slutsatser

besvaras frågeställningen från inledningen av rapporten. Reflektionerna är sådana

vi har dragit under studiens gång om varför resultatet ser ut som de gör. Framtida

forskning är frågor som vi har ställt oss själva under studiens gång och som är av

stort intresse för dels oss själva och den professionella världen.

Under studien har ett flertal likheter mellan bankerna och de representerade

metoderna hittats men även ett antal betydande skillnader. Till exempel har

respondenter från båda banker uttryckt liknande åsikter och tankar om varför agila

metoder behövs och hur ett agilt projekt skall genomföras. Däremot finns det

skillnader i hur bankerna hanterar detaljerna med tillvägagångssättet, både i

genomförande och implementeringen av agila projekt.

56

6.1 SEB

När SEB bestämde sig för att styra mot agil projektledning släppte banken på

inrådan av en inhyrd konsult ansvaret för skapandet av Scrumteam och hur dessa

skulle organiseras fritt på varje enskilt team. Som ett resultat fick varje team ett

eget sätt att sköta planering, kommunikation och längden på etapperna. Det

resulterar i ett fullständigt kaos för ansvarig projektledare som sedan behöver

koordinera dessa team mot ett gemensamt mål. I och med att det inte finns några

uppsatta riktlinjer hur det skall skötas faller allt det på projektledaren, något som

försvåras ytterligare av att varje team ger projektledaren olika mycket mandat och

insyn i deras arbete.

Om vi ser till vad SAFe anser det mest kritiska för att få projektet att rulla så

återkommer hela tiden att alla arbetar efter samma ettapplängd. Att SEB kan ha

upp till 18 olika team med olika längd på sina etapper skiljer sig rätt markant mot

tanken i SAFe där det är imperativt att alla arbetar efter samma leveranstid. Så det

ser ut nu med att allt arbete att få alla koordinerade mot samma mål faller på

projektledaren blir för mycket. Eller så en respondent uttryckte sig, en anledning

till att vissa projekt inte körs agilt är för att komplexiteten ökar med gränsytorna.

Det är vår mening att ifall SEB införde fler av rollerna vi hittar i SAFes

programnivå kanske det skulle gå att hantera även stora projekt som det ser ut

idag. Det skulle kunna bli lättare, men inte bra. Struktur och gemensamma

ettapplängder och uttalat sätt att sköta kommunikation är viktigt för framgången i

alla agila metoder.

Den plötsliga övergången till agila metoder och sättet det släpptes i organisationen

står troligen för oredan som finns i bankens projektmiljö i dagsläget. Det hela

underlättas inte heller av att det är en väldigt traditionsbunden miljö som nämnts

tidigare i rapporten. Som ett resultat finns det både projektledare och personal i

förvaltningen som anser att de agila metoderna inte behövs då det gamla sättet

alltid fungerat och detta sitter djupt i ryggraden.

Hur banken fungerar internt är också ett problem för den nya agila resan. Då det

finns så stora krav från projektbeställaren att direkt få veta vad saker och ting

kommer kosta och när det kommer levereras gör det svårt att hantera planeringen

av projekten på ett agilt sätt. I dagsläget är det även svårt för projektledaren att

engagera produktägaren under hela projektets gång, även det är ett direkt resultat

av att enligt tradition har IT-sidan varit skiljt från affärssidan vilka är den

huvudsakliga leverantören av projekt. Den separationen är något de måste åtgärda,

även om affärssidan inte har möjlighet att närvara på daglig basis kan de inte

längre se på projekten som något de beställer och IT levererar om det skall skötas

på ett agilt sätt. Scrum och SAFe säger att kunden bör finnas tillgänglig hela tiden,

något SEB har problem med även i de bästa av fall.

Att SEB vill gå mot mindre projekt efter Standish Groups rapport kan ha flera

fördelar för banken som organisation. En av respondenterna sade att vissa av

projektdeltagare på banken ansåg att projekten tog över för stor del av vardagen.

De ansåg att det tar över för mycket av deras tid med förvaltningen. Om de då

istället kan få sitta med projekt som bara sträcker sig över några månader istället

57

för år kan det vara en lättnad i deras arbetsbörda. Sen är det även ett steg mot en

mer agil organisation att gå mot mindre projekt då det är mer likt de små

projekten som de agila metoderna skapades för.

Att SEB hyrt in en konsult för att omorganisera hur banken arbetar i de agila

projekten kommer troligen ge en positiv effekt på hur mycket arbete det är i

dagsläget. En respondent uppgav att konsulten efter 20 minuters översyn

konstaterat att banken måste införa riktlinjer för bland annat etapplängd och hur

kommunikation skall skötas. Det är vår mening att det är just de områden som

skapar de huvudsakliga problemen i organisationen idag. Även om det tycks

enkelt att gå in i banken och säga ”här använder vi 3 veckors sprint och så här

sköter vi kommunikation” så är det troligen inte så enkelt i verkligheten. Vi har

vad en av respondenterna kallade för ”gamla rävar”, personer som gjort på

samma sätt i 30 år och kan de systemen utantill. Det är sådana saker som kan

hindra utvecklingen och försvåra även sådana ändringar som nämndes ovan.

SEB befinner sig i en tid av reform vilket tidigare nämnts i rapporten. Att de valde

att släppa den agila reformen så hastigt och på ett sådant sätt de gjorde ligger till

grunden för problemen de har idag. Men införandet av ett projektkontor i

samband med reformen samt anställandet av konsulter för att hantera reformen

och föra den mot ljusare tider visar på att SEB verkligen vill utvecklas som en agil

organisation.

SEB har ett intern sätt att avgöra om deras projekt utförs agilt eller inte. Banken

använder sig av en agil mognadstrappa där projekten klassas som agilt om det

uppfyller ett visst antal steg. Den agila mognadstrappan har inte kunnat studeras

eftersom SEB har valt att inte lämna ut mognadstrappan. Att kunna utgå ifrån den

agila mognadstrappan hade sannolikt underlättat arbetet med att beskriva hur SEB

arbetar i agila projekt, vilket är svårt att generalisera för SEB eftersom alla projekt

ser olika ut i dagsläget. Med trappan som underlag skulle det också kunnat gå att

klassificera alla projekt som döms som agila internt. Som organisation går det inte

att dra den generaliserade slutsatsen att SEB är agila, men banken arbetar

uppenbarligen mot att få fungerande agila projekt. Sannolikt har SEB störst arbete

att genomföra med att få alla projektgrupper att fungera tillsammans, mot ett och

samma mål.

Angående hur SEB arbetar med agila projekt i multiprojektmiljöer är det svårt att

ge ett konkret svar av den enkla anledning att SEB saknar riktlinjer och därmed

blir det svårt att dra några generaliserande slutsatser.

Det SEB bör komma ihåg under sin agila resa är att de agila metoderna är en

process, en ständig utveckling för det egna företaget. Agila metoder är en process

för att hitta det som fungerar absolut bäst för den egna organisationen.

6.2 Handelsbanken

Handelsbankens implementering av agila metoder var försiktig. Den skedde inte

organisationsomspännande över en dag. Istället har deras projektledare fått välja

om de vill utföra projekten agilt eller inte och backas upp med stöd av ett

projektkontor. Att projektkontoret fungerar likt en stödjande organisation vid

58

större projekt till projektledaren tror vi kan vara en anledning till att de metoderna

har tagit sådan fart inom organisationen. Redan efter tre år med de nya metoderna

utfördes 26 % av projekten agilt.

Handelsbanken säger inte att ett projekt skall bedrivas agilt bara för att det är litet.

De tänker istället ett steg längre och säger att projekt där kraven tenderar att

förändas är de som bör bedrivas agilt. När ett projekt väl bedrivs agilt anser

respondenten från Handelsbanken att Scrumteamen bör bestå av högst 8 personer,

behövs det fler personer så införs istället fler team. Tanken att teamen inte bör

överstiga en handfull individer liknar både Scrum guide och SAFe i det att teamen

bör hållas så små att kommunikation och beslut kan skötas snabbt och effektivt.

Kostnad är heller inte motivering att arbeta agilt, däremot har kort ledtid visat sig

vara positivt för framgång i projekt rent generellt.

Hos Handelsbanken hanteras mål vilka är så långsiktiga att de är svåra att

formulera på projektform i vad de kallar för program. Ett program består av ett

flertal separata projekt där alla arbetar mot ett slutgiltigt mål. Om detta skall

liknas med något ur teorin skulle det vara när det inom SAFe infös ett flertal ART

för att arbeta mot ett större mål. Skillnaden här är dock att SAFe bedriver dessa

parallellt medan Handelsbanken kör dessa successivt.

Handelsbankens projekt har en så kallad midja vilken består av projektledaren,

beställaren och projektansvarig linjechef (resursägare). Kommunikation mellan

dessa är en förutsättning för att projektet skall lyckas. Scrum säger att en nära

kommunikation med resursägaren och beställare är viktigt så att projektet hela

tiden går i den riktning som kommer driva igenom deras visioner. SAFe yrkar på

detsamma men rollerna har andra namn i metoden.

På teamnivå och mellan flera team använder Handelsbanken daily Scrum och

Scrum of Scrums. Handelsbanken försöker att samlokalisera så långt det går, om

det av någon anledning inte går så används fortfarande dagliga möten men via

telefon. Om projekten är av större natur är även projektledaren med i dessa möten,

projektledarens roll är då främst att skapa transparens och hjälpa till vid

oförutsedda problem, vilket är likt rollen en Scrum master har. Sättet att sköta

kommunikationen är väldigt lik både LSS och SAFes rekommendationer på hur

kommunikationen skall skötas. Vissa skillnader kan hittas i SAFe där det finns

betydligt fler roller, release management team, DevOps, UX för att nämna några

på programnivå. Dock bör det beaktas att SAFe är en metod framtagen för att

hantera upp till 150 individer.

För Handelsbanken går det att tyda samma mönster som SEB kring långsiktig

planering. En långsiktig planering behöver genomföras för att kunna tillfredsställa

intressenter och resursägare, dock genomförs planeringen väldigt grovt och

detaljplaneringen sker successivt. Både Scrum och SAFe säger att det bör finnas

en grov målbild för verksamheten så att det tydligt framgår vad verksamheten

strävar mot. Men då krav och teknik kan förändras under projektets gång bör

detaljplaneringen hanteras allteftersom projektet kommer framåt och erhåller

värdefull återkoppling från kunden. Tillsättning av personal till projekt sker på

portföljnivå hos projektledning men detaljplaneringen av projektet sker på

teamnivå där kunskapen för detaljplaneringen finns.

Scrum och SAFe säger att de som skall förvalta resultatet efter projektet har

avslutats bör sitta med i projektet hela tiden så att förvaltarna kan få återkoppling

59

under hela projektet och underlätta överlämningen av projektet. Handelsbanken

försöker göra samma sak, de försöker använda resurser från den avdelning som

skall förvalta resultatet. Dock är detta inte alltid en möjlighet men det är något

som Handelsbanken försöker arbeta mot. Genom att genomföra projektet med

förvaltningens resurser kan två fördelar utläsas; Handelsbanken kan se

överlämningen som en överflödig del vilket innebär onödigt tidskrävande arbete

samt att resursägaren involveras och blir delaktigt under hela projektets gång.

I Scrum diskuteras alla typer av förändringar direkt med produktägaren och

kommer på så sätt vidare med arbetet. Hos Handelsbanken hanteras det lite

annorlunda. Om det är något vilket inte direkt rör produktägaren fattar de närmast

problemet ett beslut, vilket liknar det agila tänket att de närmast problemet skall

hantera det. Förändringar av krav fryses däremot efter en viss tidpunkt i projektet.

Om produktägaren skulle vilja veta vad en förändring av ett krav skulle innebära

har Handelsbanken ett verktyg för den typen av analyser. Resultatet presenteras

sedan för produktägaren som får besluta om förändringen skall göras eller ej.

Vi kan se flera likheter med de agila metoderna hos Handelsbanken, men de har

ett eget sätt att definiera om ett projekt genomförs agilt. De definierar agilt efter

tre punkter: att det arbetas aktivt med en produktlogg, sprintar är konsekventa och

mellan tre och sex veckor samt att det sker regelbundna möten. En sak som enligt

respondenten ofta ”fladdrar” är att under sprinten skall det regelbundet prioriteras

bland kraven för att projekten skall vara agila. Vi kan säga att hur de gjort är ett

sätt att införa det agila tänket i en sekventiell organisation.

6.3 Slutsatser

Under rapporten har vi insett att det inte är så enkelt att på kort tid införa de agila

metoderna på organisationsnivå när det talas om tusentals individer. I fallen

studerade i den här rapporten är det svårt att särskilja de sekventiella metoderna

från de agila metoderna i projekten. Det beror till stor del att de fortfarande finns

ett behov att utföra vissa aspekter av projekten efter de sekventiella metoderna.

Bankerna arbetar fortfarande till stora delar sekventiellt, något som är en följd av

den interna strukturen och traditionerna inom organisationen.

Handelsbanken har behållit den sekventiella budgeteringen för att

projektbeställaren vill veta kostnad och tidsrymd innan eventuellt godkännande av

projektstart. I övrigt har Handelsbanken kommit långt i implementering av agila

modeller.

SEB arbetar i dagsläget inte efter de agila metoderna vi har behandlat i den här

rapporten på ett enhetligt sätt. Projekt som har en kritisk deadline genomförs

fortfarande sekventiellt. Detta är en tydlig indikator att de arbete kvar med de

agila modellerna.

Angående vår egen insats; det vi ser att vi hade kunnat göra annorlunda hade varit

att sett till fler teorier kring de berörda ämnena. Vi hade även kunnat utföra fler

intervjuer, både bland projektledare och bland personal på golvet för att se ifall de

delar våra respondenters syn. Att följa med ett antal arbetsteam under en

60

tidsperiod för att se hur deras arbete förhåller sig till organisationens visioner om

hur arbeta med de agila metoderna skall bedrivas.

Angående Handelsbanken hade det varit av intresse att få till en intervju även med

en projektledare och inte bara bygga empirin på chefen av projektkontoret. En

intervju med en projektledare hade kunnat verifiera respondentens kredibilitet.

6.4 Vidare forskning

Under studiens gång har vi stött på frågor som vi anser är av stort värde och som

borde besvaras. I en agil värld, hur kommer projektledarens roll se ut i framtiden?

Kommer projektledarrollen försvinna med de agila metoderna?

Då vi såg till en fallstudie av två av de fyra svenska storbankerna vore det även av

intresse att göra en studie av alla fyra.

En vetenskaplig studie av fördelar och begränsningar av metoden SAFe är av

intresse då det enbart cirkulerar praktikers åsikter.

Litteraturlista

Antvik, S & Sjöholm, H (2005). ”Projektledning och metoder”. Stockholm:

Antvik & Sjöholm.

Berggren, C (2001). Projekt: Organisation för målorientering och lärande. Lund:

Studentlitteratur AB.

Crawford, L (2002). “Profiling the competent project manager”.

Dobbins, J. & Donnelly, R (1998) “Summary research report on critical success

factors in federal government program management”.

Fryvbjerg, Bent, (2003/2004). "Fem missförstånd om fallstudieforskning".

Statsvetenskaplig tidskrift

Gerring, John, (2004). "What Is a Case Study and What Is It Good For?"

American PoliticalScience Review

Gopal, A. Sivaramakrishnan, K. Krishnan, M.S & Mukhopadhyay, T (2003).

“Contracts in Offshore Software Development: An Empirical Analysis”.

Gustavsson, T (2011). ”Agil Projektledning”. Stockholm: Sanoma utbildning.

Herten, H. J & Peeters, W.A.R (1986). “Incentive contracting as a project

management tool”.

Jansson, T & Ljung, L (2004). ”Projektledningsmetodik”. Lund: Studentlitteratur

AB

Kylén, J-A (2004). ”Att få svar”. Stockholm: Bonnier Utbildning AB.

61

Larman, C & Vodde, B (2009). “Scaling lean & Agile development”. Kanada:

Addison-Wesley, Pearson Education.

Leffingwell, D (2011) “Agile software requirements: Lean requierments practices

for teams, programs, and the enterprise”.

Leffingwell, D (2014) Tillgänglig: http://www.scaledagileframework.com [2014-

06-03]

Schwaber, K. & Sutherland, J (2011). “The Scrum guide”.

Schwaber, K. (2004). “Agile project management with scrum “.

Nonaka, I & Takeuchi, H (1986) “The new, new development game”.

Trost, J (2010). ”Kvalitativa intervjuer”. Lund: Studentlitteratur AB.

Wysocki, R (2009). “Effective Project Management: Traditional, Agile, Extreme,

Sixth Edition”. USA: WILEY.