Kulturens Konsekvenser og Scrum: Et litteraturstudie

Transkript

1 Kulturens Konsekvenser og Scrum: Et litteraturstudie Forfatter: Timmi Søndergaard Cpr: Studium: Cand.Merc.IT Afleveringsdato: Vejleder: Jakob Nørbjerg Antal Anslag: Timmi Søndergaard 1

2 Indholdsfortegnelse 1 Ledelsesresume Emne og problemformulering Problembeskrivelse Problemformulering Hypotese Afgræsning Besvarelse af problemformuleringen Agil udvikling Den agile bevægelse og Scrum Kultur og adoptering af agile metoder Håndtering af kulturelle forskelle Valg af Scrum Scrum teori Scrum masteren Product backlog Product owner Scrum teamet Sprints Scrum og agile udvikling Kultur og Kultur framework Kultur Valg af kulturframework Konsekvenser Geert Hofstedes framework Magtdistance Individualisme/kollektivisme Maskulinitet/femininitet Usikkerhedsundvigelse Langfristet/kortfristet tidsorientering Metode Analyse Framework Indholdsanalyse af Scrum

3 5.2 Tolkning af data Datakilder Opsummering Analyse af Scrum Resultat af tekstanalyse Magtdistance Ledelse, hierarki og uddelegering af ansvar Uenigheder og magtdistance Individualisme vs. kollektivisme Ledelse af individer Konfrontationer og åbenhed Det kollektive ansvar Usikkerhedsundvigelse Formalisering, regler og ledelse Eksperter og sund fornuft Usikkerhedsundvigelse i Scrum Maskulinitet - Femininitet Ego i maskuline og feminine kulturer Intuition eller beslutsomhed i ledelse Selvorganisering Konflikter og aggression Langtidsorientering - Korttidsorientering Kontrolsystemer Sandhed Delkonklusion Kultur analyse af USA og kina i relation til Scrum Hofstede scores Scrum i relation til USA Magtdistance - MDI Individualisme vs. kollektivisme - IDV Usikkerhedsundvigelse - UUA Maskulinitet vs. femininitet - MAS Langtids vs. korttidsorienteret - LSO

4 7.2.6 Delkonklusion Scrum i relation til Kina Magtdistance - MDI Individualisme vs. kollektivisme - IDV Usikkerhedsundvigelse - UUA Maskulinitet vs. femininitet - MAS Langtids vs. korttids orienteret - LSO Del konklusion Opsummering Konklusion Hvilke kulturelle antagelser bygger Scrum på? Hvordan stemmer Scrum overens med de kulturelle antagelser hos henholdsvis Kina og USA? Hypotese Hvilke udfordringer giver de grundlæggende kulturelle forskelle mellem Scrum og henholdsvis Kina og USA? Perspektivering Litteraturliste Bilag Identificeret ord fra Hofstedes kultur dimensioner Kodet citater Citater for Magtdistance - MDI Citater for Individualisme vs. kollektivisme - IDV Citater for Usikkerhedsundvigelse - UUA Citater for Maskulinitet vs. Femininitet - MAS Citater for Langtidsorienteret vs. Korttidsorienteret - LSO

5 1 Ledelsesresume Målet med denne afhandling er todelt, dels skal den give et indblik i de underliggende kulturelle værdier som udviklingsmetoden Scrum bygger på. Ydermere skal den sammenligne disse værdier med de kulturelle værdier, som er gældende for nationalstater. Opgaven bygger på antagelsen om at modeller og processer har indbygget kulturelle værdier, som er unikke for den kultur som har født de pågældende modeller og processer. Til analysen af kultur benyttes det framework som er udarbejdet af Geert Hofstede. Afhandlingen analyserer Scrums underliggende værdier og sammenligner disse med henholdsvis Kina og USA. Sammenligningen tjener det formål at vurdere Scrums kulturelle kompatabilitet med de to lande. Fremgangsmåden giver et indblik i de problemstillinger, som kan opstå ved en adoptering af metoden i de respektive lande. Afhandlingen konkludere at Scrum bygger på lav magtdistance, individualisme, lav usikkerhedsundvigelse, feminine værdier og er kort tidsorienteret. Ydermere konkluderes det at Scrum og USA udgør et tættere kulturelt match end Scrum og Kina. Det understreges at Scrum ville være problematisk at indføre i Kina i dens rene form, og at metoden kræver signifikante omstruktureringer for, at øge sandsynligheden for en succesfuld adoptering af metoden. 5

