Agile udfordringer ved scrum

Transkript

1 Agile udfordringer ved scrum Institut for Marketing og Organisation April 2013 Casestudie af Creuna Vejleder: Forfatter: Charlotte J. Brandt Casper Skjold Nielsen Anslag:

2

3 Abstract The overall objective of this thesis is to add an academic contribution to the debate about, why many companies adjusts or rejects the scrum methodology. I have answered this by conducting a case study that tests two critics answers to the question. Many IT companies are experiencing difficulties in creating value for their customers when they use traditional project management methods. This is greatly due to the high complexi- ty of the tasks and the customers ever- changing needs. These companies start to search for new development methods that can solve the problem. A large part of them ends up choos- ing the agile method Scrum. But only 30% of these companies are successful. The rest will either adapt the method or leave it in favor of another method. The two critics Ken Schwaber and John Sonmez are of different opinions about why this is the case. Ken Schwaber believes it is due to the fact that many companies cannot handle the organizational problems the method exposes. John Sonmez on the other hand believes that the scrum methodology leads to some unnecessary problems. These problems force the companies to adapt the method or reject it because they can add value to the process by doing so. Ken Schwaber is the author of the book Agile Project Management With Scrum and he is one of the persons who formulated the Scrum methodology for the first time. John Sonmez is a practitioner of agile methods with years of experience using Scrum. It was difficult to figure out which one of them was right since both of them had years of experience using Scrum. Moreover the theory was not able to answer the question. I there- fore chose to conduct a case study of the company Creuna. Creuna used Scrum to learn the agile mind- set but ended up adapting the method and eventually reject it in favor of Kan- ban. I decided to analyze, if Creuna supported Ken Schwaber s or John Sonmez s criticism in doing so. I chose to divide the analysis into three parts. First I analyzed what expectations Creuna had to the Scrum methodology and matched these with the theory. The analysis showed

4 that their expectations matched the theory. I could then conclude that this was not the rea- son why Scrum had failed them. Then I analyzed what challenges Creuna had faced when they used Scrum. The analysis showed that scrum made it difficult for Creuna to work agile and create the value they were capable of. The employees realized that it was not the rules and rituals that made scrum valuable. It was the idea behind these principles that created the value. After realizing this they started to adjust the method to the context of the projects. And they started to look for a new method that would support this way of thinking. I could in the light of this conclude that Creuna reinforced John Sonmez s criticism of Scrum. Lastly I analyzed how Creuna is working with project management today. The analysis showed that they had moved an abstraction level up. They were now focusing on the un- derlying values in the process. They are now using Kanban as their primary project management tool. Kanban allows Creuna to combine several methods at once. That way they can choose the methods that create the most value in a particular context. This agile way of thinking solves several of the problems Scrum had caused. I could on this basis once again conclude that Creuna supports John Sonmez s criticism of the Scrum method. The analysis made me able to conclude that Creuna shares many of John Sonmez s experi- ences with Scrum, and they support most of his criticism. Therefor it can be concluded that the Scrum methodology forced Creuna to adjust the method and eventually reject it be- cause they could add value to the process by doing so. That also meant that Ken Schwaber s criticism could be dismissed in this case.

5 Indholdsfortegnelse 1. INDLEDNING PROBLEMFORMULERING AFGRÆNSNINGER UDGANGSPUNKT FOR UNDERSØGELSEN OPGAVENS OPBYGNING VALG AF TEORI BEGREBSDEFINITION BESKRIVELSE AF CREUNA METODE OVERVEJELSER I FORBINDELSE MED DATAINDSAMLING VALG AF RESPONDENTER OPBYGNING AF INTERVIEWGUIDE GENNEMFØRELSE AF INTERVIEW KRITIK AF METODEAFSNIT KILDEANALYSE TEORETISK AFSNIT SCRUM TEORIEN JOHN SONMEZ S KRITIK AF SCRUM- METODEN ANALYSE CREUNAS FORVENTNINGER TIL SCRUM- METODEN FORVENTNINGER SCRUM TEORIENS INDFRIELSE AF CREUNAS FORVENTNINGER DELKONKLUSION UDFORDRINGERNE CREUNA MØDTE SCRUM- METODENS RAMMER FLASKEHALSE COMMITMENTS PRODUKTEJEREN DELKONKLUSION CREUNA I DAG SCRUM SOM OVERGANGSMODEL KANBAN VÆRKTØJSKASSEN AGILE UDFORDRINGER DELKONKLUSION KONKLUSION PERSPEKTIVERING REFERENCER BILAG 50

6 Indledning 1. Indledning Efter at have studeret agile forretningsprocesser inden for software udvikling nærmere, er det blevet klart for mig, at der er mange fordele forbundet ved agile udviklingsmetoder. Virksomheder, der benytter traditionelle metoder, har ofte problemer med at opfylde kundens behov. Metoden tager udgangspunkt i en kravspecifikation, der bliver udarbejdet i starten af projektet. Det betyder, at der ikke bliver taget hensyn til kundens skiftende behov, og leverancen af produktet sker ofte langt ude i fremtiden. Dermed ender kunden med at betale for et produkt, der indeholder mange unødvendige features, hvilket ikke er holdbart i det lange løb. Derfor begynder mange virksomheder at lede efter en metode, der kan hjælpe dem med at forbedre deres leveringstid og skabe mere værdi. Det er her, at mange virksomheder begynder at finde de agile udviklingsmetoder attraktive. Ifølge det agile manifest (Beck, 2001) er kernen i agil software udvikling følgende: - Individer og samarbejde frem for processer og værktøjer - Velfungerende software frem for omfattende dokumentation - Samarbejde med kunden frem for kontraktforhandling - Håndtering af forandringer frem for fastholdelse af en plan Der er værdi i punkterne til højre, men vi værdsætter punkterne til venstre højere. Mange virksomheder kan identificere sig med dette værdisæt. Derfor vælger de at skifte fra traditionel projektledelse til agil projektledelse (Møllerhøj, 2011). I den forbindelse har scrummetoden fået en høj tilslutning, og den er blevet et synonym for agil udvikling (Vin, 2011). Mange virksomheder finder metodens faste rammer og lette forståelighed tiltrækkende, hvorfor de vælger denne metode, når de vil lære at arbejde med agile processer. Det er dog blevet klart for mig, at der er mange udfordringer og komplikationer forbundet med brugen af scrum. Flere virksomheder afviger fra metoden, og benytter den kun i en begrænset periode (Vin, 2011). Ken Schwaber, som er en af skaberne af scrum-metoden, skriver på sin personlige blog (Schwaber, Scrum Fails? ), at kun 30% af dem der benytter scrum bliver succesfulde udviklings- Side 6 af 68

