Agila metoder i stora projekt inom två svenska storbanker

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: Handledare: Examinator: VT-14 Tomas Gustavsson Lennart Ljung

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 ITavdelningar 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. iii

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. iv

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 v

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 vi

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 vii

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 3

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). 4

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. 5

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 ITprojekt 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. 6

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 7

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 8

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. 9

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. 10

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å 11

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). 12

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. 13

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. 14

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 15

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. 16

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 17

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: Nackdelar: 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 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å. 18

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 19

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. 20

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ö. 21

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: 22

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. 23

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. 24