6 2 Emne og problemformulering I dette afsnit præsenteres den overordnet problembeskrivelse med en efterfølgende præcisering til en konkret problemstilling. Afgrænsninger for opgaven præsenteres samt et afsnit omkring hvorledes problemstillingen vil blive besvaret gennem opgaven. 2.1 Problembeskrivelse I de senere år har vi oplevet en stigende fokus på den agile tilgang inden for software udvikling. De procesbaserede metoder bliver opgivet til fordel for den agile tilgang i et forsøg på at imødekomme de problemer, som historisk har plaget software udvikling. Budgetoverskridelser, tidsoverskridelser og manglende eller forkert funktionalitet er et resultat af en proces, som ikke formår at tilpasse sig den verden som den agere i. Software udvikling er et forsøg på at bygge et værktøj til at understøtte en arbejdsproces som aktørerne ofte ikke selv forstår eller er fuldt ud bevidste om. Under disse forhold kan det ikke undre, at løsningen ikke leverer det som kunden har brug for, selv hvis projektet leverer det, som kunden faktisk bad om. I takt med at IT-projekter bliver større og mere komplekse er flere firmaer begyndt at benytte sig af Scrum for at kunne levere deres projekter inden for de fastsatte rammer. Scrum er en af de mere populære metoder inden for den agile bevægelse og sandsynligvis den mest udbredte agile metode i Danmark. I den vestlige verden har vi en kutyme med at lede efter den optimale løsning, Best Practice, og så overføre den til andre virksomheder, processer eller systemer. Enhver proces eller værktøj, som har været en succes i et ét firma eller en kontekst, vil hurtigt blive kopieret andre steder og bliver derved standardiseret og formaliseret. På samme måde er Scrum blevet udbredt til store dele af den vestlige verden efter dens initiale succes i USA. Det er således metodens succes, der er drivende for dens udbredelse: Hvis den har bevist sit værd et sted vil virksomheder være mere positivt stillet overfor at indføre den i deres organisation. Samtidig udbreder de selv metoden i forhold til datterselskaber samt forretningspartnere. Der ligger sjældent en analyse forud for udbredelsen af sådanne metoder og praksisser med det formål at determinere, om metoden er passende i de andre firmaer. 6