7 Indledning organisationer. I tillæg til dette fremhæver praktikeren John Sonmez (Sonmez, About) nogle væsentlige udfordringer ved scrum. Udfordringer der gør det umuligt at benytte scrum-metoden til at arbejde agilt. Både Ken Schwaber (Schwaber, What Comes After Scrum, 2012) og John Sonmez (Sonmez, Scrum Will Die, 2010) siger, at scrum ikke er den endelige metode inden for agil projektledelse. De er dog uenige om, hvorfor dette er tilfældet. Ken Schwaber mener, at det skyldes manglende commitment fra virksomhederne, da mange ikke formår at overkomme de organisatoriske problemer, som scrum-metoden fremhæver. John Sonmez mener derimod, at det er scrum-metoden, der medfører en række udfordringer, som gør det umuligt for virksomhederne, at skabe den ønskede værdi. Derfor vælger flere at afvige fra metoden eller forkaste den. 1.1 Problemformulering Mange virksomheder mislykkes med scrum-metoden. De to kritikere Ken Schwaber og John Sonmez har to vidt forskellige holdninger til, hvorfor dette er tilfældet. Teorien gør det ikke muligt at vurdere, om én af de to kritikere har ret. Jeg har derfor valgt at gennemføre et casestudie af virksomheden Creuna, der har forsøgt sig med scrum-metoden og efterfølgende forkastet i hvert fald dele af den. I dette casestudie vil jeg analysere, hvordan de erfaringer Creuna har gjort sig med scrum-metoden stemmer overens med den kritik, som er fremført af Ken Schwaber og John Sonmez. 1.2 Afgrænsninger Analysen tager udgangspunkt i én virksomhed, hvorfor mine konklusioner er baseret på denne ene virksomhed. Det betyder, at jeg analyserer om Creunas erfaringer støtter den ene kritiker mere end den anden. Ved et større casestudie ville det være muligt at lave en nuanceret analyse, der viser hvilken kritiker, der oftest har ret. I denne afhandling er det ikke muligt for mig at konkludere og perspektivere på et generelt niveau, da dette kræver et større empirisk studie. Formålet med casestudiet er derfor, at få detaljeret og holistisk viden omkring den valgte virksomhed fremfor en generel viden om flere virksomheder (Eriksson & Kovalainen, 2011, s ). I tillæg til dette skal det også inspirere Side 7 af 68

8 Indledning læseren til at drage egne konklusioner og eventuelt søge flere informationer efterfølgende (Eriksson & Kovalainen, s ). Denne afhandling omhandler scrum-metoden, som bygger på det agile manifest. Jeg vil ikke gå i dybden med det agile manifest. Det vil derfor være op til læseren selv at søge yderligere information om dette. Jeg vil heller ikke gå teoretisk i dybden med metoderne, som Creuna benytter i dag. Jeg vil blot forklare, hvordan de i Creunas perspektiv adskiller sig fra scrum-metoden og skaber mere værdi. Jeg har valgt at afgrænse mig fra brugen af observationer, da tidsrammen ikke gør mig i stand til at gennemføre både interviews og observationer. Interviews blev valgt fremfor observationer, da interviews gjorde det muligt at undersøge Creunas bevæggrunde for at vælge scrum. Dette var ikke muligt alene ved brugen af observationer. Analysen af Creuna tager udgangspunkt i interviewene med de tre medarbejdere: Jesper Boeg, Mridul Sethias og Martin Brogaard. De tre medarbejderes mening repræsenterer Creuna i denne afhandling. Dette er ikke ensbetydende med, at alle i Creuna nødvendigvis er af samme holdning. 1.3 Udgangspunkt for undersøgelsen Formålet med opgaven er at bidrage fagligt til diskussionen om, hvorfor mange virksomheder afviger eller bevæger sig væk fra scrum-metoden. Det er ikke muligt at generalisere ud fra én case, da resultatet kun giver et indblik i én virksomheds erfaringer med scrum. Jeg håber dog, at jeg kan underbygge én af kritikerne af scrum og dermed lægge fundamentet for et større casestudie. Et par centrale kriterier i forhold til valget af case virksomhed var, at projektledelse var en del af deres dagligdag, og de havde erfaringer med scrum. En virksomhed der opfyldte dette og havde tid til at bidrage til afhandlingen, var Creuna. Side 8 af 68

9 Indledning 1.4 Opgavens opbygning Dette afsnit har til formål at beskrive opgavens opbygning og indhold for læseren. Metodisk starter jeg med at beskrive undersøgelsens metode, videnskabsteoretiske perspektiv og dataindsamlingsmetoden. Afsnittet har til formål, at gøre de metodiske overvejelser eksplicitte. Herefter beskriver jeg min forståelse af scrum teorien med udgangspunkt i Agile Project Management With Scrum af Ken Schwaber (Schwaber, Agile Project Management With Scrum, 2003). Denne beskrivelse giver et indblik i, hvordan Ken Schwaber mener, at scrum teorien skaber værdi, hvis den følges stringent. Dertil har beskrivelsen til formål at skabe et fælles paradigme for læser og jeg. Dette teoretiske afsnit supplerer jeg med et afsnit vedrørende kritisable dele af scrum-metoden. Kritikken tager udgangspunkt i blogindlægget Scrum Will Die af John Sonmez (Sonmez, Scrum Will Die, 2010). Kritikken skal bruges i den efterfølgende analyse til at sammenholde Creunas erfaringer med kritikken. Analysen er i tre dele. Først analyserer jeg, om der er sammenhæng mellem virksomhedens forventninger og scrum teorien. Dette giver et indblik i, om Creuna havde urealistiske forventninger til scrum-metoden, og om dette var årsagen til, at de forkastede metoden. Herefter analyserer jeg udfordringerne, som Creuna mødte, da de benyttede scrum-metoden. Dette giver et indblik i, hvorfor virksomheden valgte at forkaste metoden, samt understøtter om én af de to kritikere har ret. I sidste del analyserer jeg, hvordan Creuna arbejder med projekter i dag. Derved kan jeg analysere om kritikken af scrum er berettiget. Hvis virksomheden oplever de samme udfordringer i dag, understøtter det Ken Schwaber i, at virksomheden ikke var i stand til at overkomme de organisatoriske problemer, som scrum bragte frem i lyset. Hvis virksomheden ikke oplever de samme udfordringer i dag, understøtter det John Sonmez i, at scrum-metoden var skyld i udfordringerne. Analysen tager udgangspunkt i et kvalitativt datasæt indsamlet gennem semistrukturerede interviews. Dette datasæt vil jeg sammenholde med den beskrevne teori og kritikken af teorien. Derved kommer analysen til at holde teori og praksis op imod hinanden. Afslutningsvis vil jeg på baggrund af analysen besvare problemformuleringen i min konklusion og perspektivere analysen. Side 9 af 68