7 I sin artikel Motivation, Leadership, and Organization: Do American Theories Apply Abroad? (Hofstede, 1980) argumenterer Geert Hofstede for, at teorier reflekterer den kultur som forfatteren kommer fra. Theories reflect the cultural environment in which they were written Hofstede skriver også, at teorier ofte anses som universelt gældende, specielt af deres forfattere. Han konkluderer dog, at teorier ikke er universelle, og at teorier fra et land vil forstås og have en anden indflydelse i et land, hvor kulturen er markant anderledes i forhold til teoriens oprindelsesland. Denne mangel på erkendelse af de underliggende kulturers vigtighed kan have afgørende betydning, når multinationale firma forsøger at indføre ensrettede processer og metoder på tværs af lande i organisationen. Denne problemstilling er ikke blevet mindre med den øgede outsourcing og offshoring, der har fundet sted og til stadighed finder sted som et resultat af den øgede globalisering. Herhjemme har vi eksempler på offshoring af IT udvikling og i den forbindelse har flere danske firmaer adopteret Scrum som udviklingsmetode ved offshoringdestinationen. Et eksempel herpå er både Jyske bank og Danske Bank, som begge har oprettet offshore udviklingscentre i Indien. Netop disse to eksempler er begge gået fra procesdrevet udvikling til at indføre Scrum i deres dele af deres udviklingsprojekter. Med udgangspunkt i Hofstedes artikler og bøger bør man dog spørge om, hvorvidt Scrum passer til den asiatiske kultur. Det er netop denne problemstilling, som jeg vil belyse i denne opgave, Scrum klarer sig godt i forhold til den danske kultur, men kan danske firmaer forvente den samme succes, når de sender deres udvikling offshore? Og hvilke problemstillinger vil der kunne opstå, når Scrum forsøges implementeret i asiatiske firmaer? Denne afhandling sigter efter at skabe klarhed om de underliggende kulturelle værdier som Scrum bygger på, samt hvorledes disse kan forligenes med de asiatiske kulturelle værdier. Ved at belyse forskellene mellem de underliggende værdier mellem Scrum og de lande, der forsøger at benytte Scrum, bliver det muligt at udpege de områder hvor konflikter kan opstå. Det er mit mål, at denne opgave skal resultere i et produkt, som kan benyttes af danske, asiatiske eller internationale virksomheder, der ønsker at indføre Scrum i deres datterselskaber i Asien. 7

8 2.2 Problemformulering Problemformuleringen er baseret på undertegnedes interesse i at afdække de problemer, som indfinder sig ved adopteringen af en specifik softwareudviklingsmodel. Til denne afhandling tages der udgangspunkt i udviklingsmodellen Scrum; årsager til valget uddybes i efterfølgende afsnit. Afhandlingen har som overordnet spørgsmål: Hvordan kan nationale kulturelle værdier påvirke implementeringen af Scrum?. I denne opgave tages der udgangspunkt i USA og Kina. For at kunne svare på ovenstående vil jeg dele problemformuleringen op i en række delspørgsmål. Hvilke kulturelle antagelser bygger Scrum på? Hvordan stemmer Scrum overens med de kulturelle antagelser i henholdsvis Kina og USA? Hvilke udfordringer giver de grundlæggende forskellige kulturelle antagelser mellem Scrum og henholdsvis Kina og USA? 2.3 Hypotese Som beskrevet i problem beskrivelsen, så antager Geert Hofstede en position om, at teorier og metoder bygger på de underliggende kulturelle værdier som der opfinderen besidder. På baggrund af dette formuleres følgende hypotese: 1. Da Scrum er opfundet af en Amerikansk forfatter forventes det, at de underliggende kulturelle værdier som Scrum bygger på er sammenfaldne med de værdier, som er gældende for USA. 2.4 Afgræsning Hvis man følger Hofstedes præmis, er al forskning bundet til de værdier, som forskeren er opvokset med. Det betyder, at denne afhandling er skrevet ud fra de værdier, som undertegnet er opvokset med. Det er således vigtigt at notere sig, at den kulturelle analyse og perspektivering er foretaget ud fra et vestligt synspunkt. Jeg har ikke personlig dyb personlig kendskab til den kinesiske kultur, hvorfor jeg i denne opgave forlader mig på min forståelse og fortolkning af andres beskrivelser. 8

9 Det er også vigtigt at notere, at min baggrund for dette studie er som IT-professionel. Jeg er ikke antropolog eller har arbejdet med kultur tidligere, hvilket unægtelig vil påvirke min tilgang til emnet. Jeg har valg at begrænse studiet til to lande af pladshensyn. USA i egenskab af at være Scrums opfinderland, og Kina der på mange måder besidder kulturelle værdier, som er anderledes fra de vestlige. Strukturen af denne opgave er ikke specifik til disse lande - alle lande ville principielt have kunne være udvalgt og et større antal lande ville også være mulig. I den nyeste udgave af "Kulturer og Organisationer" har Hofstede tilføjet en ny kulturdimension, som han kalder "Eftergivenhed versus begrænsning". Jeg har valgt at undlade at tage den med af følgende årsager: Dimensionen er kun tilføjet for nyligt, og der findes ingen sekundær litteratur, hvor dimensionen inddrages endnu. På Hofstedes egen hjemmeside er dimensionen endnu ikke repræsenteret eller beskrevet, i modsætning til de andre dimensioner. Ydermere så har han i den nyeste udgave af sin bog, i modsætning til de andre dimensioner, ikke et afsnit der beskriver, hvorledes denne dimension påvirker arbejde og erhvervslivet.. Det tyder på, at dimensionen ikke er fuldt defineret og moden på samme niveau som de andre dimensioner, og derfor udelades den fra denne opgave. 2.5 Besvarelse af problemformuleringen For at kunne besvare problemformuleringen skal jeg i første omgang afdække hvilke kulturelle værdier eller antagelser som Scrum bygger på. Dette gøres ved at benytte et af flere tilgængelige kulturelle frameworks, som beskriver nationale kulturer, og hvorledes de manifesterer sig. Til denne opgave er valget af framework faldet på Geert Hofstede, og det er ud fra dette framework at Scrum skal analyseres. Selve analysen af Scrum sker ved "content analysis" af de oprindelige Scrumbøger som metodens forfatter skrev. 9

10 Ud fra frameworket og analysen kan det bestemmes, hvilke kulturelle værdier Scrum bygger på. Disse værdier sammenholdes så med de nationale værdier som Hofstede har identificeret for henholdsvis Kina og USA. Forskelle og sammenfald i kulturelle værdier beskrives mellem Scrum og de to lande. Denne afhandling er udelukkende et litterært studie, og der benyttes sekundær litteratur til at understøtte Hofstedes framework samt sammenligningen mellem Scrum og de to lande. De artikler, der benyttes, er primært baseret på kulturstudier med udgangspunkt i Hofstedes framework. 3 Agil udvikling Dette afsnit indeholder en beskrivelse af den agile bevægelse, og hvordan den relaterer sig til Scrum i forhold til oprindelse og bagvedliggende filosofi. Dernæst indeholder afsnittet en beskrivelse af tidligere studier omkring kultur i forhold til agil udvikling. I forlængelse af dette følger en kort beskrivelse af tidligere anbefalinger for håndtering af kultur og agil udvikling. Afsnittet sluttes af med en beskrivelse af, hvorfor jeg har valgt Scrum som undersøgelsessubjekt, og en kort gennemgang af Scrum og teorien bag. 3.1 Den agile bevægelse og Scrum Agil softwareudvikling er et fællesbegreb af softwareudviklingsmetoder baseret på iterativ og inkrementel udvikling, hvor krav og løsninger udvikles gennem et samarbejde mellem selvorganiserende og tværfunktionelle teams. Agil softwareudvikling fremmer en adaptiv planlægning, udvikling og levering af funktionalitet. Fælles for disse metoder er ofte en time-boxed iterativ tilgang, som opfordrer til konstant tilpasning i forhold til omstændighederne. Agil softwareudvikling som begreb blev først etableret med starten af den agile bevægelse, som blev startet af en række af prominente figurer inden for IT industrien, heriblandt Martin Fowler. Det var med udgivelsen af det "Agile manifest" i 2001, at gruppen for første gang officielt definerede begrebet agil softwareudvikling. 10