10 Indledning 1.5 Valg af teori Teorien tager hovedsageligt udgangspunkt i bogen Agile Project Management with Scrum. Bogen er skrevet af Ken Schwaber, der er én af grundlæggerne af scrum metodologien. Den omhandler brugen af scrum og udfordringerne forbundet herved. Bogen skaber et solidt grundlag for at forstå scrum, og den kommer med forklaringer på, hvorfor mange ikke lykkes med scrum. Dertil forklarer den også, hvordan det er muligt at overkomme disse udfordringer. Med udgangspunkt i denne bog er jeg i stand til at forholde mig kritisk til brugen af scrum-metoden. Som supplement til bogen af Ken Schwaber, har jeg valgt at benytte et indlæg fra en blog, der omhandler udfordringerne forbundet ved scrum-metoden. Jeg har valgt indlægget Scrum Will Die af John Sonmez. Indlægget beskriver de udfordringer, som han har erfaret, at metoden medfører. Han argumenterer imod Ken Schwaber i indlægget, da han mener, at scrum-metoden, gør det umuligt for virksomhederne at skabe den ønskede værdi. 1.6 Begrebsdefinition Scrum Scrum er en metode, der opstiller rammerne for et projekt, derfor defineres scrum i denne afhandling blandt andet som et rammeværktøj. Scrum kan også betragtes som en udviklings- og projektledelsesmodel. Begreberne metode, model, ramme og værktøj vil alle blive brugt om scrum. Fagtermer Jeg har nogle steder i afhandlingen valgt at benytte engelske fagtermer, da jeg finder dem mere dækkende end en oversættelse. Disse termer bruges også af praktikere af scrum, hvorfor dette findes mere korrekt. Det er eksempelvis begreber som ScrumMaster, scrum board, team og commitment. Kritikere Jeg har valgt at kalde både Ken Schwaber og John Sonmez for kritikere. Det er dog vigtigt at skelne mellem, hvad de kritiserer. Ken Schwaber kritiserer virksomhedernes evne til at benytte scrum-metoden, mens Jon Sonmez kritiserer selve scrum-metoden. Side 10 af 68

11 Indledning Scrum principperne Jeg vil i få tilfælde benytte begrebet scrum principperne. Begrebet dækker over reglerne, ritualerne, artefakterne og rollerne, som scrum-metoden indebærer. 1.7 Beskrivelse af Creuna For at give læseren et indblik i Creuna vil jeg i det følgende beskrive virksomheden. Beskrivelsen tager udgangspunkt i Crenuas hjemmeside (Creuna, 2013), og min samtale d. 28/02/2013 med medarbejderne Christian Spliid og Jesper Boeg fra Creuna. Creuna er nordens største digitale bureau. Virksomheden blev grundlagt i 2001, og de har nu kontorer i Danmark, Norge, Sverige og Finland. De lever af at levere komplette digitale løsninger til deres kunder med et strategisk udgangspunkt i hele kundens forretning. Det betyder, at de ser på hvordan teknologi kan samarbejde med kundens strategi og koncept, og de holder det op mod målinger og data. De forsøger dermed at inddrage alle tænkelige elementer af kundens forretning, således de forstår den bedst muligt. De tror på, at de kan skabe en bedre løsning for kunden ved at have kontrol over hele processen fra ide til implementation. Som følge af dette har Creuna 330 ansatte med vidtrækkende kompetencer i alt fra digitalt design, forretningsudvikling, programmering, kundeservice, marketing og projektledelse til hardcore forretningsanalyse. Det betyder, at Creuna kan hjælpe kunden lige fra de indledende strategiske spørgsmål til lanceringen af en færdig løsning, uden at de behøver at involvere andre parter. Creuna er derfor meget engageret i at inddrage kunden gennem hele processen. Således de i samarbejde med kunden kan få klarlagt målene med projektet, og hvordan produktet skal skabe værdi for dem. Derved kan de i fællesskab arbejde hen mod målet og i sidste ende skabe en ekstraordinær digital løsning. Creuna skaber værdi ved at tilføre nye dimensioner til fire overordnede områder. Disse områder er forretningsudvikling, produktudvikling, procesoptimering og marketing & salg. I dimensionen forretningsudvikling sikrer Creuna at kundens strategi matcher deres digitale behov i en hurtigt skiftende omverden. Det vil sige, at de hjælper med at integrere en digital strategi og optimere denne løbende. Produktudvikling betyder, at Creuna hjælper kunden med at tænke en digital dimension ind i deres produkt. De kan hjælpe kunder, som aldrig har tænkt digitalt før med nye såvel som eksisterende produkter. Side 11 af 68

12 Indledning Når Creuna procesoptimerer, anskuer de kundens processer fra forskellige vinkler for at blive i stand til at lave en digital løsning, der matcher deres behov. Creuna dykker ned i kundens data og kommer op med forskellige løsningsforslag, der kan optimere kundens proces. Målet er at lave en håndgribelig og brugervenlig løsning, der imødekommer slutbrugerens ønsker. Creuna kan også hjælpe kunden med at optimere marketing & salg. Dette gør de ved at udvikle virksomhedens kommunikationsplatforme og kampagner. Creuna forsøger at skabe kreative koncepter med relevante budskaber, der engagerer kundens målgruppe. I tillæg til dette finjusterer de hele tiden løsningen i forhold til slutbrugens behov og interaktion med løsningen. Derved behøver kunden ikke selv at dykke ned i datamængden, og de får løbende opdateret og optimeret løsningen. Et resultat af Creunas forretningsmodel er, at alt arbejde er projektorienteret. Derfor er projektledelse en essentiel del af virksomhedens værdiskabelsesproces. Det betyder, at Creuna hele tiden har fokus på at forbedre processen. Men dette har ikke altid være tilfældet. Creuna startede med en traditionel tilgang til projektledelse. Sagt med andre ord; et projekt begyndte med udarbejdelsen af en kravspecifikation i samarbejde med kunden, efterfulgt af intern udvikling af produktet og til sidst en præsentation af produktet for kunden. Problemet var, at alt for ofte matchede løsningen ikke kundens behov. Resultatet heraf var dårlig projektøkonomi og utilfredse medarbejdere. Creuna begyndte derfor at lede efter nye metoder, som de kunne styre deres projekter med. De besluttede, at løsningen skulle tage udgangspunkt i et agilt mind-set. Målet hermed var at skabe større værdi for kunden for derved at skabe bedre resultater for Creuna. For at lære organisationen at tænke og arbejde agilt valgte Creuna at implementere scrum. Creuna havde stor succes med at kommunikere scrum ud til medarbejderne, men efter en tid blev det dog også klart for medarbejderne, at der var en del udfordringer forbundet med scrum-metoden. Creuna endte derfor med delvist at forkaste scrum-metoden for at søge en ny en måde at optimere processen på, og de er nu i høj grad gået over til at benytte kanban. Side 12 af 68