11 De agile "letvægts" metoder blev dog allerede udtænkt og taget i brug i starten til midt 90'erne som et modsvar til de "tunge og rigide" procesdrevne modeller. De tidlige letvægtsmetoder inkluderede Scrum (1995), Crystal Clear, Extreme Programming (1996), Adaptive Software Development, Feature Driven Development, and Dynamic Systems Development Method (DSDM) (1995). Den agile bevægelse kom til verden på baggrund af de problemer, som blev forbundet med at udvikle software med de procesdrevne modeller. Formålet var at skabe en ny tilgang til softwareudvikling, som kunne håndtere de problemer, som de procesdrevne modeller ikke kunne. Proces drevet udvikling er baseret på en ideologi om streng styring af udviklingsaktiviteterne, hvor kravene oftest er specificeret forud for, at udviklingen begynder. Processen styres ved at specificere ned i meget stort detaljegrad, som efterfølgende tillader, at alle aktiviteterne kan planlægges og udføres. Den procesdrevne software har historisk haft problemer, hvis der opstod pludselig ændringer og uforudsete hindringer under et udviklingsforløb. Både metoderne men også de juridiske/kontraktmæssige vilkår har gjort det problematisk for procesdrevet udvikling at reagere på ændringer. Scrum blev som metode præsenteret første gang i 1995 som en artikel udgivet af Ken Schwaber og Jeff Sutherland. Metoden blev senere hen udbygget og formaliseret i bogen Agile Software Development with Scrum i Scrum går dog mange år forud for det, da Ken Schwaber praktisk havde brugt ideerne i Scrum i sit arbejde gennem 80 erne og 90 erne. Et af de centrale punkter i Scrum, som efterfølgende blev adopteret af den agile bevægelse, er opgøret med procesdrevet software udvikling, som havde været standard indenfor software udviklingsindustrien i mange år. Det var Ken Schwabers frustrationer med de førnævnte problemer, som fik ham til at uarbejde ideerne bag Scrum. Mødet med ligesindede profiler indenfor IT verdenen ledte ham til at blive medlem af den agile bevægelse, og i sidste ende resulterede i udgivelsen af Scrum i bog form. Det var dog først med starten af den agile 11

12 bevægelse, at antallet af agile metoder voksede og der kom fokus større offentlig på agil softwareudvikling og ikke mindst Scrum. Det overordnede formål med Scrum er således en udviklingsmetode, der i højere grad er i stand til at levere resultater i dynamiske miljøer. Scrums hovedstyrke er netop, at kunder og slutbrugere har bedre mulighed for at ændre og/eller tilføje krav uden at det resulterer i nogle af de problemer som er opstået historisk. Scrum løser disse problemer gennem det som Ken Schwaber kalder empirisk kontrol. Empirisk kontrol som begreb dækker over en ledelsesteknik, der har indlagt feedback loops, og hvor projektet konstant tilpasser sig i forhold til de tilstedeværende omgivelser og hændelser. Scrum dækker over en praksis, der dikterer tæt samarbejde og involvering af kunderne, og samtidig opgives ideen om på forhånd at kunne specificere kravene fuld ud. I stedet er der indført mekanismer, så Scrum kan tilpasse sig de ændringer som opstår løbende. 3.2 Kultur og adoptering af agile metoder Der findes i dag flere artikler som omhandler organisationskultur og dens påvirkning i forhold til implementering af softwareudviklingsmodeller i organisationer. Fokus på ledelse generelt og ikke mindst IS ledelse og kultur har været genstand for talrige undersøgelser, siden Hofstedes framework først blev udgivet. Samme fokus har der ikke tidligere været i forhold til softwareudviklingsmodeller og kultur (Ford et al, 2003). Med den agile bevægelse er der dog kommet et større fokus på den kulturelle kompatibilitet mellem organisationer og udviklingsmodeller, specielt de agile metoder. Eksempler på dette er (Ngwenyama & Nielsen, 2003), (Nerur et al, 2005), (Iivari & Iivari, 2011). Artikler omhandlende de forhold, som de agile metoder præsterer bedst under, har også set dagens lys efter det Agile Manifest blev offentliggjort (Boehm, 2002), (Boehm & Turner, 2003). 12