13 Metode 2. Metode For at blive i stand til at besvare problemformuleringen har jeg valgt at foretage kvalitative, dybdegående semistrukturerede interviews. Det vil sige, at empirien i opgaven tilvejebringes gennem interviews med enkeltpersoner. På det videnskabsteoretiske plan holder opgaven sig indenfor Schleiermachers hermeneutiske vinkel, hvor det er essentielt at undersøge, hvad der subjektivt menes i stedet for at søge efter en objektiv sandhed (Sherratt, 2005). Dette indbefatter, at i forhold til at kunne forstå, hvilke udfordringer Creuna møder i forbindelse med brugen af scrum-metoden, er det nødvendigt aktivt at engagere sig med udfordringer, for at det er muligt at forstå dem. For at kunne gøre dette, tager opgaven som nævnt udgangspunkt i et casestudie og interviewet af tre ansatte hos Creuna. De semistrukturerede interviews giver mulighed for praktisering af både hermeneutiske og fænomenologiske principper ( (Luckmann and Berger, 1967) as in (Lise Justesen, 2010)). Interviews er velegnet til at beskrive fænomener i deres kontekst, og på den baggrund er det muligt at levere en fortolkning, der giver en øget forståelse af fænomenet (Lise Justesen, 2010). Interviewene hører det konstruktivistiske paradigme til, hvilket betyder, at ontologien er konstruktivistisk, og epistemologien er subjektiv (Eriksson & Kovalainen, 2011). Det vil sige at jeg som interviewer forsøger at forstå respondentens verdensopfattelse uden at påvirke denne. Schleiermachers hermeneutiske tilgang fokuserer ikke på modtagerens opfattelse af beskederne, men derimod kun på afsenderen og hermed Creunas brug af scrum (Palmer, 1969). Det vil derfor være nærliggende at antage denne videnskabsteoretiske tilgang i opgaven. Side 13 af 68

14 Metode 2.1 Overvejelser i forbindelse med dataindsamling Årsagen til, at jeg valgte semistrukturerede interviews var, at de er velegnet til undersøgelser med ønske om en eksplorativ tilgang, der stimulerer ny viden. Samtidigt fik jeg herved mulighed for på forhånd at vælge en række temaer, som jeg ønskede interviewpersonernes refleksioner over ( (Fontana & Frey, 2002) as in (Lise Justesen, 2010)). Interviewet tog derfor udgangspunkt i en interviewguide. I denne havde jeg på forhånd defineret temaer og en række hovedspørgsmål med tilhørende underspørgsmål (se bilag 4 og 5). Dette betød, at jeg havde mulighed for at stille flere spørgsmål, hvis jeg ikke mente, at det første svar var fyldestgørende. Interviewet er dokumenteret med en lydoptagelse (vedlagt CD i bilag). Sandsynligheden for at optagelsen har haft betydning for respondenternes svar er minimal, da emnet ikke er følsomt. I forhold til analysen af interviewet er interviewets kontekst mindre betydningsfuldt, da konteksten har minimal indflydelse på resultatet af analysen. Mit fokus i analysen er derfor hovedsageligt på meningsindholdet. Det er meningsindholdet, der er centralt for den fremadrettede analyse. Det betyder, at jeg ikke har fokuseret på respondentens sprogbrug, kropssprog, pauser og betænkningstid. Derfor har jeg valgt ikke at transskribere de gennemførte interviews (Kvale & Brinkmann, s ). En transskribering giver et detaljeret indblik i interviewene for læseren, og den kan hjælpe med at strukturere analysen. Men det er tidskrævende, og det er nemt at lave forståelsesmæssige fejl ved at omdanne tale til tekst (DiCicco-Bloom & Crabtree, 2006, s ). Derfor opvejer fordelene ikke ulemperne i denne afhandling, hvorfor jeg valgte transskribering fra. For at fremhæve det vigtigste fra hvert interview har jeg i stedet skrevet et interview referat (se bilag 1,2 og 3). Referatet er baseret på detaljerede noter, som jeg har taget, mens jeg lyttede til, de indspillede interviews. Alle noter til interviewene blev taget mindre end firetyvetimer efter, at interviewene var blevet gennemført, således de var friske i min erindring. For at strukturere interview referatet i forhold til analysen, valgte jeg at benytte kodning. Jeg valgte at benytte kodning for at strukturere analysen på en måde, som jeg fandt logisk. Jeg farvelagde en tekstdel i forhold til, hvilken del af analysen, den vedrørte. Eksempelvis farvelagde jeg alt vedrørende Creunas forventninger i rødt. Side 14 af 68