13 En gennemlæsning af ovenstående artikler bevidner om at der er opstået en bevidsthed om at kultur har en konkret effekt i forhold til software udviklingsmodeller, som påvirker alt fra sandsynligheden for en succesfuld implementering til udviklingsmetodernes effektivitet under de pågældende kulturelle forhold. Fælles for denne forskning er, at den primært bygger på eksisterende viden omkring organisationskultur, hvor der ofte tages udgangspunkt i den populære model "Competing Values Survey". Der har således ikke været det samme fokus på, hvorledes national kultur frem for organisationskultur påvirker softwareudviklingsmodeller. National kultur kan ikke sidestilles med organisationskultur, og det er vigtigt at virksomheder, specielt globalt positioneret virksomheder, kender forskellene og hvorledes de kan påvirke virksomhedernes aktiviteter. National kultur relaterer sig til vores dybeste holdninger og værdier som vi tillæres meget tidligt i livet. Organisationskultur udgøres af normer, værdier og retningslinjer, som er fæstet i de processer og praksisser, som læres gennem arbejdet i organisationen. Medarbejdere kan tilpasses nye organisationskulturer, men hvis disse strider imod de underliggende national kulturelle værdier vil virksomhedens værdier ende med at blive undermineret. Der er altså et behov for at anskue udviklingsmodeller ikke kun i forhold til organisationskultur men også i forhold til national kultur. De få eksempler som findes omkring dette viser, at udviklingsmetoder vil have svært ved at blive adopteret på et nationalt plan, hvis metodens underliggende kulturelle antagelser ikke stemmer overens med den nationale kultur (Hazzan & Dubinsky, 2005). Dette er blevet mere relevant med tiden i takt med at flere virksomheder går ind i outsourcing og offshore outsourcing aktiviteter. Med distribueret udvikling på tværs af lande og med etableringen af offshore udviklingscentre kan spørgsmålet om, hvorledes nationale kulturer påvirker disse udviklingsmetoder have afgørende betydning. I disse tilfælde kan teorien om organisationskultur ikke belyse om organisationskulturen og virksomhedens metoder og processer er kompatible med de lande som virksomheden ønsker at etablere sig i. 13

14 3.3 Håndtering af kulturelle forskelle Forskningen i kultur og kulturel kompatibilitet afføder det naturlige spørgsmål: "Hvorledes skal man forholde sig til kulturelle forskelle?". Som nævnt tidligere så har størstedelen af den nuværende forskning taget udgangspunkt i organisationskultur, hvor der er to tilgange til problemet. På den ene side argumenteres der for, at den organisatoriske kultur kan ændres eller tilpasses (Ngwenyama & Nielsen, 2003). Det er dog ikke alle forskere som er enige i at organisationskultur kan ændres inden for en så kort tidshorisont, at det er en troværdig løsning (Iivari & Iivari, 2011). På den anden side argumenteres der for, at organisationskultur kan ændres over en længere periode, hvor organisationskulturen og eksempelvis den "agile kultur" vil påvirke, forstærke og ændre hinanden samtidigt (Iivari & Iivari, 2011). National kultur, som defineret af Hofstede, er dog anderledes end organisationskultur idet den er med til at definere vores samfund og vores præferencer som individer. Organisationer har således ikke mulighed for at ændre vores underliggende kulturelle værdier, da disse er selve kernen af de enkelte lande og samfund. National kultur kan dog godt ændres, men det fordrer at hele samfundet påvirkes da national kultur er betinget af de kollektive værdier i samfundet. De forslag og konsekvenser som er foreslået af ovenstående forfattere kan altså ikke gøre sig gældende i forhold national kultur. National kultur kan ikke tilpasses dynamisk i forhold til en de omstændigheder, der er gældende for de enkelte organisationer som operere i de enkelte samfund. Bevidst manipulation af national kultur foretaget af enkelte organisationer med det formål at tilpasse den nationale kultur til virksomhedskulturen er ikke en mulighed. Viden omkring national kultur, og hvorledes den påvirker de enkelte organisationer, kan derimod bruges til at forudsige og afbøde konsekvenserne ved at introducere processer som er bundet til modsatrettet kulturelle værdier. 14

15 3.4 Valg af Scrum Kultur påvirker alle processer og modeller i alle brancher - dette er ikke unikt for IS branchen eller for de forskellige softwareudviklingsmetoder, som eksisterer i dag. Der er således grundlag for at undersøge de underliggende kulturelle antagelser for alle softwareudviklingsmetoder. Valget af Scrum som undersøgelsesemne blev påvirket primært af dets popularitet. Først ønskede undertegnede at tage udgangspunkt i en agil udviklingsmetode grundet den agile bevægelses overvældende succes og hurtige udbredelse i vesten. Valget faldt specifikt på Scrum grundet popularitet over for andre af de agile metoder. Der var en forventning om, at det ville være nemmere at finde sekundær litteratur omkring Scrum grundet dets popularitet. En bekræftelse på, at kultur påvirker Scrum findes i A practical guide to distributed Scrum" (Woodward et al., 2010) hvor forfatterne anerkender og beskriver at national kultur kan være problematisk, men ikke har indsigt nok til bedømme hvad der ligger bag problemerne eller hvorfor det kan føre til konflikter. Det blev yderligere underbygget efter jeg havde været i kontakt med en direktør i Cap Gemini med 25 års erfaring inden for outsourcing, som bekræftede kulturens indflydelse på softwareudvikingsmodeller og ikke mindst i forhold til Scrum. Han skriver følgende til mig: For at svare på et af dine spørgsmål om hvorvidt der er nogle udviklingsmodeller der passer bedre til nogen kulturer, så er svaret klart ja! Et udviklingsprojekt, med klare afgrænsninger, krav og processer egner sig godt til hierarkiske kulturer, som f.eks. i de asiatiske eller østeuropæiske kulturer, mens de mere agile, som f.eks. SCRUM eller iterative projekter, vil have meget svært ved at fungere i disse kulturer. Her har de nordeuropæiske kulturer en fordel pga. vores demokratiske sindelag og evne til selv at tage ansvar. Ole Samuelsen, Engagement Director, Capgemini Danmark A/S 15

16 3.5 Scrum teori I dette afsnit introduceres Scrum og teorien bag scrum, afsnittet starter med en kort opsummering som uddybes efterfølgende. Scrum som metode består af ganske få roller og processer og er designet til at kunne håndtere omskiftelige krav og situationer i et givent projekt. De faste deltagere i et Scrum projekt er Scrummasteren, Scrum teamet og Product owner. Derudover er ledelsen og slutbrugere også ofte aktive. Scrum er bygget op om en simpel ide om, at udvikling udføres i faser (sprints) på 30 dage i varighed (30 dage er standard men kan variere), hvorefter at en ny fase vil følge. Mellem faserne udvælges de funktionaliteter, som skal udvikles i kommende fase. Da planer kun låses fast i 30 dage, så giver det mulighed for bedre tilpasning til ændringer i projektet. Scrum masteren er den ansvarlige person, som skal sikre at udviklingen forløber som den skal, og som bistår både Scrum teamet, ledelsen og Product owner. Scrum teamet er et selvstændigt team af personer, som skal sikre at udvikle og teste de funktionliteter, som er udvalgt for det givne sprint. Product owner er den person som ejer det endelige system og som bestemmer hvilke funktionaliteter som Scrum teamet skal udvikle Scrum masteren Scrum masteren er et nyt begreb i forhold til den klassiske projektlederrolle. Scrum masteren har ligesom projektlederen ansvaret for, at løsningen tilfredsstiller de krav som er fremsat og at processen gennemføres succesfuldt, men rollen og metoden er anderledes. Hvor projektlederen normalt er ansvarlig for drive projektet, er Scrum masteren ansvarlig for, at der ikke er noget som hindrer udviklingen. I Scrum er det teamet, som driver projektet. Det er Scrum masterens rolle at samarbejde med udviklingsteamet, kunden og ledelsen og sikre, at der ikke opstår hindringer eller afbøde dem, hvis de ikke kan forhindres. Det er Scrum masteren som leder det daglige statusmøde og sikrer at der sker fremskidt i projektet. 16