15 Metode Valg af respondenter Jeg fik mulighed for at interviewe tre forskellige medarbejdere hos Creuna. To af dem var projektledere, mens den sidste var senior konsulent inden for systemudvikling. Fordelen ved at interviewe to projektledere var, at de i højere grad var i stand til at bevæge sig et abstraktionsniveau op. Det var naturligt for dem at tage stilling til og sammenholde brugen af forskellige projektledelsesmodeller. I modsætning hertil var senior konsulenten bedre til at svare på spørgsmål, der omhandlede udførelsen projekterne. Alle tre interviews varede omkring en time, hvilket var nok til at give et forholdsvist detaljeret indblik i virksomheden. De tre medarbejdere svarede forholdsvist ens på mange af spørgsmålene på trods af, at de blev interviewet på forskellige tidspunkter. Derved har de underbygget flere af hinandens svar, hvilket styrker analysens troværdighed. Jeg ville dog gerne have haft et eller to interviews yderligere, da det kunne nuancere analysen yderligere. Det ville have været interessant at tale med en eller to personer fra Creunas ledelse. Da de ville have været i stand til at svare på spørgsmål omkring de strategiske overvejelser, der var forbundet med valget af model Opbygning af interviewguide Inden jeg gennemførte interviewene med de tre medarbejdere, brugte jeg lang tid på at opbygge en interviewguide. Det var vigtigt for mig, at spørgsmålene i interviewguiden var relevante i forhold til problemformulering og den efterfølgende analyse. Derfor gennemgik jeg dem flere gange, og strukturerede dem efter temaer. Derved styrkede jeg også opgavens validitet. Interviewene tog udgangspunkt i to næsten identiske interviewguides. Forskellen på de to interviewguides var primært vinklen på nogle få spørgsmål, ellers var der kun et par spørgsmål, der varierede i de to interviewguides. I begge interviewguides var det generelle fokus på: - Hvorfor Creuna valgte scrum-metoden, og hvilke forventninger de havde til metoden? - Hvilke udfordringer Creuna mødte, og hvorfor de forkastede metoden? - Hvordan Creuna arbejder med projektledelse i dag, og hvilke udfordringer de møder? Det er disse spørgsmål, der danner grundlaget for analysen, og dermed bliver de i sidste ende brugt til at besvare problemformuleringen. Side 15 af 68

16 Metode 2.2 Gennemførelse af interview Jeg valgte at dele interviewet op i tre faser, som det anbefales af Lise Justesen (Lise Justesen, 2010). I første fase præsenterede jeg interviewpersonen for formålet med undersøgelsen, opbygningen af interviewet og tidsrammen. Dertil talte vi et par minutter om løst og fast. Dette resulterede i, at de forholdsvis hurtigt blev trygge med situationen. Jeg forklarede også alle interviewpersonerne, hvordan materialet vil blive brugt og præsenteret, hvilket alle var indforstået med. Denne del af interviewet varede mellem 5-10 minutter. I anden fase indledte jeg hvert hovedspørgsmål med at forklare konteksten, som spørgsmålet skulle forstås i. Herefter stillede jeg spørgsmålet og gav respondenten tid til at svare på dette. Jeg stillede yderligere spørgsmål, hvis interviewpersonen bevægede sig i en spændende retning, eller når jeg følte, at det var nødvendigt at få uddybet hovedspørgsmålet med underspørgsmål. Det var en flydende proces, hvor respondenterne talte i størstedelen af tiden. Denne del af interviewet varede i mellem minutter. Tredje fase var afslutningen på interviewet. Her gav jeg interviewpersonerne et signal til, at interviewet var ved at slutte. Dette gjorde jeg ved at sige, dette var faktisk mit sidste spørgsmål. Er der noget, som du mener, at jeg har forbigået? Eller har du noget, som du gerne vil tilføje?. Hvis de ikke havde noget at tilføje, sagde jeg pænt tak for deres tid og deltagelse. Den sidste del af interviewet varede mellem 5-10 minutter. 2.3 Kritik af metodeafsnit Det var svært for mig, at leve op til det fænomenologiske kriterium om, at en forsker skal have en fordomsfri tilgang til analysen. Jeg havde læst flere kritiske artikler inden undersøgelsen, hvorfor det var svært at gennemføre interviewene uden forudfattede meninger. I tillæg til dette havde jeg været til en uformel snak med to af virksomhedens medarbejdere et par uger inden interviewene. Derfor havde jeg allerede en ide om, hvordan virksomheden arbejdede med projektledelse, og hvorfor de forkastede scrum-metoden. Dette gjorde, at jeg i højere grad søgte svar, som bekræftede mine forventninger, end svar der afkræftede dem. Et andet kritikpunkt er, at der kan være stor forskel på, hvad en respondent tænker, og hvad personen rent faktisk giver udtryk for. Respondenterne kan føle sig forpligtiget til at tale positivt omkring kanban, fordi Creuna på nuværende tidspunkt benytter denne metode. Det kan også Side 16 af 68

17 Metode være, at jeg som interviewer minder om respondentens chef, og det får personen til at svare anderledes. Det er umuligt at afklare, om dette har haft indflydelse i denne undersøgelse. Det er derfor vigtigt at have in ménte, da risikoen er til stede. Ved en dyberegående undersøgelse ville det være muligt at måle respondentens mikro impulser i hjernen for derved at fjerne risikoen. (Lindstrøm, 2001, s ) Interviewene forløb heller ikke fejlfrit, hvilket hovedsagelig skyldtes min manglende erfaring som interviewer. Processen blev til tider rodet, da de åbne spørgsmål resulterede i, at respondenten svarede på flere af mine spørgsmål samtidigt. Jeg mistede derfor overblikket i spørgeguiden, og jeg kom et par gange til at stille et spørgsmål, som respondenten allerede havde svaret på. Derudover stillede jeg et par gange ledende spørgsmål, og jeg kom med eksempler på svar, hvis respondenten ikke forstod formuleringen af spørgsmålet første gang. Jeg skulle i stedet have omformuleret spørgsmålet til et nyt åbent spørgsmål. Formålet med at lave en interviewguide er, at den skal være i stand til at måle formålet med analysen. Altså spørgsmålene i interviewguiden skal gøre mig i stand til at besvare problemformuleringen. På denne måde sikres det, at opgaven har en høj validitet. Derfor var det problematisk, at jeg til tider rodede rundt i interviewguiden, og jeg stillede ledende spørgsmål. Jeg har dog forsøgt at højne validiteten ved at få respondenterne til at godkende indholdet af de enkelte referater, hvilket de alle gjorde. Interviewet og referatet kan også sætte spørgsmålstegn ved afhandlingens reliabilitet. Begge dele er fortolket af mig, hvilket målenøjagtigheden afhænger af. Meningsindholdet afspejler min subjektive opfattelse af respondenternes svar. Det er en kombination af min erindring af respondenterne på svartidspunktet og min forståelse af lydoptagelsen. Jeg har dog bestræbt mig på, at forholde mig objektivt gennem hele processen, og det samme vil jeg gøre i analysen. 2.4 Kildeanalyse Bogen Agile Project Management With Scrum af Ken Schwaber er anerkendt af mange inden for software udvikling og projektledelse. Det fremgår også af de første afsnit, hvor den bliver per reviewed. Bogens pålidelighed og relevans bliver underbygget af, at det er én af de to skabere af scrum, som har skrevet den. Ken Schwaber har mange års erfaring med at arbejde med og un- Side 17 af 68