17 3.5.2 Product backlog I et Scrum projekt udgør the product backlog en prioriteret liste over alle de krav, som skal tilfredsstille de behov som er identificeret og løbende identificeres og afklares. Product backloggen indeholder alt det, der konstitueres som arbejde på projektet. Det er en liste over features, funktioner og teknologier, som skal implementeres, fejlrettelser etc. Product backloggen er altså et meget bredere begreb end den klassiske kravspecifikation. Product backloggen er ikke en statisk liste men et levende og kontinuerlig foranderligt artefakt. Product backloggen ændres ofte i takt med at projektet skrider frem. Som følge af at de involveredes viden og forståelse udbygges medfører det ofte en ændring af eksisterende krav eller tilføjelse af krav - nogle gange opdages det at krav reelt ikke var nødvendige. Input til listen kan komme fra alle kilder internt i organisationen, alle interessenter kan indmelde krav, fejlrettelser eller ønsker, som derefter prioriteres. Listen bliver aldrig sekventielt gennemført, idet det ikke kun er indholdet af krav som kan ændres, prioriteten af dem kan også ændres. Der foreligger således en reel mulighed for at nogle krav eller ønsker aldrig gennemføres, da de konstant nedprioriteres Product owner Product owner er den person som ejer og er ansvarlig for product backloggen. Han er samtidig den officielt ansvarlige for hele projektet og systemejer. Hvis projektet er ejet af en ekstern kunde vil product owner være den officielle kunderepræsentant. Product owner er altid en enkelt repræsentant, hvilket gør det nemmere at placere ansvar og gennemføre beslutninger. Product owner har til opgave at vedligeholde product backloggen og sikre, at den altid er up to date, og at alle opgaverne er prioriteret i den rækkefølge som aktiviteterne skal gennemføres. 17

18 Product owner vil ofte arbejde sammen med sin organisation, Scrum masteren og Scrum teamet for at kunne varetage sin opgave med at sikre, at udviklingsaktiviteterne gennemføres i den rækkefølge og kvalitet som ønskes Scrum teamet Et Scrum team adskiller sig fra den konventionelle ide om, hvorledes grupper fungerer. Så snart deltagerne til et Scrum team er nedsat, hvilket sker i samarbejde mellem Scrum master, product owner og ledelsen, bliver de fuldkommen autonome. Det vigtigste begreb fra Ken Schwaber er ideen om, at Scrum teams er selvorganiserende. Det forventes, at et Scrum team selv organiserer sig i forhold til den opgave som løses. Scrum sætter større krav til projektdeltagerne, som nu skal påtage sig ansvaret for udviklingen og selv afdække og definere, hvorledes de i sidste ende kan gennemføre det. Ingen kan diktere, end ikke ledelsen, hvorledes teamet skal gennemføre projektet, eller hvordan de skal organisere sig. Ken Schwaber beskriver i sine bøger, at Scrum teams ikke er opdelt i roller - alle deltagere skal kunne bidrage til det endelige resultat. Den normale rollefordeling som udviklere, arkitekter, testere benyttes ikke i Scrum Sprints Som nævnt tidligere er udviklingsforløbet i Scrum er faser inddelt i sprints, hvert sprint varer som udgangspunkt 30 dage. Al funktionalitet som udvikles i et sprint skal være færdig udviklet og testet efter de 30 dage. Hvert sprint resultere således i funktionel kode som kan tages i brug med det samme. 18