18 Metode dervise i scrum. Det formodes derfor, at han har en dyb indsigt i metoden, og udfordringerne den medfører. Det er dog vigtigt at have for øje, at Ken Schwaber som skaber, underviser og forretningsmand også har en interesse i at få metoden til at fremstå succesfuld. Blogindlægget Scrum Will Die er i modsætning til bogen 100% subjektiv og ikke videnskabelig. Forfatteren er praktikeren John Sonmez (Sonmez, About). Bloggen bygger på hans erfaring med scrum og agil udvikling. Han får ikke et personligt udbytte af at få scrum til at fremstå i et specifikt lys. Derfor kan han tillade sig at forholde sig objektivt til metoden. John har fingeren på pulsen, hvorfor det er vigtigt, at være åben overfor hans syn på agil udvikling. Han har et solidt grundlag for at vurdere metodens anvendelighed (Sonmez, LinkedIn, 2013). I forhold til afhandlingens troværdighed havde det været bedre at benytte en videnskabelig artikel. Men de personer, som praktiserer agiludvikling, udtrykker sig sjældent gennem videnskabelige artikler. De benytter andre medier, hvor det er hurtigere og nemmere at udtrykke sig. Jeg valgte John Sonmez blogindlæg fremfor mange andre bloggere, da han fremstår mere reel. Da han beskriver udfordringerne med udgangspunkt i teorien, og han forsøger at argumentere for, hvorfor teori og praksis ikke hænger sammen. Dette var at foretrække frem for andre bloggere, der blot fremhæver udfordringerne. Han giver samtidigt udtryk for, at han godt kan lide scrummetoden, og han har benyttet metoden gennem mange år. I den forbindelse har han oplevet en række udfordringer, som han gerne vil dele med andre. Side 18 af 68

19 Teoretisk afsnit 3. Teoretisk afsnit 3.1 Scrum teorien Jeg vil i det følgende beskrive min forståelse af scrum teorien. Målet er at skabe en fællesforståelse af scrum teorien for læser og jeg. Et fælles paradigme er vigtigt for den efterfølgende analyse og konklusionerne, der bliver dannet på baggrund heraf. Afsnittet tager udgangspunkt i Agile Project Management With Scrum af Ken Schwaber (Schwaber, Agile Project Management With Scrum, 2003). Ordet scrum stammer oprindeligt fra rugby. Udtrykket bruges, når spillerne på et hold stiller sig tæt sammen og danner én enhed, der i fællesskab fører bolden op ad banen (Westmoreland, 2008). Det er samme filosofi, der ligger bag ordet i udviklingssammenhæng. Scrum er en agil projektledelsesmodel, der benyttes til at løse komplekse opgaver i forbindelse med software projekter. Kompleksiteten i softwareprojekter gør det ofte vanskeligt at forudsige et resultat, og derfor er det ikke muligt at benytte definerede processer til at kontrollere projekternes kvalitet. Virksomheden skal have en tilgang til projekterne, hvor processen ikke er defineret på forhånd. En sådan tilgang er scrum baseret på, og den hedder empirisk proceskontrol. Empirisk proceskontrol består af tre dele; gennemsigtighed, inspektion og tilpasning. Gennemsigtighed betyder at de aspekter af en proces, der kan påvirke resultatet, skal være synlige for dem, der kontrollerer projektet. Inspektion betyder, at processen skal inspiceres ofte, således varianser opdages og tilpasses. Dette er vigtigt, da det er inspektioner, der bidrager til at ændre projektets kurs. Tilpasning betyder at de forskellige procesaspekter, som en inspektør mener er utilstrækkelige skal tilpasses, således at processen igen er tilstrækkelig. Det er meget vigtigt, at tilpasningerne bliver gennemført hurtigst muligt for at minimere den fremtidige variation i processen. Gennemsigtighed, inspektion og tilpasning er indbyrdes afhængige, og det er samspillet mellem disse, der gør det muligt for en virksomhed at løse komplekse opgaver. For at få give læseren en forståelse for hvordan scrum teorien tager udgangspunkt i dette, vil jeg nu beskrive teorien. Side 19 af 68

20 Teoretisk afsnit Scrum er et rammeværktøj, der gør virksomheder i stand til at arbejde agilt. Rammen er et iterativt forløb, hvor outputtet af hver iteration er et produktinkrement. Iterationerne er korte og faste for at sikre hurtig feedback. Den bagvedliggende tanke er, at kunden sjældent kender alle sine behov og ønsker i projektets indledning, men i takt med projektet skrider frem, og deres viden om produktet øges, vil det blive nemmere for dem at definere deres egentlige behov. Den løbende feedback er derfor central, da det gør udviklerne i stand til at tilpasse løsningen til skiftende behov. Et scrum projekt starter typisk med en workshop, hvor kundens behov defineres. Behovene defineres som opgaver, der tilsammen udgør en product backlog. En produktejer prioriterer opgaverne efter, hvilken værdi de skaber for kunden. Opgaverne der skaber mest værdi prioriteres øverst. Én iteration i et scrum projekt kaldes for et sprint. Inden hvert sprint committer teamet sig til et antal opgaver fra product backlogen, som bliver tilføjet en sprint backlog. Mængden af opgaver der tilføjes sprint backlogen bestemmes af, hvor mange opgaver teamet mener, at de kan færdiggøre i det kommende sprint. Teamet arbejder på disse opgaver gennem hele sprintet, og ved sprintets afslutning præsenterer teamet den funktionalitet, som de har udviklet for kunden. Herefter har kunden mulighed for at give feedback til teamet. Ud fra denne feedback kan teamet i samarbejde med produktejeren tilføje nye opgaver til product backlogen og prioritere disse på ny. Derved bliver produktet tilpasset kundens ønsker. Denne proces fortsætter, indtil kunden er tilfreds med produktet. Produktet er funktionelt ved enden af hvert sprint, derfor kan kunden også vælge at få implementeret et produktinkrement, inden det udvikles yderligere. For at give et detaljeret indblik i de enkelte dele af scrum, vil jeg uddybe dem i det følgende. Der er kun tre roller i et scrum projekt til at sikre, at processen fungerer. Derfor er alt ledelsesmæssigt ansvar fordelt mellem disse roller. Det drejer sig om produktejeren, teamet og Scrum- Masteren. Produktejeren repræsenterer kunden og alle andre, der har en interesse i projektet. Personen er ansvarlig for at sikre finansieringen af projektet. Produktejeren gør blandt andet dette ved at specificere kravene til projektet, sætte mål for ROI og udarbejde en release plan. Kravene til projektet prioriteres på en liste kaldet product backlogen. Produktejeren prioriterer kravene efter den værdi, som de tilfører det endelige produkt. Side 20 af 68

21 Teoretisk afsnit Produktejerens primære formål er løbende at opdatere listen med prioriteter, og godkende opgaverne som teamet arbejder på. Produktejeren kan dermed styre udviklingen ved hjælp af product backlogen. I tillæg til dette fungere produktejeren også som bindeled mellem projektets interessenter og teamet. Et team består af en række medarbejdere, som kan løse kundens opgaver. Det er teamet, der har ansvaret for, at udvikle den ønskede funktionalitet. De er selvledende, selvorganiserende og krydsfunktionelle, hvilket betyder, at de selv er ansvarlige for at sammensætte et team, der kan løse opgaverne i et projekt. I tillæg til dette vælger de også selv, hvilke opgaver de arbejder på. Et optimalt team består af fire til ni medarbejdere. Hvis et team er større end dette, bliver det svært for dem, at leve op til overstående kriterier, hvorfor det er bedre at dele dem op i mindre teams. For at gøre det muligt at udvikle et produktinkrement i hvert sprint skal alle teams have kompetencerne indenfor alt fra design, kodning og integration til test og implementering. Det er kun et team, der opfylder disse kriterier, der anses som værende krydsfunktionelt. Inden hvert sprint skal teamet i samarbejde med produktejeren vælge, hvor meget af product backlogen, de kan omdanne til funktionalitet i det kommende sprint. Det er teamets ansvar at alle opgaver, der udvælges kan færdiggøres. Det vil sige, at teamet committer sig til de opgaver, som de vælger. ScrumMasteren er ansvarlig for projektets succes. Han skal øge sandsynligheden for succes ved at hjælpe produktejeren med at prioritere de mest værdifulde dele af product backlogen. Dertil skal han gøre teamet i stand til at forvandle product backlogen til funktionalitet. Dette gør han blandt andet ved, at sikre scrum reglerne bliver overholdt, og der ikke er nogen barrierer mellem produktejeren og teamet. Dertil skal ScrumMasteren sørge for, at teamet og produktejeren bliver uddannet i brugen af scrum. ScrumMasteren skal også beskytte teamet mod udefrakommende faktorer. Det kan eksempelvis være interessenter, som forsøger at påvirke teamet i en bestemt retning eller ændre projektets kurs. Det er ScrumMasterens opgave at sikre, at projektet forløber så glat som muligt. Det vil sige, at personen skal løse de organisatoriske problemer, som måtte opstå. Dette skal personen gøre uden at give ordrer, men ved at vejlede. Side 21 af 68

22 Teoretisk afsnit En product backlog er en liste med funktionelle og ikke-funktionelle krav. Listen tager udgangspunkt i interessenternes ønsker, som bliver formuleret af produktejeren. Product backlogen er prioriteret således at opgaverne, der forventes at skabe den største værdi udvikles først. Produktejeren estimerer sammen med teamet på et release planning møde i starten af hvert projekt, hvor lang tid opgaverne vil tage, og hvordan de skal prioriteres. I takt med produktet begynder at tage form vil kravene til produktet ofte ændres, hvorfor product backlogen løbende skal tilpasses til de skiftende behov. Formålet med product backlogen er derfor at få specificeret, hvad der på et givent tidspunkt skaber mest værdi for kunden at få udviklet. Ved brugen af scrum udføres alt arbejde i sprints. Et sprint er normalt 30 kalender dage. Det varierer dog fra projekt til projekt. Teamet vælger et antal opgaver fra product backlogen, som de mener er realistiske at færdiggøre inden for et given sprint. Disse opgaver placeres i en sprint backlog, hvor de deles op i mindre opgaver. Sprint backlogen er oftest visualiseret ved hjælp af et scrum board. Scrum boarded viser opgaverne, som er valgt til et givent sprint. I tillæg til dette viser scrum boarded, om en given opgave er i gang, venter eller færdig. Derved kan teamet se, hvad der bliver arbejdet på. Det er i den forbindelse vigtigt, at produktejeren i samarbejde med holdet definerer begrebet færdig. Hvis medarbejderne har forskellige opfattelser af ordet færdig vil det ikke være muligt at implementere produktinkrementet efter et sprint. Hvert sprint bliver indledt med et sprint planlægningsmøde. Her samarbejder produktejeren og teamet om at beslutte, hvad der skal udvikles i det kommende sprint. De tager udgangspunkt i den højeste prioritet på product backlogen. Produktejeren bruger den første halvdel af mødet på, at forklare hans ønsker for det kommende sprint. Teamet giver i den sidste halvdel af mødet et bud på, hvor meget af product backlogen de kan omdanne til funktionalitet. Dette gør de ved at estimere, hvor lang udviklingstiden er på de enkelte opgaver. De vil typisk dele opgaverne op i kasser, således de placeres i kasser af 2, 4, 6 eller 8 timers arbejde. Hvis de ikke passer ned i én af disse kasser, bryder de opgaverne yderligere ned. Planlægningsmødet må maksimalt vare 8 timer. Målet er, at bruge så lidt tid som muligt på at planlægge det fremtidige arbejde. Dermed skaber de en mindre overhead omkostning, da teamet kan begynde at bruge tiden på at udvikle den ønskede funktionalitet i stedet for at planlægge. Side 22 af 68

23 Teoretisk afsnit Efter hvert sprint afholdes et fire timers sprint evalueringsmøde. Her præsenterer teamet det inkrementelle produkt, som de har udviklet for produktejeren og andre interesserede. Formålet med mødet er at give teamet feedback og at samarbejde om, hvad der skal udvikles i næste sprint. I tillæg til sprint evalueringsmødes afholder ScrumMasteren et tre timers retrospektiv møde med teamet. ScrumMasteren opfordrer teamet til at revidere det netop overståede sprint, således de kan effektivisere brugen af scrum i det næste sprint. Hver dag afholdes et 15 minutters stand-up møde. Teamet mødes, og hver enkelt medarbejder opdaterer de andre i teamet omkring deres situation. Dette gør de med udgangspunkt i tre spørgsmål: - Hvad har du færdiggjort siden det sidste daglige stand-up møde? - Hvad planlægger du at lave mellem dette møde og det næste stand-up møde? - Hvilke hindringer står i vejen for, at du når dine forpligtigelser for dette sprint og projektet? Formålet med mødet er, at synkronisere teamets arbejde. Dertil giver det også medarbejderne mulighed for at hjælpe hinanden. Det bliver kaldt et stand-up møde, da teamet står op, mens de holder mødet. Derved sikrer de, at mødet ikke trækker ud. Til at vurdere et projekts fremgang benytter teamet en burndown graf. Denne graf er relevant for alle parter, der er involverede i projektet. Grafen viser mængden af arbejde, som teamet mangler at gennemføre over tid. Grafen visualiserer korrelationen mellem mængden af tilbageværende arbejde på et givent tidspunkt og teamets evne til at mindske mængden af arbejde. Dette gør det muligt at komme med et konkret bud på en færdiggørelsesdag for projektet. Samtidigt er det også nemt at lave en hvad-hvis-analyse, da det er muligt at ændre på én eller flere faktorer, hvorefter færdiggørelsesdatoen tilpasses øjeblikkeligt. Ifølge Ken Schwaber er det essentielt, at organisationer ikke afviger fra metoden, hvis de ønsker at få fuldt udbytte af den. Han siger, at metodens faste rammer gør problemer i en organisation synlige, hvilket kan være frustrerende for mange. De beskylder derfor metoden for ikke at passe ind i deres kontekst. Han siger, at de i stedet skal imødekomme de organisatoriske problemer, Side 23 af 68

24 Teoretisk afsnit som bliver gjort synlige, da formålet med de faste rammer netop er at fremtvinge de organisatoriske problemer. Det kræver engagement og commitment fra organisationens side at indse dette. Side 24 af 68

25 Teoretisk afsnit 3.2 John Sonmez s kritik af scrum-metoden Formålet med dette afsnit er at uddybe John Sonmez kritik af scrum teorien. Det er vigtigt at fremhæve John Sonmez s kritikpunkter, da den kommende analyse vil blive holdt op mod disse. Kritikken er baseret på blogindlægget Scrum Will Die af John Sonmez (Sonmez, Scrum Will Die, 2010). John Sonmez er uenig med Ken Schwaber i, at organisationer blot skal committe sig til metoden, for at få succes med den. Han mener, at mange virksomheder afviger fra metoden og bevæge sig væk fra den, da dette giver et bedre resultat. John mener, at metoden er et værdifuldt redskab til at lære den agile tankegang, men den er utilstrækkelig i forhold til at skabe værdi og arbejde agilt. Scrum var den første metode inden for den agile verden, som for alvor fik en stor tilhængerskare. John mener, at dette hovedsageligt skyldtes, at metoden er nem at forstå og kommunikere ud, ikke at den skaber den ønskede værdi. Derfor sætter han spørgsmålstegn ved, om metoden er holdbar på sigt for virksomheder, der ønsker at arbejde agilt. Scrum adresserer mange af de traditionelle udfordringer, som et team står overfor, men samtidigt skaber metoden også en række agile udfordringer. John Sonmez har identificeret, hvad han mener, er de største udfordringer ved at benytte scrum-metoden. Udfordringerne har det tilfældes, at de alle udspringer af, at scrum bygger på en vis grad af planlægning. John mener, at planlægning er spild af tid, da det i bund og grund betyder, at teamet bruger tid på noget, der ikke skaber værdi på bundlinjen. Én dags planlægningsarbejde resulterer i en 10% overhead omkostning i et to ugers sprint. Det første store problem ved planlægning er, at det er baseret på estimater, som teamet laver. Men forudsætningerne for at lave et estimat er ikkeeksisterende, da estimatet tager udgangspunkt i teamets produktivitet fra tidligere opgaver. Problemet er, at teamet er ustabilt, og det er umuligt at lave et estimat baseret på gennemsnittet af et ustabilt element. Derfor er det ikke værdiskabende at bruge tid på at estimere opgaver. Side 25 af 68

26 Teoretisk afsnit Et andet centralt problem er commitment. Teamet committer sig til et antal opgaver, som de skal løse i et sprint. Resten af virksomheden committer sig samtidigt til, ikke at ændre opgaverne som teamet arbejder på. Dette er essentielt for scrum, ellers fejler planlægningen og tilliden til metoden. Problemet er, at det er umuligt at overholde disse commitments. Virksomheden ønsker ikke at ændre prioriteringen af opgaverne midt i et sprint, men de kan blive nød til det, hvis der opstår et kritisk problem. I tillæg til dette er der en naturlig grænse for teamets kapacitet. Det betyder, at virksomheden er tvunget til at bryde sin commitment eller ændre sin plan, hvis de ønsker at tilpasse sig problemet. Det vil sige, at virksomheden skal afvige fra scrum teorien på den ene eller anden måde. Alternativet er, at de ikke afviger, og dermed ikke imødekommer kundens ønsker. En del af scrum er de daglige stand-up møder. I teorien er møderne en rigtig god ide, men i praksis er de ofte værdiløse. Problemet er, at medarbejderne allerede ved, hvilke opgaver de andre medarbejdere arbejder på. Det ved de, fordi de alle arbejder på den samme product backlog, og de benytter programmeringsmetoder, der opfordrer til samarbejde. Derfor bliver mødet ofte kun gennemført, fordi scrum teorien foreskriver dette, men det skaber ingen værdi. Der bliver blot brugt værdifuld udviklingstid på at tale om noget, som alle i forvejen kender til. I de tilfælde, hvor medarbejderne ikke arbejder tæt sammen til dagligt, har møderne en tendens til at blive en time i stedet for et kvarter. Derved går der for meget potentiel udviklingstid med at snakke om opgaverne. Begge eksempler er uholdbare på lang sigt. I tillæg til overstående fremhæver John en sidste udfordring ved scrum-metoden, hvilket vedrører produktejer-rollen. Teoretisk set sikrer rollen, at teamet arbejder på de rigtige opgaver, og de ikke bliver påvirket af udefrakommende faktorer. I realiteten bevirker rollen, at virksomheden lægger produktets skæbne i hænderne på én person. Problemet er, at det er få personer, der kan opfylde kravene til denne rolle. Hvis personen er højtstillet i organisationen, ender det ofte med, at han agerer chef mere end produktejer. Teamet mister derfor følelsen af at være selvledende og selvorganiserende. Hvis personen er mindre betydningsfuld, ender virksomheden med en person, der ikke kan tage en beslutning, og alle andre omkring produktejeren ender samtidigt med at føle sig værdiløse. Side 26 af 68