De valgte metoder og det sammenfattede forløb sættes afslutningsvist ind i en designvidenskablig kontekst.

Størrelse: px
Starte visningen fra side:

Download "De valgte metoder og det sammenfattede forløb sættes afslutningsvist ind i en designvidenskablig kontekst."

Transkript

1 Synopsis Denne rapport viser, hvordan tegnestuen Arkitemas brug af ledelses værktøjet scrum, optimeres ved hjælp af, specialdesignet værktøj. Igennem empirisk indsamlet data produceres en omfattende behovsanalyse, hvor fokus på det intuitive værktøj, som skaber historik og overblik er i centrum. Den omfattende behovsanalyse danner efterfølgende grund for et iterativt designforløb med brugeren i fokus. Dette fokus opnås hovedsagelig igennem brug af en række test forløb. De valgte metoder og det sammenfattede forløb sættes afslutningsvist ind i en designvidenskablig kontekst. Rapporten inddrager dimensionerne design og konstruktion. Dimensionen design fordi der er fokus på designprocesser såvel som designmetoder, dimensionen konstruktion da et værktøj til scrum bliver designet og programmeret. Rapporten konkludere, at Arkitemas brug af scrum, er blevet forbedret ved hjælp af det specialdesignede værktøj, ydermere konkluderes det at værktøjet også har sin berettelse uden for denne kontekst Freja Bange Nyboe Louise Smed Møller Tobias Bornakke Jørgensen Jens Jarl Broe 1 S ide

2 Forord Vi har igennem følgende rapport, stræbt efter at benytte et klart og præcist skriftsprog, der formidler informationen uden omsvøb, for herved at gøre teksten let tilgængelig for læseren, forståelig og præcis frem for ophævet og fremmedgjort. Rapporten er skrevet således, at der forekommer både kildehenvisninger og fodnoter. Kildehenvisninger vil i teksten være noteret med APA-stil, der henviser til den brugte kilde, der er at finde i kapitlet 'litteraturliste'. Fodnoterne vil indeholde uddybende eller forklarende information om emnet og vil være tilgængelige i bunden af den pågældende side og betegnes med nummereringer. Den opmærksomme læser vil bemærke at rapportens beskrivelser, med næsten pinlig nøjagtighed, afspejler nedenstående processtruktur. Dette skyldes, at vi i vores skrivning har været optaget af de overordnede tanker bag David Parnas og Paul Clements artikel A rational design proces: How and why to fake it (Parnas & Clements, 1986). I denne artikel præsenterer de to forskere først en række grunde til at en designproces aldrig nogensinde vil være 100% rationel. Blandt argumenterne finder vi denne lille perle, der meget fint viser, hvorfor: "5) Human errors can only be avoided if one can avoid the use of humans...". Videnskabeligt set holder den irrationelle designproces imidlertid ikke den samme værdi som den rationelle, fordi den er meget sværere at følge. (Parnas & Clements, 1986, s. 2) På den baggrund er nedenstående rapport skrevet af mennesker til mennesker. - God fornøjelse! 2 S ide

3 3 S ide

4 Procesmanual I følgende afsnit giver vi en visuel beskrivelse af projektets processtruktur. Vi har i vores opbygning af rapporten, for at lette læsningen, ladet processtrukturen afspejle sig i rapportens fysiske komposition. Projektets processtruktur er funderet i Alan R. Hevner et al s model, der her ses i sin oprindelige udgave: Figur 1: Hevners model over IS forskning (Pries Heje (red.), 2008A, 1. forelæsning) Ud fra Hevners model ønsker vi, at fastsætte en rationel designproces for hele projektforløbet. Dette er gjort ved at forklare den relation rapportens afsnit har i forhold til Hevners model, hvorved en samlet kronologisk designproces opstår. Kausaliteten mellem rapport og designproces, resultere altså i en procesmanual der guide vejen - fra problem til løsning. Udover at fungere som en procesmanual internt i gruppen, er formålet med den visuelle model også at guide 4 S ide

5 læseren. Idealet for modellen er, at læseren kan holde sig orienteret i rapportens enkelte afsnit og derved opnå et overblik over de enkelte afsnits relevans i forhold til rapportens samlede scope. Lidt forsimplet kan de enkelte afsnit ses som puslespilsbrikker, og vores adopterede Hevner model som oversigtbilledet der hjælper læseren til at samle brikkerne. Figur 2: Vores forløb skitseret vha. den ofte benyttede projekt fisk (Pries Heje (red.), 2008A, 3. forelæsning). Som det af ovenstående model fremgår, er procesmanualen delt op i fire overordnede faser. Derudover benyttes to forskellige niveauer: 'projekt niveau' og 'design niveau'. De to niveauer henholdsvis fiskens hoved og hale og afspejler de to grundlæggende perspektiver, som gruppen benytter i rollen som henholdsvis RUC studerende og designere. Projektniveauet er et slags metaniveau der fungerer som en teoretisk projektramme for designniveauet. I første fase (Projektdefineringen) defineres det videre projektforløb med afsæt i problemformuleringen. I det afsluttende projektniveau (Projektperspektivering), opsummeres projektet, ved konkludere på problemformuleringen og ved i perspektiveringen, at sætte rapporten ind i en større videnskabelig kontekst. Ud fra ovenstående model og Hevners model den føromtalte procesmanual som vil blive præsenteret i det følgende afsnit. 5 S ide

6 Projektniveau Projektdefinering (1. fase) Indeholder følgende afsnit: Kapitel 1:Problemfelt, Problemformulering, Problemafgrænsning Omgivelser Erfaring Processer Kultur Vidensbase Projektledelse Problemformulering Første fase bærer titlen projektdefinering fordi det er denne fases funktion, at sætte rapporten ind i en faglig kontekst samt her igennem argumenterer for rapportens relevans. Argumenterne herfor findes i problemets omgivelser samt den videnskabelig vidensbase hvorudfra projektets problemformulering udarbejdes. Designniveau Behovsindsamling (2. fase) Indeholder følgende afsnit: Kapitel 2: Introduktion til Scrum teori Kapitel 3: Interview metode, Foranalyse metode, Observation metode Kapitel 4: Resultaterpåindsamlet data Problemformulering fra 1. fase Vidensbase Teori Metode Rammeværker Best practise Omgivelser Erfaring Interview Observation Databehandling Definere behov (analyse) Behov 6 S ide

7 Med udgangspunkt i problemformuleringen fra 1. Fase, har Behovsindsamlingen til formål at fremstille de essentielle behov til det endelige design. Dette gøres i tre trin. Først introducerer de grundlæggende teori om Scrum, som vores design skal forholde sig til. Herefter præsenterer vi vores metodiske overvejelser, i forhold den efterfølgende dataindsamling. Til sidst anvendes denne viden til gennemførelse af en iterativ behovsanalyse i det kommende designs miljø. Heri defineres de konkrete brugere og organisationers behov. Til sidst bearbejdes disse data og en kravspecifikation for det endelige design udarbejdes. Designniveau Design (3. fase) Indeholder følgende afsnit: Kapitel 5:Design Kapitel 6:Test, evaluering Kapitel 7:Beskrivelse af produkt Behov fra 2. fase Iterativ proces Produkt design Evaluer Vidensbase Design metoder Test metoder Resultat Med udgangspunkt i de behov, der er blevet defineret i den forudgående fase, gennemføres i design fasen en iterativ designproces med løbende evaluering. Udover de udarbejdede behov trækker vi på metoder og teknikker fra vidensbasen. Efter sidste iteration gennemføres en større ex post test af designet samtidig med at selve designet beskrives. dette sammenfattes med den afsluttende test og evaluering, disse to sammenfattet afkaster et endeligt resultat. 7 S ide

8 Projektniveau Design proces (4. fase) Indeholder følgende afsnit: Kapitel 8:Konklusion Kapitel 9:Perspektivering Er designet anvendeligt? Resultater og erfaringer Udbygget vidensbase? Anvendelse Tilføjelse I denne fase går vi et niveau op og behandler resultater og erfaringer opnået i projektet i en videnskabelig kontekst. Kan designet anvendes i den virkelige verden og er denne viden gyldig uden for vores kontekst? 8 S ide

9 Indholdsfortegnelse Synopsis...1 Forord...2 Procesmanual...4 Del 1 Projektdefinering Indledning Problemfelt Problemformulering Problemafgrænsning Del 2 Behovsindsamling Scrum teori Roller Forløb Artefakter Metodiske overvejelser af dataindsamling Interview som metode Motivation for valg af interviewpersoner Foranalyse Observation som metode Behovsanalyse Interview med Joos Jerne Interview med Morten Stahlschmidt Design behov To Scrum or not to Scrum Opsummering/kritik Foranalyse gennemførelse og diskussion Observation af Scrum møde med Arkitema Problemer relateret til udførelsen af Arkitemas Scrummøde Andre kilder S ide

10 4.10. Delkonklusion og kravspecifikation Del 3 Designproces Design Overordnet forløb Metode og teknik Designforløb Test og evaluering Overordnede tanker Test i naturlig kontekst Papirprototyping Tænkehøjtforsøg Afsluttende test hos Arkitema Designbeskrivelse Programmets funktioner Ikke implementerede funktioner Layout Opsummering Del 4 Projektperspektivering Konklusion Perspektivering Litteraturliste S ide

11 Del 1 Projektdefinering 1. Indledning 1.1. Problemfelt I starten af det 19. århundrede opstod der en større bevidsthed om procesforbedring i erhvervslivet. Denne bevidsthed var specielt Frederick Winslow Taylor fortaler for igennem sin introduktion af begrebet scientific management - i vore dage kendt som taylorisme eller fordisme 1. Scientific management er en ledelses teori, hvor man analyserer og syntetiserer arbejdsprocessen, for derved at højne produktiviteten (Copley, 1923). I vore dage bliver processor, der følger Taylors teorier ofte betegnet som 'samlebåndsarbejde'. Det ligger altså implicit, at scientific management specielt henvender sig til statiske og ensartede produktioner. Som vi senere skal komme ind på, gør det modsatte sig gældende i moderne projektledelse; nemlig at projekter aldrig kan betragtes som ens og derfor har væsentlige afvigelser fra samlebåndsarbejdet (Biering-Sørensen, 2004). Til trods for dette repræsenterer Taylors bevidsthed om struktureret 'procesforbedring' i vores øjne et markant vendepunkt i den idehistoriske forståelse af projektledelse og skal ses i kontrast til tidligere ledelsesformer, hvor beslutningerne oftere blev taget på baggrund af traditioner og 'tommelfinger-regler'. I 1910 tog Henry Gantt, med udgangspunkt i Taylors idé om scientific management, næste skridt imod en mere struktureret og reflekteret projektledelse med hans artikel Work, Wages and Profit i The Engineering Magazine. Her præsenteres det, der senere er blevet døbt Gantt chart. Gantt chartet er et effektivt værktøj til at planlægge og skemalægge aktiviteter i projekter, ved at dechifrere og opdele den samlede opgave i mere eller mindre afhængige aktiviteter (se eksempel, figur 3) 1 Hvilket skyldes at en af de første der i praksis tog den Tayloristiske tilgang til sig var bilfabrikanten Ford. 11 S ide

12 . Figur 3: Eksempel udgave af gant chart (Harrison) Gantt chartet henvender sig mest til aktiviteter, der er forholdsvis lette at tidsestimere, da der i Gantt chartet ikke umiddelbart er implementeret funktioner til håndtering af uforudsete ændringer. Som det fremgår på figuren, repræsenterer den horisontale linje den tid, de enkelte aktiviteter er estimeret til, samtidig med at den skaber en oversigt over den samlede tidslinje. Af den vertikale linje kan projektets faser aflæses. Når de to linjer kombineres, giver Gantts charts altså et hurtigt overblik over projektets fortid, nutid og fremtid. Gantt charts er i dag, i forskellige afskygninger, en integreret del af mange projektlederes værktøjskasse, hvilket en enkelt internet-søgning på ordet 'Gantt planing' kan overbevise én om. Moderne projektledelse generelt Som modpol til 'samlebåndsarbejdet' (taylorismen), er kendetegnene for det projektorienterede arbejde, at det er tidsbegrænset, indeholder et element af noget uprøvet, udføres af en projektgruppe, der sammensættes til lejligheden og gruppe sammensætningen går ofte på tværs af fagdiscipliner (Biering-Sørensen, 2004, s. 17). Projektledelsen som fagdisciplin placeres altså i brændpunktet mellem en række forskellige discipliner, hvor af de mest væsentlige er kommunikation og ledelse samt naturligvis den faglige viden indenfor det domæne, man udvikler i, eksempelvis softwareudvikling. Desuden er det kendetegnene, at hvert projekt i større eller mindre grad afføder nye unikke produkter, services eller resultater (Biering-Sørensen, 2004, s. 17). 12 S ide

13 De plandrevne projekter Som et af de første erhverv begyndte man i militære sammenhænge i midt 1950'erne at udvikle værktøjer til håndtering specifikt af projektledelse. Før 1950'erne var projekter, her i blandt de militære projekter, almindeligvis ledet ved hjælp af værktøjer som blandt andet de tidligere omtalte Gantt charts, men i 1957 udviklede den amerikanske flåde værktøjet Program Evaluation and Review Technique (PERT) til at understøtte udviklingen af et militært missil program 2. At PERT var mere end en militær projektledelse og nemt kunne lade sig benytte i civile sammenhænge skinner igennem, hvis man ser på de krav, der opstilles til koordineringen af militære handlinger (Biering-Sørensen, 2004, s. 32): gennemføre en - ofte svær - opgave som ikke er prøvet før mange menneskers koordinerede indsats er nødvendig planlægning, koordinering og kommunikation er essentiel handlekraft når virkeligheden viser sig at være anderledes end planerne, er lige så essentiel ord som strategisk, taktisk og operationel er anvendelige til at anskue processen fra forskellige detaljeringsniveauer Formålet med PERT var at skabe et værktøj, der kunne kontrollere tiden og forudse sandsynligheden for succes i projektet. En af grundstenene i PERT er derfor estimering. Kort sagt funderer man projektplanlægningen ud fra matematiske estimater af de enkelte aktiviteter. Et eksempel på et sådant estimat kunne lyde: Forventet tid = (optimistisk + 4 x sandsynligt + pessimistisk) / 6 Denne, og mange andre kalkulerede værdier, indsættes herefter i et diagram sammen med bl.a. milesten, hvorved der skabes et overblik over projektets omfang. Denne proces har mange fællestræk med Gantt chartet, men PERT er langt mere omfattende og dækker i modsætning til Gantt chartet hele projektprocessen ved at udstikke redskaber til estimering og planlægning. Projekt et, der er styret i PERT, er altså på sin vis planlagt på forhånd eller det, vi i daglig tale betegner plandrevene forløb. 2 Vi er velvidende om at PERT ikke var ene om at revolutionere styringen af projekter på denne tid. At vi udelukkende vælger at fokusere på PERT skyldes at projektet meget tydeligt afspejler mange af tidens træk. 13 S ide

14 I denne kategori af udviklingsmetoder findes også vandfaldsmodellen. Vandfaldsmodellen adskiller sig dog fra PERT ved ikke at have måletekniker, for eksempelvis estimeringen, integreret i sine rammeværker. Kendetegnet for vandfaldsmodellen er, at man opdeler projektet i faser, hvor hver enkelt fase færdiggøres, før man springer til den næste Siden Win Royce introducerede denne vandfaldsmodel i 70 erne, er den hovedsageligt blevet brugt indenfor softwarebranchen, hvor den også oprindeligt var tiltænkt. Modellen, som Kravspecifikation ses herover, er en meget enkel udgave af Design vandfaldsmodellen. Der er større diskussion Implementation om, hvorvidt man kan være iterativ inden for rammernee af modellen, bl.a. ved hjælp af det, der kaldes feedback-loopsmodellen i sin nøgne form uden at Vi vælger dog blot at bringe Afprøvning Vedligeholdelse Figur 4: Klassisk vandfaldsmodel gå ind i diskussionen. Overordnet kan man sige, at de plandrevne metoder deler en tanke om, at hvis blot man går grundigt til værks, så kan man forudsige alle krav og på den måde sikre, at projektet ikke overskrider de forventede omkostninger. I denne optik vil ændringer(eksempelvis nye behov) i projektet anses som fejl i forhold til den plan, projektet er struktureret efter (Jensen & Søvsø Pedersen, 2007, s. 2). Agile udviklingsmetoder Først i begyndelsen af 1980'erne kom det næste væsentlige paradigmeskift. Her grundlagde Takeuchi og Nonaka, hvad der senere skulle blive kendt som agile udviklingsmetoder, med publiceringen af artiklen New New Product Development Game (Takeuchi & Nonaka, 1986). I denne artikel fremlagde de på baggrund af grundige casestudies af en række førendee japanske elektronikvirksomheder nye tendenser og problemstillinger i udviklingen af produkter. Omdrejningspunktet var med fokus på øget konkurrencedygtighed på et marked, hvor behovene konstant ændrede sig, kombineret med, at de produkter der blev udviklet ofte var særdeles videns tunge. 14 Side

15 Takeuchi og Nonakas observationer gik på, hvordan man imødekom de behov, der konstant opstod eller ændrede sig undervejs i et projektforløb. Deres løsning på dette var den agile projektledelse. Konceptet bag agil projektledelse er, at man udvikler i etaper og hele tiden evaluerer processen. På denne måde tilføres løbende værdi til kunden, da kunden gennem releases, løbende kan følge udviklingen. Det ideelle ved denne tilgang er, at man har mulighed for at tilpasse processen på trods af dynamiske og komplekse omgivelser; Man er adræt, hvoraf navnet agil kommer. (Schwaber, 2004, s. XII). På denne måde gøres der i udviklingsfasen både plads til innovation og læring. (Schwaber, 2004, s. XVIII) I forhold til de plandrevne metoder, eller phased program planning som de benævnes i artiklen, adskiller agil udvikling sig fra disse ved, ikke at have en ligeså detaljeret og forudbestemt proces, til gengæld tilbyder de muligheden for at ændre processen løbende, samtidig med det endelig mål er for øje (Schwaber, 2004, s. XVIII). I nogle sammenhænge betegnes denne modsætning som en decideret krig imellem to systemer, der ikke kan leve side om side. De sidste par år er disse fronter imidlertid blødt væsentligt op, da en række forskningsresultater har vist, hvorledes de to forskellige paradigmer har deres berettigelse i forskellige kontekster (Kasse, 2008). I projekter hvor man har kendskab til det domæne, man skal udføre sit projekt 3 indenfor, det vil sige at man kender både behov og begrænsninger, vil en plandreven projektmetode ofte være succesfuld, da man på forhånd kan opstille succeskriterier form af krav, tidsramme og pris. Er der derimod tale om et overvejende ukendt domæne, vil en agil udviklingsmetode være mest succesfuld, hvor succeskriterier i samme grad er opstillet på forhånd (Biering-Sørensen, 2004, s. 50). Det oplagte eksempel på en branche, hvor sidstnævnte gør sig gældende, er software industrien. I udviklingen af software er det ofte meget svært at fastlægge alle krav på forhånd (Biering- Sørensen, 2004, s. 41), hvorfor den agile tankegang blevet adopteret bredt i softwarebranchen inden for det sidste år. Men idéen om agilitet i projekter er også blevet adopteret i andre brancher med uklare domæner, eksempelvis arkitektbranchen, hvor indenfor dette projektets samarbejdspartner befinder sig. 3 Eksempel på dette kan være byggebranchen hvor man ofte arbejder i meget velkendte domæner, man kan i den sammenhæng snakke om at branchen er moden[peter Læssøe; Deltakonference 13/11/08], idet den kan levere produktet til tiden. Dette er dog sagt med forbehold for eksempelvis opbygningen af den nye DR by. 15 S ide

16 En anden forskel på de to udviklingsmodeller er graden af dokumentation. I sin ekstreme form, fordrer den agile udvikling slet ingen dokumentation i modsætning til den plandrevne ofte massive dokumentation. Igen er disse forskelle blødt væsentligt op de sidste år, så f.eks. Tim Kasse i stedet taler om "kunsten at lægge sig i the sweet spot mellem ekstremerne" (Kasse, 2008) 4. "Scrum has been used successfully on thousands of projects in hundreds of organizations over the last 10 years. It is based in industrial process control theory, which employs mechanisms such as selforganization and emergence (Schwaber, 2004, s. 1) Som tidligere omtalt blev den agile tankegang hilst velkommen i mange software kredse som en modpol til den plandrevne projektledelse. Det var imidlertid først i 2001, at den agile tankegang blev formaliseret, i gennem, at en række ledende skikkelser fra den agile verden udarbejdede det agile manifest: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan Uddrag af det agile manifest, (Beck et al, 2001). Scrum 5 Der findes en række agile udviklingsmetoder, hvoraf Scrum er een. I New New Product Development Game introducerede Takeuchi og Nonaka en metafor for den agile tankegang, hvor de sammenligner denne med det, der foregår på en rugbybane; a holistic or rugby approach where a team tries to go the distance as a unit, passing the ball back and forth may better serve today s competitive requirements. I rugby-sammenhænge er Scrum den situation, hvor holdet samles i en klynge for at bestemme taktik for, hvordan bolden føres videre frem på banen. Navnet er senere er udsprunget af netop dette. 4 Hvor dette sweet spot så reelt befinder sig er normativt og generelt uklart. 5 En dybere forklaring på scrum er at finde i kapitel S ide

17 I nutidens projekter fokuseres ofte på udvikling af videns tunge produkter, hvor der kræves en høj indsigt og fleksibilitet, og hvor det før begyndelsen af projektet kan være svært at kortlægge krav og problemer. Derfor bliver en stor del af selve projektledelsen/udviklingsprocessen defineret igennem brugen af empirisk proceskontrol (Schwaber, 2004, s. 2) i takt med, at en større indsigt definerer nye problemer og behov (Enggård & Agerkvist Petersen, 2007, s. 1). Værktøjer Mennesket har altid benyttet sig af værktøjer i ledelsesmæssige sammenhænge. Om det så har været nedskrivningen af mødereferater eller brugen af symboler (som f.eks. en krone) til at fastsætte det indbyrdes hierarki. En ændret projektledelsesform og dermed ændrede ledelsesprocesser bør medføre en ændring af værktøjer og brugen deraf. Høje borde, der sikrer stående møder, kan være en fordel hvis mødet er fastsat til 15 minutter. Er der imidlertid tale om et 4 timers langt briefingsmøde, ville disse sjældent være passende. Men mennesket er og bliver et vanedyr, og traditioner dør ikke nemt. En hurtig sammenligning af nogle af de mest udbredte elektroniske projektledelsesværktøjer (f.eks. Microsoft Projekt, Microsoft Exchange, JIRA et cetera) viser med alt tydelighed, hvordan de sidste års større fokus på større agilitet i projektledelsen ikke kan sige at have fuldt med udviklingen af værktøjer til håndtering af disse. Det er imidlertid gruppens hypotese, at en lignende tilpasning ikke engang har fundet sted inden for udviklingen af værktøjer specielt målrettet de agile projekter. Det agile manifest fordrer netop fokus på menneskelig interaktion frem for tools, men alligevel kræver de projektledelsesværktøjer, vi kender til, "stadig en længerevarende uddannelse overhovedet at benytte " (bilag A; 40:05). Vi mener således, at det er muligt at skabe et værktøj med respekt for den metode, den arbejder indenfor, samt hvor Scrums fokuseringen på mennesket og interaktionen bibeholdes. Det vil vi med følgende problemformulering og problemstillinger gøre rede for. 17 S ide

18 1.2. Problemformulering Hvordan designes et værktøj der understøtter Scrumprojekter hos en konkret organisation? For at kunne lave et optimalt værktøj/produkt fremstiller vi disse problemstillinger: 1 - Hvordan kortlægges designbehovene til et sådant værk? 2 - Hvilke behov har den konkrete organisation? 3 - Hvordan designes et sådant værktøj? 4 - Hvordan testes designets kvalitet? 5 - Hvordan påvirker værktøjet ledelses processen i Scrum? 1.3. Problemafgrænsning Ovenstående problemanalyse og -formulering efterlader os med en bred række af spørgsmål, som det pga. projektets begrænsede forløb ikke vil være muligt at afdække lige grundigt. I følgende afsnit vil vi derfor forsøge at indskrænke og afgrænse projektets undersøgelsesfelt. Gruppen anerkender, at Scrum for de fleste brugere er et teoretisk udgangspunkt, hvorudfra de udvikler deres egne tilgange. (Hansen, 2008). Det udviklede design tager udgangspunkt i de brugere, som vi har haft kontakt til og vil sandsynligvis kunne benyttes af andre, men det er ikke projektets mål at forsøge at skabe et universelt værktøj. I videnskabelige termer benytter projektet sig af den induktive metode. Induktion som metode anses i de traditionelle videnskabelige kredse til tider som mindre "fin" ift. den rent teoretisk mere sandefærdige deduktion 6 (Olsen, Bitsch, & Pedersen, 2003, s. 153). Udover at det rent praktisk er svært at forestille sig en deduktiv tilgang til problemstillingen, har vi valgt at benytte en induktiv tilgang. Dette skyldes imidlertid vores problems placering i en evig foranderlig verden. I denne verden vil rene lovmæssigheder kun forefindes inden for et afgrænset tid og rum (Olsen, Bitsch, & Pedersen, 2003, s. 140). 6 Dog undtaget den matematiske induktion som ligeledes resulterer i ubestridelige konklusioner. 18 S ide

19 Da vores projekt er et designprojekt, vil der ikke forefindes en dybere analyse af andre projektledelsesmetoder. I stedet accepterer vi Scrum som en god projektledelsesmetode. Det er på samme vis ikke projektets mål at skabe en Scrum version 2.0, men derimod at optimere den allerede stabile Scrumproces ved hjælp af et værktøj. Det er imidlertid vores overbevisning, at vi igennem vores interaktion med brugerne ikke kan undgå at påvirke den allerede eksisterende proces og dermed indirekte skabe nye processer. En oplagt indgangsvinkel til belysning af en metode som Scrum vil ofte være selv at afprøve metoden. Da projektledelse for denne projektgruppe dog er et relativt ukendt område, vurderer vi, at den høstede erfaring, risikerer at forsvinde blandt de mange ekstra problemstillinger, som en ny arbejdsmetode kan medføre. Derudover er det vores umiddelbare overbevisning, at Scrums korte lean agtige møder og agile natur ikke egner sig til vores projekt, hvor forståelsen af projektets problem løbende bliver mere detaljeret, men hvor problemets natur og vilkår ikke ændres markant. Projektet bæres af tre teoretiske hovedsøjler: projektledelse, såvel teoretisk og praktisk forståelse af Scrum som generel projektledelse, behovsanalyser, samt designmetoder. Netop på grund af det relativt brede teoretiske fundament, vores projekt har, vil væsentlige teoretiske områder kun blive behandlet overfladisk. Af de tre hovedsøjler vil projektledelse således hovedsagelig fungere som et fundament for vores efterfølgende design, hvorfor vi har valgt ikke at lade dette aspekt gennemgå en større kritisk teoretisk analyse. Ligeledes af tidshensyn har vi valgt at lade vores designfase bygge næsten udelukkende på empirisk indsamlet data frem for et decideret litteraturstudie, samt gruppens medlemmers tidligere "design" erfaring. Dette er valgt da gruppen internt allerede har en relativ stor viden over forskellige design metoder, og for ikke at flytte projektets scope væk fra processen. Indsamling af empiri gennem interessentanalyse og behovsanalyser er også genstand for afgrænsning. Af de interessenter, der findes for projektets produkt, anses Scrum teamets oplevelser og holdninger som de mest interessante, hvorfor hovedfokus vil ligge på dem både som samlet gruppe og som individer. På samme tid afgrænser vi os fuldstændigt fra problemstillingerne forbundet med større organisationer, hvor Scrum benyttes i flere afdelinger, der indbyrdes arbejder sammen. I stedet ønsker vi kun at se på specieltilfældet, hvor en enkelt gruppe benytter Scrum i den daglige ledelse. 19 S ide

20 Del 2 Behovsindsamling 2. Scrum teori Scrum er en iterativ og ofte inkrementel udviklingsmetode opstået og oftest benyttet inden for software udvikling. Scrum har sit udspring i de tidligere omtalte agile udvilkingsmetoder. Vi vil som nævnt i problemafgrænsningen ikke gå ind i en længere diskussion af Scrums styrker og svagheder men blot nedenfor gennemgå de ting, som kendetegner Scrum. Scrum består af 3 aspekter - regler, roller, og artefakter, som sammensat giver en, for en udefrakommende, meget låst proces. Vi vil i det følgende først skildre de overordnede regler samt karakteristikker for et Scrumforløb, før vi dykker ned i roller og artefakter. Følgende afsnit er skrevet på baggrund af bogen Agile Project Management with Scrum, og har derfor direkte reference hertil. (Schwaber, Agile Project Management with Scrum, 2004) 2.1 Regler og forløb Scrum holdes langt hen ad vejen sammen ved hjælp af regler. Regler, som det er Scrummasterens opgave at sikre, at alle i gruppen overholder. I den traditionelle udgave af Scrum, der har sin oprindelse i USA, diskuteres reglerne og procedurerne ikke ud fra argumenter som "If the rules are disputed, time is lost while everyone waits for a resolution" (Schwaber, Agile Project Management with Scrum, 2004, s. 133). Sådanne holdninger har naturligvis haft svært ved at vinde indpas i den mindre hierarkiske og autoritære skandinaviske struktur, hvorfor alle de projekter, vi har haft kontakt med i dette projekt, har valgt at tilpasse reglerne til deres personlige behov (se desuden afsnittet To Scrum or not to Scrum, Kapitel 4). Af den grund vi vil i det følgende ikke forsøge at forklare Scrums flere sider lange "regelsæt" som figurer i nogle bøger, men blot gennemgå de regler som vi igennem vores undersøgelse vurderer som er mest centrale. Desuden vil vi, da samtlige "regler" er tilknyttet specielle fase i Scrumforløbet, samtidig gennemgå et standard forløb. For at denne gennemgang giver mening vil vi her først gennemgå roller i Scrum. 20 S ide

21 2.2 Roller Et væsentligt aspekt i Scrum er en meget stringent arbejds- og ansvarsopdeling. Dette sikres hovedsagelig igennem opdelingen i 3 foruddefinerede roller: Scrummaster Scrum masteren kan overordnet betegnes som gruppens facilitator. I Scrum analogier benyttes ofte beskrivelsen af denne rolle som fårehyrden der holder styr på flokken (teamet), sikre at de har hvad de skal bruge i deres arbejde og beskytter teamet for udefra kommende fare. Produktejer Produkt ejeren repræsentere "kundens" interesse i projektet og ses i Scrum som netop en af de udefra kommende fare fordi han kan komme til at lede teamet på vildspor med nye projekter og idéer. Produkt ejeren er derfor forment adgang til teamet under sprintene (teamet kan selvfølgelig altid kontakte produkt ejeren hvis de har brug for dette). Produkt ejerens ansvar i processen er at skrive arbejdspakker (user stories), og placere dem prioriteret i produkt backloggen. Sammen med projektteamet repræsenterer Scrummaster og produktejer, gruppen af folk der er forpligtet til projektet. Disse betegnes normalt samlet 'the pigs' ud fra velkendte historie om hønen og grisen (se nedenfor). Chickens Den anden gruppe 'the chickens' omfatter projektets interessenter f.eks. brugere, kunder, og lovgivere. Disse mennesker er ikke del af det egentlig Scrum proces og har f.eks. ikke lov til at byde ind under de daglige Scrum møder uden at de bliver spurgt. Deres forbindelse til Scrumteamet går derfor igennem produkt ejeren eller fra Scrumteamet til dem. 21 S ide

22 2.3 Forløb Sprint planlægningsmøde: Mødet forløber i løbet af én dag, er den første fase i Scrum og forløber i to afdelinger. Til første del af mødet deltager normalt Scrummaster, produktejeren og projektteamet (disse roller forklares længere nede i afsnittet). Desuden kan der til første del af forløbet inviteres personer, som måtte lægge inde med, for planlægningen væsentlig viden. Disse forlader dog rummet, før arbejdet med at sammensætte den kommende sprint begynder. På mødet vælger projektteamet de elementer fra den, af produkt ejeren, prioriterede produkt backlog, som skal kan udføres i den kommendee sprint. Figur 5: Oversigt over scrum forløb I anden del af mødet træder produktejeren ind i rollen som kylling og står således til rådighed for teamet, men må ikke "blande sig" i planlægningen. I denne del er det projektteamets opgave at omforme de, fra produktbackloggen, valgte elementer til en mere detaljeret sprint backlog over den kommende sprint. Opgaverne nedbrydes i mindre opgaver, og estimeringerne gøres mere detaljerede. 22 Side

23 Sprinten og det daglige Scrummøde En sprint forløber almindeligvis over 2-4 uger. I løbet af denne periode mødes teamet én gang dagligt til et 15 min. langt stående møde - ofte kaldet 'den daglige Scrum'. Mødet starter altid samtidigt og så vidt mulig samme sted, og det forventes, at alle teamets deltagere er til stede. Under mødet er det kun "the pigs" 7 som taler. Mødet forløber med at projektteamets medlemmer på skift besvarer følgende tre spørgsmål: 1. Hvad har du lavet siden sidste møde? 2. Hvad har du planlagt at arbejde med i dag? 3. Har du nogen problemer, som forhindrer dig i at nå disse mål? Sprint aflevering og retrospektiv Den sidste dag i en sprint præsenteres de udviklede produkter, og der kigges tilbage på procesforløbet. I første del af mødet præsenteres de fuldstændig færdige features (done done) over 4 timer. Til denne fremlæggelse har alle projektets interessenter adgang. I anden del af mødet kigger teamet tilbage på processen ved at besvare følgende to spørgsmål: 1. Hvad gik godt i sprinten? 2. Hvad kan forbedres til næste sprint? Denne del af mødet tager ligeledes ca. fier timer og sikrer en kontinuerlig proces forbedring i teamet 2.4 Artefakter I den litterær beskrivelse af Scrum benyttes tre væsentlige artefakter produkt backlog, sprint backlog og burn down chart. Vi skal senere se at det er vores erfaring at der i den praktiske brug af Scrum ofte benyttes flere og andre artefakter. Disse værktøjer er i høj grad med til at fastholde projektets "scrumstruktur" og er på den måde, mere end blot et støttende værktøj som f.eks. kalendere, værdiskemaer etc. 7 the pigs er en scrum term og dækker over de personer som er forpligtet til projektet. 23 S ide

24 Produktbacklog Produktbackloggen består i en liste af user-stories 8, som tilsammen danner kravene for det endelige design. Produkt backloggen er productejerens ansvar, men dokumentet er åbent og tilgængeligt for alle projektdeltagerne. Alle user-stories i produktbackloggen er blevet estimeret ift. den værdi, som user-storyen tilføjer designet (almindeligvis estimeret af produktejeren) samt de udviklingsmæssige ressourcer, som elementet kræver for at blive realiseret (almindeligvis estimeret af projektteamet). Sprintbacklog Sprintbackloggen indeholder detaljerede beskrivelser af, hvordan teamet vil implementere kravene for den nuværende sprint. Alle sprintens opgaver bliver nedbrudt til mindre opgaver af 4-16 timers forløb. Efterhånden som sprinten forløber nedskrives de tilbageværende timer. Opgaver på sprintbackloggen tildeles ikke, men vælges i stedet selv af projektteamets medlemmer. Sprintbackloggen tilhører projekt teamet, og det er kun projektteamtet, der kan ændre i denne. Burn down chart Er et offentligt tilgængeligt diagram over sprintens resterende arbejde. Denne opdateres hver dag og giver dermed en simpel oversigt over fremgangen i den nuværende sprint. Til tider benyttes også burn down chart over den samlede resterende mængde arbejde i projektet. 3. Metodiske overvejelser af dataindsamling 3.1. Interview som metode Igennem møder og korte samtaler med scrumbrugere står det klart for os, at der eksisterer en væsentlig afstand imellem den i litteraturen teoretisk beskrevne Scrum og den praktiske brug af metoden. Da et meget væsentligt aspekt af en designproces netop er at opfylde en brugers behov (Pries-Heje (red.), 2008A, 1. forelæsning, sl. 5) finder vi det nødvendigt at indsamle empirisk data som overordnet besvarer følgende spørgsmål: Hvordan forløber et scrumprojekt for interviewpersonerne? Hvilke værktøjer benyttes? 8 En user story er et formuleret krav til endelige produkt, f.eks. man skal kunne oprette en ny opgave. 24 S ide

25 Valg af kvalitative interviews Til at besvare disse spørgsmål har vi valgt at benytte et åbent semi-struktureret ekspertinterview. Det valg tager udgangspunkt i flere aspekter. Vigtigst er det, at det ikke er projektets mål at designe et universelt værktøj til scrumudvikling, hvilket et valg af en mere kvantitativ dataindsamlingsmetode ville ligge op til. Se eventuelt problemafgrænsningen i kapitel 1 hvor vi beskriver dette valg med udgangspunkt i den induktive metode. Samtidig er ekspertinterviewet særligt velegnet til hurtigt at danne sig en forståelse af et nyt og ukendt domæne blandt andet pga. dets fleksible natur, der giver mulighed for at bore dybere ned i eventuelle interessante svar fra interviewpersonen (Robson, 2002, s. 229). Metodisk valg Hvorfor vi har valgt at placere os imellem det åbne og det semikonstruerede interview? Figur 6: Illustration af interview struktur Det åbne interview giver mulighed for at interviewpersonen selv deltager aktivt i interviewet (Pries-Heje (red.), 2008A) Indsamling af data, slide 8]. For eksempel kan det være en mulighed at spørge om vedkommende, vil demonstrere hvordan de udfører deres arbejde. I vores tilfælde, hvordan en projektleder anvender Scrum. Vi vil kunne drage stor udbytte af denne åbne interviewform, da vi vil spare en masse tid i forhold til selv at afprøve de allerede eksisterende værktøjer til Scrum. Ved et åbent interview vil vi kunne bruge projektlederens erfaring fra anvendelsen af eksisterende værktøjer til Scrum (der er en lang række eksempler på dette, et kunne være; (Bilag A; 43.00). Tidsmæssigt er denne interviewform relativt krævende. Et åbent interview kræver som udgangspunkt en til fire timer at udføre, hvor udarbejdelsen af referat cirka er dobbelt så tidskrævende. Vælger vi dog at renskrive vores interview kan det tage op til ti gange så lang tid som selve interviewet. (Pries-Heje (red.), 2008A) Indsamling af data, slide 10] Dette vælger vi ikke at gøre, da det for os er mere relevant at fremhæve de vigtige pointer i interviewet. I stedet for transskriberet udgave af interviewene, vedlægges begge interviews som lydfiler på en cd. 25 S ide

26 Huskeregler til interviews Det semi-strukturede interview fungerer godt til at interviewe flere personer om det samme emne. (Pries-Heje (red.), 2008A), Indsamling af data, slide 6] Derfor er den semi-strukturerede interviewform yderst anvendelig for os, da vi vil interviewe flere projektledere om deres anvendelse af Scrum. Dette gør vi for at få et bredere perspektiv på, hvordan vi får svar på vores tidligere stillede spørgsmål vedrørende vores motivation for brug af interviews: Hvordan forløber et Scrumprojekt for interviewpersonerne? Hvilke værktøjer benyttes? For at opfylde rammerne for et semi-struktureret interview, kræver det at man opstiller en tjekliste eller en spørgeramme for at sikre, at man får spurgt ind til det samme emne. (Pries-Heje (red.), 2008A) Indsamling af data, slide 13] Vi vælger dog til en vis grad at finjustere, individualisere og fokusere hvert interview i takt med at vi oparbejder en viden om emnet. Dermed får vi en klarer og klarer ide om hvad vi ønsker svar på. Dette kan ses som en iterativ proces, som er illustreret i vores procesmanual i den 3.fase der hedder Behovsindsamling Motivation for valg af interviewpersoner Motivation for valg af Joos Jerne Metoden Scrum ses ofte anvendt inden for softwareudvikling. Det er relativt tilgængeligt, at finde information om hvordan softwareudviklere bruger Scrum, da det inden for denne branche, har været populært i en årrække. Vi finder det dog enormt interessant, at se denne metode anvendt inden for andre brancher hvor Scrums potentiale måske endnu ikke er fuldt udnyttet. Det har været interessant for os at vælge en virksomhed, der ikke opererer i softwarebranchen. Dette da vores fornemmelse er, at Scrum allerede er en udbredt ledelsesmetode i softwarebranche, og der derfor allerede findes adskillige værktøjer der understøtter til Scrum (dog vil i afsnittet Foranalyse begrunde, at vi ikke finder disse programmer særligt brugervenlige). I gruppen har vi kontakt til Joos, der er arkitekt hos arkitektfirmaet Arkitema. Vi vidste på forhånd, at han tidligere har arbejdet med projekter, hvor de har brugt Scrum og vi blev derfor interesserede i at vide, hvordan de greb metoden an. Vi så også her en mulighed for, at starte et samarbejde med Arkitema med henblik på, senere i vores designproces, at afprøve vores kommende værktøj til Scrum, i deres arbejde med anvendelse af Scrum. 26 S ide

27 Motivation for valg af Morten Stahlschmidt På foranledning af Joos Jerne fik vi kontakt til Morten Stahlschmidt, som også er arkitekt hos Arkitema. Det interessante ved Morten er, at han på det aktuelle tidspunkt anvender Scrum til at lede et større projekt. Ved at kontakte Morten har vi fået afdækket to væsentlige aspekter i vores behovsanalyse. Dels fik vi mulighed for at bruge de erfaringer og informationer, som vi indhentede da vi interviewede Joos. Derved kunne vi tilrettelægge et interview, hvor vi var relativt fokuserede på, hvad vi ville have svar på. Herved har vi bevæget os mere i retning af et struktureret interview. Under selve udførelsen af interviewet bibeholdte vi dog strukturen for det semi-strukturede interview, ved at lade Morten som interviewperson, snakke forholdsvist frit inden for de forberedte spørgsmål. Det andet og meget væsentlige aspekt som Morten bidrog med, var en observation af et Scrummøde. Gennem Morten fik vi mulighed for at være fluen på væggen under et af de daglige Scrummøder i hans projektteam. Da det daglige Scrummøde er en meget væsentlig proces i Scrummetoden samlet set, fik vi her en unik mulighed for gøre egne erfaringer, ufiltreret af Mortens livsverden (fænomenologi) Foranalyse En problematik der rejste sig allerede tidligt i forløbet, var gennemførelsen af en Ex Post (Pries- Heje et al, 2008B) evaluering af vores udviklede design i en "acceptabel" naturlig kontekst. At sikre naturlige omgivelser var essentielt af to grunde: hovedsageligt var vi nervøse for at belaste vores projekts, essentielle samarbejdspartnere mere end højest nødvendigt, ved at lave om på deres allerede etablerede arbejdsrytmer. For at danne os et reelt indtryk af udbyttet af vores værktøj, var det nødvendigt at resten af omgivelserne, så vidt mulig, forblev naturlige. Dertil kom, at en test udelukkende af vores nye værktøj, uden den omkringliggende naturlige kontekst, ikke ville give os et tilfredsstillende overblik over succesen af vores gennemførte designforløb. Til nærmere at belyse dette problem besluttede vi, at gennemføre en foranalyse af hvilket funktionaliteter vores design skulle afspejle, og hvilke tekniske løsninger der var mulige. Vi benyttede desuden rammeværket Strategies for design science research evaluation (SDSRE) af Pries-Heje et al. (Pries-Heje et al, 2008B) som guide for udformningen af analysen, ved at besvare følgende 3 spørgsmål: 1. Hvad evalueres artefaktet og/eller designmetoden? Evalueringen bør omhandle både designmetode og artefakt da disse i vores projekt er kausalt forbundet. Kausalitetsbegrebet skal i denne sammenhæng forstås på den måde, at 27 S ide

28 designmetoden er årsagen, og selve artefaktet er virkningen heraf. Når for eksempel kravene til artefaktets funktionalitet og den dertil følgende affordance (Holden, Lidwell, & Nutler, 2003, s. 20) overstiger vores tidsramme, må vores tilgang naturligvis også ændre sig. En konsekvens af dette har været, at vi ikke ønsker at lave et universelt fungerende værktøj, men et værktøj der som udgangspunkt kun fokuserer på ét firmas specifikke krav. 2. Hvordan evalueres naturligt eller kunstigt, igennem hvilke processer og med hvilke kriterier? Evalueringen bør finde sted i kunstige omgivelser for at undgå yderligere belastning på vores samarbejdspartnere. Desuden er det væsentlig at undersøgelsen gennemføres hurtigt og fleksibelt, hvilket ofte er et kendetegn i evaluering der er gennemført i mere kunstige omgivelser [Design og metode; s241, nederst]. Hurtigt, fordi andre dele i projektet afventede resultatet, og fleksibelt, fordi domænet for undersøgelsen var relativt ukendt for os. Som proces valgte vi at benytte en kriteriebaseret analyse. Dette ud fra vores iagttagelser af, at vi allerede havde nogle meget klare kriterier for hvilke krav systemet skulle opfylde, og fordi det er en relativ hurtig tilgang. Følgende tre kriterier blev opstillet ud fra vores allerede gennemførte læsning og interviews (ikke prioriteret rækkefølge): - Adgang til videre udvikling: Tilgængelighed og kvaliteten af systemets kode og dokumentation. - Let tilgængelig: Det var vigtigt, at vi skabte et værktøj, som relativt let kunne adopteres af vores samarbejdspartnere. Fra begge vores interviews kunne vi spore en skepsis over for komplicerede it-systemer der ofte hæver kompleksiteten (bilag A). En kompleksitet der ikke er plads til i et kort Scrummøde. Afledt af dette blev intuition i brugerfladen hurtigt et nøgleord for vores design. Blandt andet på baggrund af Joos Jernes udtalelse, men også generelle iagttagelser, gjorde det vigtigt for os at bibeholde så meget af deres vante brug af Scrum som muligt. I denne sammenhæng besluttede vi at det var væsentligt at designet, i så høj grad som muligt, bibeholdte den terminologi og de visuelle udtryk, der blev brugt i den eksisterende projektledelse. Herved var målet at vores samarbejdspartner kunne adoptere og bruge designet, uden at skabe store ændringer i den daglige ledelse. 28 S ide

29 Uden at udføre en større usability undersøgelse, fastsatte vi indikatorerne på at dette kriterium var opfyldt til: At produktet allerede er kendt/benyttes af brugeren. At produktet kun understøtter få funktionaliteter (Norman, The Design of Everyday Things, 2008B, s. 204) At produktets følger de kulturelle konventioner for projektledelsesværktøjer (Norman, Affordance, Conventions, and Design, 2008A, s. 186). - Andre brugeres erfaring: Scrummasters erfaringer hentet fra for eksempel online fora, eller interviews. 3. Hvornår skal der evalueres? Evalueringen bør finde sted før designprocessens start (ex ante), da vi vurderer at resultatet er meget afgørende for vores kommende designproces. Så afgørende at en afklaring før videre arbejde er en nødvendighed. I besvarelsen af de tre spørgsmål opstiller vi et deskriptivt rammeværk for vores evaluering (Pries-Heje et al, 2008B, s. 244). Besvarelsen på de tre spørgsmål kan derfor sammenfattes i den nedenstående figur, som er lavet med udgangspunkt i SDSRE: (Pries-Heje et al, 2008B, s. 244): Figur 7:Evalueringsmodel hentet fra SDSRE Det fremgår af figuren, at evalueringen foregår ex ante, og omhandler selve designproduktet. Ligeledes ses det på figuren, at evalueringen foregår i et kunstigt miljø (artificial). Det 29 S ide

30 væsentligste ved denne figur er også at bemærke betegnelserne C og P. P beskriver karakteristikken for evalueringsprocessen (Process) og C indikerer evalueringskriterierne (Criteria) (Pries-Heje et al, 2008B, s. 245) Observation som metode For at opnå den mest virkelighedsnære forståelse af anvendelsen af Scrum i dens naturlige kontekst, har vi ud over at bruge interview til empirisk indsamling af data valgt at foretage observationer. Observation er en klassisk empirisk metode til indsamling af information. Denne er specielt udbredt blandt antropologer, men bliver også flittigt anvendt inden for andre fagområder. Formelle og uformelle observationer Der er to overordnede tilgange til observationer; uformel (informal)- og formel observation (formal observation). Uformel observation er, som navnet antyder, meget lidt struktureret. Man kan som observatør selv vælge, hvilke handlinger man vil ligge vægt på, samt hvordan den fundne viden dokumenteres. Normalt vil det være ved at tage noter, og ved at udspørge de observerede under selve observationen. Den formelle observation er struktureret og der er et klart defineret mål for, hvordan og hvilken information, der skal indhentes. Det på forhånd fastlage fokus gør at den information der opnås, har stor troværdighed og er meget detaljeret. Til gengæld ville vi ved meget strukturerede observationer let miste konteksten og kompleksiteten, ved udelukkende at have fokus på enkelt dele (Robson, 2002, s. 313). Vi har valgt at bruge den uformelle tilgang til observation. Dette valg har vi truffet fordi vores observationer vil være meget korte (15 minutters møder), og fordi vi igennem disse søger et overblik over og en mere praktisk tilgang til Scrum. Observationsroller Ved observation er det vigtigt at vi træffer et valg angående, hvilken rolle vi påtager os til observationen. Et parameter der her er centralt, er observatørens grad af interferens med det observerede emne. Parameteret befinder sig almindeligvis inden for de to ekstremer, den fuldt ud deltagende observatør eller fluen på væggen. Inden for den deltagende observatør er der 30 S ide

31 forskellige grader af deltagelse, lige fra fuldstændig deltagende til den udelukkende observerende (Robson, 2002, s. 313). Rollen "fluen på vægen" adskiller sig fra de deltagende roller ved at gøre sig til en del af den naturlige kontekst, for dermed ikke umiddelbart at fremstå som en observatør. Som eksempel kan fluen på væggen stå i en skolegård og observere uden at de observerede har kendskab til dette. Vi har i vores tilgang valgt at benytte os af den mindst deltagende model: Deltager som observatør. Denne rolle indebærer, at alle til stede ved observationen er bevidst om at de bliver observeret. Derimod interagerer observatøren ikke og bliver aldrig en del af gruppen, som man forsøger ved den fuldt ud deltagende rolle (Robson, 2002, s. 319). Vores begrundelse for dette valg er, at vi ikke ønsker at blande os i den proces vi iagttager. Samtidig har vi ikke valgt rollen som den helt usynlige flue på væg, da det ville kræve meget tid og energi helt at skjule vores tilstedeværelse, og da vi ikke mener, at vores tilstedeværelse vil påvirke mødets forløb væsentligt. Dokumentation Der er forskellige måder at dokumentere den viden vi opnår ved observation på. Til observationer, der strækker sig over lang tid, hvor enkelte detaljer er centrale, bliver avancerede noteringssystemer eller værktøjer ofte brugt. Er det imidlertid de overordnede træk der søges, kan sådan dokumentation i bedste fald være spild af tid, mens det i værste fald kan forstyrrer overblikket så meget at kvaliteten forringes. Et andet meget vigtigt aspekt af dokumentationen er tiden fra oplevelse til dokumentation. Det altafgørende er at huske at få vores noter og oplevelser dokumenteret så hurtigt som muligt; helst inden for 24 timer. Samtidig siger en tommelfingerregel, at der aldrig må påbegyndes en ny observation inden de forrige noter er blevet gennemarbejdet, da de to oplevelser ellers lynhurtigt sammenblandes. I forbindelse med at anvende dokumentationen i rapporten har vi gjort nogle etiske overvejelser i forhold til hvordan vi omtaler de implicerede personer. Vi er nået frem til, at det mest korrekte er at lade personerne fremstå anonyme, da det er den overordnede proces, der er relevant for vores observation og ikke den enkelte person. Helt konkret omtaler vi deres derfor personer med bogstaver i analysen. Potentielle fejlkilder Observation kan ikke betegnes som problemfri. Det er en tidskrævende proces, ikke bare selve observationen, men også bearbejdelsen af den indsamlede viden. Der kan forekomme problemer med troværdighed i en observation. Problemer kan opstå, hvis de observerede er så 31 S ide

32 opmærksomme på at de bliver observeret, at de indirekte agerer anderledes end de ville gøre, hvis de ikke blev observeret (Robson, 2002). Det er derfor et grundlæggende vilkår for observationen, at man som observatør aldrig kan vide hvordan ens tilstedeværelse påvirker forløbet. Disse problemer kan imidlertid ofte relativt nemt afhjælpes. For eksempel kan meget strukturerede observationer foretages i et kunstigt fremstillet miljø. Hvor en synlig observatør tænkeligt kan have en negativ indvirkning på observationen, kan et étvejs spejl være til stor hjælp. Den observerede glemmer herved hurtigere at denne bliver observeret og hjælper hermed til at opnå så stor lighed med virkeligheden som muligt. Motivation for udvælgelse af observationer Vi vil foretage en række observationer. Først vil vi foretage en observation af et 15 minutters daily Scrummøde, hos Arkitema. Dette bliver gjort for, at vi kan få en empirisk viden om hvordan Scrum hos Arkitema bliver brugt i praksis. Dette har yderst relevans da vi senere i forløbet vil benytte Arkitema som bruger. Derfor vil vi i under denne observation være meget opmærksomme på hvilke problemer og hvilke behov som forekommer til deres daily Scrum. Da det daglige scrummøde er en meget væsentlig proces i scrummetoden samlet set, fik vi her en unik mulighed for gøre egne erfaringer, ufiltreret af Morten Stahlschmidts egen forståelse af processen. For at skabe et bredere kendskab til Scrum, og for at opleve en anden måde at benytte Scrum på, vil vi også observere et dagligt scrummøde hos Danske Spil. Danske Spil er et andet firma end Arkitema og kan dermed fungere som inspiration til vores arbejde. Derudover har vi på baggrund af vores deltagelse på et seminar hos Danske Spil erfaret, at virksomheden, og i særdeleshed oplægsholder og projektleder Karin Hansen, har en betydelig større og dybere forståelse af Scrum som metode. Dette gør at deres proces eventuelt kan fungere som et forbillede for processen hos Arkitema. 32 S ide

33 4. Behovsanalyse 4.1. Interview med Joos Jerne Om Arkitema og Joos Jerne Joos Jerne arbejder til dagligt som arkitekt og projektleder i Arkitema, Danmarks største arkitektfirma, som en af 200+ ansatte fordelt på afdelinger i København og Århus. Ifølge Joos er firmaets væsentligste kendetegn deres teambaserede arbejdsformer der tager sit udgangspunkt i devisen om at "du aldrig bliver bedre end din bedstes mand begrænsninger" (Bilag A; 05:15) 9. Alt arbejde i firmaet gøres i dynamiske teams, som varieres i størrelse i løbet af et projekt fra 1 til 12 personer. Joos er hovedsagelig autodidakt projektleder, men tog sidste år projektleder uddannelsen 'Hopla' der er intern uddannelse som Arkitema tilbyder sine ansatte og hvorfra hans erfaring med Scrum også stammer. Desuden har han noget erfaring med projektledelse fra sin oprindelige uddannelse som konstruktør. Arkitekten og Scrum At Scrum benyttes inden for arkitekt faget kan for den uindviede synes underligt. Mange arkitekt projekter spænder i dag ikke kun over de klassiske arkitektoniske discipliner, i lige så høj grad indebærer et krav om at kunne lede et konstant omskifteligt projekt med mange forskellige interessenter (16:55): "der kommer hele tiden et eller andet, enten nogen man ikke kunne have forudset eller også nogen ting som ikke [...] har været løst ordentligt" (14:28). Efterfølgende tilføjer han dog indrømmende at der ikke kun er tale om udefrakommende problemer eller sjusk, men at de selv, pga. tidspres, ikke altid overholder deres tidsplaner, og derfor ofte må vende tilbage og detaljere et svar. Uforudsete problemer og tidspres ledende til sjusk - 2 ting som er kendte symptomer for dårlig plandrevene udvikling. (Biering-Sørensen, 2004, s. 41). Og ligesom i software verdenen syntes løsning at være den samme, hvilket står klart da han senere opsummere kravene om omstillingsparathed som et udpræget krav til arkitekten: "...Jeg tror det er lidt kendetegnet ved denne branche vi skal hele tiden være super fleksible og meget omstillingsparate" (21:30). Der er altså flere gode argumenter for at Arkitema har valgt at tage Scrum til sig. 9 I det følgende afsnit henviser alle min. angivelser til interviewet med Joos Jerne (Bilag A og lydfil 1). 33 S ide

34 Joos Jerne's brug af Scrum Joos har siden hans tilegnelse af Scrum benyttet det i genopførelse af Bellahøj badet som er et projekt, der strækker sig fra 2006 til juni Der har kun været benyttet Scrum i de dele af projektet, hvor der har været flest personer tilknyttet projektet (generelt ca. 5-7 arkitekter). I projektet er Arkitema totalrådgiver, hvilket medfører øgede krav til projektlederen pga. de mange projektinteressenter (bl.a. brugere, driftsleder, produkt ejere og forskellige entreprenører). Desuden deltager en række forskellige interne teams fra Arkitema - f.eks. interiør designerer og landskabsarkitekter. På mange måder afviger Jooses brug af Scrum umiddelbart fra de teoretiske beskrivelser af Scrum. Specielt tydeligt er det at de ikke har kendskab til flere af de traditionelle Scrum begreber (som f.eks. burn down chart, userstories etc.), men kigger man nøje efter er lighedstrækkende imidlertid større end man umiddelbart bemærker. I det følgende vil vi benytte hans egne begreber men angiver i parenteser de punkter hvor der er stor lighed imellem deres betegnelser og kendte Scrum betegnelser. Omdrejningspunktet for Joos' benyttelse af Scrum har været den daglige ledelse, konkret igennem et stående Scrum møde hver morgen kl. præcis 10 samt en aktivitets tavle ( simpel sprint backlog) om aktuelle aktiviteter. Efterhånden som den aktuelle projektfases overordnede mål blev nedbrudt og konkretiseret til konkrete 'arbejdspakker' ( userstories) blev disse tilføjet til aktivitetstavlen, og kategoriseret efter status, igangværende/afventende, samt ansvarshavende person. Joos blev et stykke inde i projektet opmærksom på en manglende historik i deres møde struktur. Samtidig oplevede han at projekt teamet ikke altid oplevede et lige stort commitment til de nye opgaver. For at løse dette problem indførte han et mødereferat som gik på omgang blandt projektdeltagere (30:13). Scrum blev i projektet udelukkende benyttet internt i Joos' team. Da byggeherrer og andre udenforstående ikke blev inkluderet, blev Scrum møderne også brugt til videre bringelse af information fra eksterne instanser (32:30). Sammen med den daglige orientering om hinandens status, resulterede dette i at skabe en helhed fornemmelse i teamet, samt et generelt højere informationsniveau (33:00). 34 S ide

35 Design behov Ud fra ovenstående diskussion samt naturligvis interviewet opsumerer vi nedenfor en liste af design behov som vi vil tage med os ind i vores efterfølgende design proces. Flere steder igennem interviewet (31:35) nævner Joos vigtigheden af at opnå projekt teamets comitment og forståelse for de opgaver man netop nu arbejder med. Et oplagt design behov for værktøjet er derfor at skabe et større og nemmere overblik for interessenter over projektet for derigennem nemmere at opnå denne commitment. Til den langsigtede planlægning benytter Joos programmet Microsoft Project til at skabe overblik samt formidle og sikre den ovenstående omtalte commitment fra deres samarbejdspartnere. Denne planlægning holdes på nuværende tidspunkt meget adskilt fra den daglige Scrum ledelse (44:50). Joos nævner efter denne beskrivelse at man dog kunne forestille sig at disse to tilgange kunne smeltes sammen. Enkelhed, intuition og driftsikkerhed er essentielt ifølge Joos(58:00). Mere avancerede teknologi hæver ofte kompleksiteten - en kompleksitet som et stående 15 min. Scrum møde ikke efterlader meget plads til. det kan godt være om 5-10 år når man har fået mere gang i noget trådløstnetværk og det ene og det andet, så kan det jo godt være man har en bærbar med og måske lige kan stå og kigge på den, men der er vi bare ikke teknisk Det går lynhurtigt hen og kommer til at handle om redskabet. ( 52;32). Udover at rumme en kritisk indstilling over for systemer med flere minutters boot time, pludselige systemfejl og ikke intuitive kursus krævende interfaces (40:05 og 54:00) ligger der her også et indirekte krav om overensstemmelse imellem teknologi og organisation. Igennem Joos' ord valg som f.eks. udtrykket "det ene og det andet" ses tydeligt en overvejende kritisk indstilling over for IT løsninger. Begrundet eller ej bliver Joos bærer af en organisationskultur der sætter nogle mere skjulte kriterier for hvilke løsninger de umiddelbart ser sig selv benytte. 35 S ide

36 4.2. Interview med Morten Stahlschmidt Om Morten Stahlschmidt Morten er arkitekt og arbejder hos Arkitema, hvor han har været ansat i to år. Morten har fungeret som projektleder i mange år, men har først efter sin ansættelse hos Arkitema og hans HOPLA uddannelse 10 sidste år, fået en mere teoretisk tilgang til projektledelse, det er også her han blev inspireret til at bruge Scrum i sin projektledelse. Projektopbygning Når Arkitema modtager en opgave, sidder der en enkelt arkitekt og vurderer om det er en opgave de kan påtage sig og hvor mange mand det vil kræve (bilag B; 22:00) 11. Godkendes opgaven bliver teamet herefter sammensat. Dette gøres dog ikke altid kun ud fra de forskellige ansattes kompetencer, men oftere ud fra hvilke medarbejdere der er ledige(28:06). Når nye folk bliver ansat i Mortens gruppe, bliver de parret op med en af de gamle medarbejder, en "onkel" det er en procedure som Arkitema har besluttet og Morten mener, at de nye ansatte på denne måde bliver bedst indsluset. Da vi interviewer Morten er han i gang med et stort ombygningsprojekt hvor der er et samarbejde med to eksterne samarbejdspartnere. Dette er et meget veldokumenteret samarbejde, hvilket er krævet fra bygherres side. Morten bruger her programmet Microsoft Project til at illustrere og dokumentere den overordnede tidsplan. Mortens brug af Scrum Morten benytter sig af en scrumtavle, denne beskriver hvilke opgaver man har den pågældende dag (se bilag E). Derudover bruger Morten også en planlægningstavle, der rækker ni uger frem (se bilag F), opgaverne bliver løbende flyttet fra planlægningstavlen til Scrum tavlen. Det daglige Scrum møde bliver afholdt klokken 12:30, fordi først der er alle medarbejdere samlede, ideelt set ville han ønske at det lå tidligere (5:33). Om de daglige Scrum møder siger Morten: "Men vi får faktisk utrolig meget ud af at dele med 10 Projektleder uddannelse hos Arkitema, (Helhedsorienteret projektlederuddannelse hos Arkitema) 11 I det følgende afsnit henviser alle min. angivelser til interviewet med Joos Jerne (Bilag A og lydfil 2). 36 S ide

37 hinanden hvad det er for nogle (arbejds-) pakker vi har gang i" (00:16). Hver opgave bliver tildelt en person, dette ejerskab i opgaverne er en stor styrke mener Morten. I vores interview med Morten beder vi ham om at give sin egen bedømmelse af sin brug af Scrum, med point på en succes skala fra 1 til 10, for at uddybe sin egen tilfredshed eller utilfredshed. Her giver han deres mødeteknik, et fem tal i forhold til overholdelsen af teorien og kommenterer: det er ikke specielt dårligt ikke vanvittigt godt, det er ikke noget der kører helt fantastisk. (31:30). De har valgt på Mortens projekt ikke at tidsestimere, da der hele tiden kommer noget nyt til (11:20). Han forklarer derefter, at han mener det er nemmere at tidsestimere de forskellige opgaver indenfor IT branchen i forhold til arkitekt branchen. vi ved ikke hvad der ligger bag ved en eller anden gammel gipsplade. (32:17) Dette er også grundet til, at de ikke laver tidsestimatater for hver enkel arbejdspakke. Så derfor ud fra en realistisk vinkel og hvordan man kan forvente, at det vil køre giver han dem selv et otte tal.(31:49). Morten gør os opmærksom på at det er svært at få hans kolleger til at huske at holde det daglige scrummøde, hvis ikke han er tilstede (05:00). Det tyder på at holdet ikke er helt engagerede og indstillet på hvad det kræver at køre Scrum. Engagement er dog et faktum som Morten er opmærksom på, han udtrykker senere at: den foregående planlægning bliver nødt til at være accepteret af teamet... det nytter ikke at have nogen med på teamet som ikke tror på tidsplanen (26;45-27;24). Et af de væsentligste problemer som Morten fremhæver, er deres lyst til at snakke indhold: Vi har den der med at vi har sådan lyst til at snakke indhold, vi vil så gerne alle sammen og byde ind (3;37-3;45). Det resultere i at de møder, som egentlig kun skal vare et kvarter lynhurtigt kommer op på en halv time, herigennem mister mødet sin egenskab som overbliksgiver, og folk mister koncentrationen. Morten har lige som Joos valgt at der er en ny Scrummaster hver uge. Dette har han valgt at implementere da han mener, det giver et større engagement fra alle i teamet, da hver medlem på denne måde ved hvordan det er, at stå med det ansvar Scrummasteren står med: "fordi ellers tager man det ikke ligeså alvorligt hvis man selv skal stå der oppe og holde styr på det så holder man også mere kæft nede i salen" (3:20-3:34). I følge Morten giver Scrum og dens elementer, et overblik f.eks. hvis der er sygdom hos en af teamets medlemmer: Men netop ved at holde Scrum hver dag så kan man fange op på om der er 37 S ide

38 nogen opgaver hos dem der er syge eller fraværende og dem ville man ikke kunne håndtere hvis man ikke havde den tavle (Scrumtavlen) (9;18-9;30). Når de daglige scrummøder bliver overholdt får Morten og teamet et stort udbytte ud af Scrum. Morten giver udtryk for, at det kan være svært at estimere tidsforbruget i Arkitekt branchen på grund af de mange kravændringer som er uundgåelige undervejs: Der er for mange ændringer under vejs Man ved ikke hvad det er for problemer man løber ind i, det kan tage en time men det kan også tage to dage (11:39-11:57) Som eksempel arbejder teamet på 24. uge på en opgave som oprindelig var estimeret til én uge. I dette konkrete eksempel mener Morten ikke at Scrum kan hjælpe med at opnå en mere præcis estimering, derimod kan det hjælpe med at takle de problemer som opstår på grund af fejlestimeringen: Der er altid et eller andet nyt der kommer ind, og det kan Scrum hjælpe utrolig meget til at håndtere ellers skal der være en eller andet stakkels projektleder der skal have alt det i hovedet. (24:04-24:15). Et problem på mange arbejdspladser er det øgede stress niveau ikke mindst inden for arkitektbranchen, Morten udtaler hvordan Scrum kan afhjælpe dette: "stressen bliver ligesom fordelt, på den her måde hjælper vi hinanden til at holde stressen lidt i ave... Når man har fortalt ud i gruppen, og de kan se hvor mange opgaver vedkommende har så er der jo masser af andre der foreslår "kan vi ikke gøre sådan" eller "skubbe det, eller"... man har ligesom i virkeligheden med Scrum hver dag en lille stressmåler på og det er i hvert fald også nødvendigt (24:20-24:56). Et andet aspekt, der er med til at sænke stressen uddyber Morten, at Scrum ligeledes kan være med til at øge samarbejdet på en arbejdsplads. Scrumtavlen bevirker, at alle kan følge med i udvikling, det skaber en visualisering om, at alle arbejde samme (19:15). Morten ynder også at lave faseplanlægning i samarbejde med sine medarbejdere, så alle kan gå ind for den(19:47) Design behov Selv om at Morten og teamet er glade for den måde de benytter sig af Scrum, ser vi stadig steder, hvor der er plads til forbedring nedenfor vil vi liste de væsentligste designbehov op. De daglige Scrummøder er for lange, og tiden bliver ikke udnyttet så godt som man kunne ønske sig. Grundet til de lange møder er at der bliver snakket indhold i stedet for at teamet holde sig til de få korte spørgsmål som er hvad der skal tales om på dat daglige Scrum møde(3:37). De daglige Scrum møder er centrale for at få mest muligt ud af Scrum og derfor er det et oplagt behov at få optimeret de daglige Scrummøder. 38 S ide

39 Tidsestimering bliver på nuværende tidspunkt kun gjort overordnet og ikke nødvendigvis for hver enkelt arbejdspakke. Morten mener ikke, at det kan lader sig gøre på grund af de konstant skiftende udefrakommende ændringer (32:17). Vi vil stadig påstå, at tidsestimering ikke er noget som bør gemmes af vejen, fordi det i sidste ende kan resultere i, at der kommer endnu flere uforudsete forsinkelser i sidste ende. Morten udtrykker stor glæde ved både at have Scrumtavlen og den overordnede Planlægninstavle synlig for teamet såvel som for ham selv (18:59). Derfor vil det være oplagt at beholde den mulighed i vores endelige design To Scrum or not to Scrum Et interessant perspektiv ift. vores projekt, er en diskussionen af hvordan en organisation adopterer Scrum, og hvilke effekt det har på processen, hvis Scrum blot delvist implementeres i organisationen som det er tilfældet hos Arkitema. Det ses f.eks. hurtigt at Joos og Morten kun benytter dele af de overordnede mødeformer (det retroperspektive møde, præsentationsmødet og planlægningsmødet). Et meget vigtigt Scrum projekt som umiddelbart for en til at stille spørgsmål ved om de overhovedet kan siges at benytte Scrum. Et centralt spørgsmål er derfor om man overhovedet bør ændre Scrum og under hvilke forudsætninger det kan gøres? I sin bog The Enterprise and Scrum forklare Ken Schwaber, en af hovedarkitekterne bag Scrum, i klare vendinger hvordan han ser på muligheden for at tilpasse Scrum: Do not change Scrum. Scrum isn't a process that you modify to fit your enterprise. [...] Whenever people change Scrum, it's because they have run into problem, dysfunction or conflict that they do not want to face or fix. Instead, they change Scrum so that the problem remains invisible and remains deadly to your enterprise. If you allow this to happen, you will have just lost Scrum's primary benefit. (Schwaber, The enterprise and scrum, 2007, s. 7). Schwaber er her meget klar i sin udmelding og igennem læsningen af hans bog får man også indtryk af at samme tilgang forsøges fulgt af alle de mange beskrevne firmaer. At en af Scrums fædre melder så klart ud, sender umiddelbart et meget tydeligt signal om den "gængse praksis". Det er imidlertid et velkendt faktum at der specielt ledelses- og ansvarsmæssigt eksisterer en betydeligt kulturelt forskel på USA og, specielt, de skandinaviske lande. Dette giver sig konkret til udtryk i f.eks. dyrkelsen af "frihed under ansvar'", eller f.eks. begrebet 'the scandinavien way', 39 S ide

40 der udtrykker Skandinavernes meget tidlige tildeling af magt til brugeren. Specielt den første kan være med til at forklare hvorfor vi igennem vores undersøgelse kun er stødt på danske firmaer, der benytter mindre rigide scrum-former (F.eks. Scanjour, Danske spil, Arkitema, Systematic). At Joos ligeledes heller ikke opfatter Scrum som en stærkt rigid ledelsesform ses tydeligt i hans beskrivelse af hvad Scrum er:"scrum er som jeg kender til det i virkeligheden en masse dele man støber sammen [...] og noget af det har man jo gjort i en eller anden udstrækning tidligere, så på den måde blev det i virkeligheden bare formaliseret og så havde man en fælles bevidsthed." (20:20). Dykker man længere ned i deres processer opdager man imidlertid at de på trods af deres begrænsede viden omkring flere af de gængse Scrum værktøjer har haft behov for den systematik som disse værktøjer tilføjer dem og derfor har "genopfundet" dem. Dette ses blandt andet i deres selvopfundne form for burn down chart: "[...vi] lavede en tidsplan, hvor man har tiden op på den ene akse og aktiviteterne ud af den anden akse, og så få den stillet op så man kan få et overblik, hvad er det der skal ske og prøve at estimere et tidsforløb..." [Joss Jerne; 17:55]. Sammenlignes denne f.eks. med Schwabers definition (Schwaber, Agile Project Management with Scrum, 2004, s. 141) er disse fuldstændige identiske. Et andet punkt hvor Jooses forståelse af Scrum også viser sig at være dybere end først antaget, ser vi igennem at han to gange i løbet af interviewet viser en forståelse af hans opgave som Scrummaster om at beskytte resten af teamet(19:20 og 24:45). På trods af også Mortens projektets lidt frie tilgang til Scrum, er de væsentligste aspekter fra Scrum blevet adopteret, hvilket Morten udtrykker sin tilfredshed og siger at: Hvis ikke man havde Scrum måtte man finde på noget andet, som man så gjorde det samme med (05:23-5:28). Ovenstående eksempel viser, mener vi, meget fint viser hvordan positive resultater kan opnås udelukkende ved implementering af nogle Scrum dele. Det er dog vores overbevisning at Schwaber har en væsentlig pointe i forhold til hvordan reglerne bør følges. Vi mener således godt at man med Scrum kan vælge ikke at indføre f.eks. reglen om bødestraffe for udeblivelse til et Scrum møde, (Schwaber, Agile Project Management with Scrum, 2004, s. 135) men indføres reglen i teamet bør denne også følges, ellers undergraves det selvansvar som Scrum tilføjer til det enkelte team medlem. På baggrund af ovenstående diskussion opstiller vi et kriterium for vores 40 S ide

41 værktøj om mere stringent brug af Scrum. Dermed ikke ment at vi ønsker at tilføje flere Scrum aspekter til deres nuværende brug, men at presse dem til at være konsekvente i forhold til de aspekter som de har valgt at benytte Opsummering/kritik I de to interviews ser vi nogle klare og sammenfaldende tendenser, både i forhold til behov og til hvordan begge projektledere har adopteret Scrum. Herved ser vi også sammenfaldende problemstillinger. På denne baggrund har de to interviews hjulpet til, at give en dybere forståelse af hvordan de to projektledere konkret anvender Scrum og hvilke bagvedliggende tanker de har gjort sig i forhold til Scrum. Som vi diskuterer i afsnittet To Scrum or not to Scrum, har vi erfaret, at der er langt fra Arkitemas brug af Scrum til den teoretisk beskrevne Scrum. I forhold til dette har vi skulle tage stilling til, hvordan vi behandler den information vi har indhentet om Joos Jernes og Mortens Stahlsmidts anvendelse af Scrum. Det er vigtigt for os at slå fast, at vores værktøj ikke nødvendigvis skal lære Arkitema at anvende Scrum stringent. Det kan kritiseres at vi tager udgangspunkt i to projektledere, der begge er relativt uerfarne i brugen af Scrum. Imidlertid mener vi, at dette faktum kan vendes til noget positivt. Vi argumenterer for, at de første gange man afprøver en ny metode, vil man have tendens til, at være mere opmærksom, end tilfældet kan være, hvis man har prøvet den samme metode 100 gange før. Vores interview med Morten Stahlschmidt foregik umiddelbart efter, at vi havde foretaget vores observation hos Arkitema. Vi er derfor bevidste om, at det gav en anden indgangsvinkel til interviewet, sammenlignet med den indgangsvinkel vi havde til interviewet af Joos Jerne, hvilket havde både sine fordele og ulemper. Fordelagtig fik vi muligheden for at stille uddybende spørgsmål relaterede til den tidligere sete observation. En ulempe var for eksempel, at vi havde en forudtagethed i forhold til, at de spørgsmål vi stillede var prægede af de resultater, vi havde fået under observationen. 41 S ide

42 4.6. Foranalyse gennemførelse og diskussion Gennemførelse Evalueringen blev gennemført i løbet af en dag, hvor to personer ved hjælp af Internettet fandt så mange mulige produkter (værktøjer) som muligt og derved skabte sig et overblik over mulighederne på markedet. På de produkter der umiddelbart opfyldte de 3 kriterier, udførte vi en mindre og lettere interimistisk usability test med os selv som forsøgspersoner. Samtidig blev vores samarbejdspartnere kontaktet, for at afdække hvilke produkter de allerede benyttede sig af. En liste af mulige løsninger til videreudvikling blev produceret, hvor de tydeligt uegnede blev sorteret fra. Til sidst blev listen gennemgået, hvor hver enkelt løsning i detaljer blev vægtet imod vores opstillede kriterier. Herefter blev de fire bedste løsninger fremhævet. Diskussion Under evalueringen blev det tydeligt for os, at værdien af vores tre kriterier ikke var uprioriteret som først antaget. Af disse tre kriterier viste "adgang til videreudvikling'' sig hurtigt at være et afgørende kriterium. Vi begrunder dette med, at dette kriterium havde en stor værdi for vores samarbejdspartnere, og det vitale samarbejde var grundlæggende for projektets succes. Havde vi vidst dette tidligere i forløbet af foranalysen havde det sandsynligvis ikke ændret på resultatet af undersøgelsen, men nok have gjort undersøgelsen hurtigere. Kriteriet vedrørende "Andre brugeres erfaring", har vi analyseret ved at søge erfaring på diverse online forummer. Ligesom vi også her har benyttet os af det tidligere omtalte interview med Jooos Jerne. Udover at være et glimrende kriterier til hurtigt at snævre vores muligheder ind, gav læsningen af andres erfaringer os desuden en dybere forståelse af, hvilke funktionaliteter, der var vigtige for en Scrum projektleder. På samme måde fik vi værdifulde erfaringer og idéer til udformningen af vores eget design, ved at besøge og studere de eksisterende værktøjer. Som nævnt tidligere, indsnævrede vi os til 4 mulige løsninger og efter at have nærstuderet programkoden, indstillede vi vores fokus på open-source programmet IceScrum (www.icescrum.org). Dette værktøj opfyldte umiddelbart de 3 kriterier og var samtidig det værktøj vi fandt mest brugervenligt. Dog viste det sig ved nærmere gennemgang, at dette program stadig brød med ønsket om et let tilgængeligt og simpelt interface. Hvis vi som udgangspunkt skulle bruge IceScrum til videre udvikling, var det vores klare overbevisning, at vi 42 S ide

43 måtte fjerne en række funktionaliteter. Samtidigt stod det os klart, at det ville kræve meget arbejde blot at "rense ud" i den eksisterende programkode, hvis dokumentation desuden hovedsagelig var på fransk. Alene efter at vi evaluerede de to ovenstående kriterier, "adgang til videreudvikling" og "let tilgængelighed", blev det os klart, at vi måtte ændre fundamentet for designet. Vi besluttede derfor, at gå en helt ny vej i forhold til selve udviklingen. Da vi påbegyndte vores Ex Ante evaluering af designet, havde vi et håb om at minimere udviklingstiden, netop ved at tage udgangspunkt i et allerede eksisterende værktøj og videreudvikle det. Med udførelsen af vores foranalyse havde vi imidlertid fået indsigt i, at denne vej meget vel kunne ende med at koste os mere tid samtidig med, at den væsentligt begrænsede vores muligheder, for at skræddersy vores løsning til vores fundne brugerbehov. Samtidig fik det os til tidligt i forløbet, at overveje andre alternative løsninger, som for eksempel kombinationen af en række præfabrikerede klasser, der ville indgå aktivt i vores design. På trods af, at vi ikke har overholdt rammeværket for Ex Ante evalueringen til fulde, har det været utrolig givtigt for os, at udføre den. Frem for at følge rammeværket, som det er beskrevet i metodeafsnittet, valgte vi at bryde ud af rammeværket og give plads til læring, i takt med at evalueringen gjorde os klogere. Konkret har det, som beskrevet ovenstående i dette afsnit, resulteret i at vi ændrede strategi til at skabe et design fra 'bunden', frem for at videreudvikle et eksisterende design. Overordnet kan vi konkludere, at vi ved at opstille de tre kriterier, hvilke vi har valgt at bygge vores foranalyse op omkring, har lagt et deskriptivt rammeværk for foranalysen af vores design. Herved har vi tidligt i processen fået en bevidsthed om det endelige design og de begrænsninger der måtte være for designet; erfaringer der ellers måske ville være kommet for sent i processen uden en foranalyse. 43 S ide

44 4.7. Observation af Scrum møde med Arkitema Fremgangsmåde til Scrummødet Til selve scrummødet deltager 10 personer. Mødet foregår i det åbne kontorlandskab, hvor de også sidder og arbejder. De fleste medarbejdere sidder ned til mødet, to af dem ved deres computere. Person A står ved Scrumboardet og fungerer som Scrummaster. A gennemgår kronologisk hver medarbejders arbejdsopgaver. Der bliver løbende skrevet nye post-its og flyttet rundt på dem som allerede er på tavlerne. Dette bliver gjort både af A og C. Beskrivelse af Arkitemas værktøjer til Scrum Til selve Scrummødet benyttes to tavler Planlægningstavlen og Scrumboardet. På disse bliver der påsat gule post-its, hvorpå arbejdspakkerne (arbejdsopgaverne) er beskrevet. Desuden benyttes pink post-its til at fremhæve vigtige deadlines. De gule post-its placeres først på planlægningstavlen der repræsenterer hele sprinten, hvorefter de ugentligt flytter over på Scrumboardet, der repræsenterer den respektive uge. På Scrumboardet er der både kolonner til aktuelle samt afventende opgaver. Der bliver løbende sat nye post-its på begge tavler Problemer relateret til udførelsen af Arkitemas Scrummøde Generelle uklarheder Der opstår i flere tilfælde uklarhed omkring arbejdspakkernes indhold. For eksempel person B s opgave om at tegne snit over kantinen som B har nogle opklarende spørgsmål til. Problemet er imidlertid at ingen rigtig kender arbejdspakkens præcise indhold, så det der kunne være løst med et kort direkte svar ender i en unødvendig diskussion. Herigennem ses et behov for at kunne beskrive arbejdspakkernes mere detaljeret end post-it noterne tillader. Et andet eksempel på uklarheden er, da der senere opstår uenighed om hvorvidt en specifik opgave (en brandplan) er udført tidligere. Her forekommer tvivl om hvad denne opgaves oprindelig indeholder, hvorvidt den er udfærdiget, og om den efterfølgende er opdateret. Samtidig forstår vi tidligt ud fra observationen, at der er stor udveksling af tegninger til ingeniørerne og entreprenørerne. I den forbindelse opstår endnu en uklarhed i mødet, da ingeniørerne har bedt om at få tilsendt en tegning, der allerede er afsendt en gang før. Samme uklarhed opstår også i forhold til hvad tidligere ansatte på projektet har lavet, og også i 44 S ide

45 forbindelse med opdatering og redigering af allerede afsluttede opgaver. Alle tre problematikker viser et behov for adgang til allerede udførte opgaver. Når uklarheder som disse forekommer, forsøger møde deltager generelt at skube diskusionen til efter mødet (netop som Scrum forskriver det). Vi observerede imidlertid at diskussionen flere gange fortsatte et stykke efter et ønske om udskydelse blev fremsagt. Rollefordeling Der forekommer mange afbrydelser mødet igennem små diskussioner opstår, på trods af, at A, der fungerer som Scrummaster prøver at holde styr på processen. I det fleste tilfælde er det relevante diskussioner, der har stor værdi for at kunne definere arbejdspakkerne, men det er ikke snak, der bør forekomme på et scrummøde. Ideelt set burde arbejdspakkerne være beskrevet så detaljeret at problemet ikke opstår til at starte med. Der opstår et konkret problem, da en af de A ansatte, K er syg. Det er tredje dag K er syg, og ingen ved, hvor langt K er nået med sine opgaver og heller ikke, hvornår K B kommer igen. Her tager D styringen og beder H om at ringe til K. K's fravær bliver en flaskehals, de andre ved ikke om de skal overtage K's opgaver, om opgaverne er udarbejdede eller om de overhovedet er påbegyndt. Det skaber en smule uro og ubehag da alle ved, at der skal afleveres fredag og det i dag er tirsdag. Samspil medarbejderne imellem D C Til selve mødet er mobiltelefoner og telefoner ikke slukket og de ringer adskillige gange. B sidder ved sin computer og kigger Figur: Sideplan ved observation 45 S ide

46 meget på skærmen, det er med til at skabe ubalance. Måden de sidder på er heller ikke ideel, i midten sidder D, B og C, bagved dem står og sidder der fire mand. Dem i midten skal derfor vende sig for at se på dem når de taler. Det kan opfattes som en hierarkisk opdeling, og har afgjort en negativ gruppedynamisk virkning på mødet. Samtidig bevirker de mange siddende at den ønskede "vi står op og er aktive i fællesskab" scrumeffekt ikke opnås. På trods af de uoptimale placeringsløsninger er der igennem hele mødet en fin respekt medarbejderne imellem og der bliver sjældent talt i mundet på hinanden. Det er som beskuer umiddelbart svært at få overblik over hvem, der har hvilke roller i gruppen. De fire mest tydelige roller og deres optræden under observationen har vi imidlertid beskrevet nedenfor: A fungerer som en blanding af ordstyrer og Scrummaster. Denne person insisterer bl.a. på dagsordenen "Nu snakker du indhold", fremdrift, stiller spørgsmålene om de andres fremgang (bruger dog ikke de 3 Scrum spørgsmål). A's spørgeteknik virker dog irrelevant da A opnår de svar som er vigtige. A holder fint fat i at de ikke skal snakkes indhold, dette bliver pointeret flere gange. På trods af A's ihærdige indsats varer mødet dog stadig over en halv time og ikke de optimale ca. femten minutter. B vil gerne kommentere det meste og har en tilføjelse eller et spørgsmål til flere af de ting som B som sådan ikke har noget med at gøre. Men det er også B der gør opmærksom på mange af de ting, der rent faktisk er problemer med, og som burde have været afklaret tidligere. C er officielt intern projektleder og erfaren arkitekt. Under scrummødet deltog C dog kun halvhjertet og det er tydeligt at det ikke er C's ønske at benytte scum. Kun fordi C, er den eneste som ligeværdigt siger D imod, virker det som om C har en vis autoritet i gruppen. C kommer nemt til at snakke indhold og tager det ikke så tungt, når han bliver gjort opmærksom på dette. C joker i stedet med det og siger: Jeg skal lige på kursus i Scrum, og det går der nok 14 dage med, alle griner hvori vi mener at kunne tolke en indirekte accepter af, at han ikke følger de fælles regler? D sad midt i rummet, havde planlægningsnotaterne, værnede om Scrum processen, lukkede mødet og tog til tider over som ordstyrer. Han stod for planlægning og havde de forskellige skemaer. Samtidig koordinerede, prioriterede og uddelegerede han opgaver (H gider du lige..."). 46 S ide

47 Han tog også flere gange styring over processen "vil du sætte den opgave ned på F", Hvornår kan du have noget klar til det de andre kan begynde at tegne på?. Overordnet kan det siges at D havde den endelige plan for øje, samtidig var der ingen tvivl om at han så sig selv som adskilt fra resten af teamet. Således så han ikke megen mening i at han selv blev gennemgået da Scrum runden nåede til ham: "tjo, det skal vi vel". D gik også ind og beskyttede sine ansatte, da det blev klart, at der skulle arbejdes over i weekenden ("Jeg synes kun I skal arbejdes en dag, så ikke hele jeres weekend bliver ødelagt"). D agerer således altså både som product ejer og Scrummaster. D definition af sin egen rolle er at viderebringe info fra eksterne kilder (jf. efterfølgende interview). Fra scrummøde til Planlægningsmøde Efter cirka en halv time tager D ordet og spørger om der er flere som har noget til Scrum mødet for ellers vil D gøre det til et planlægningsmøde. Mødet bliver derefter uden pause til et planlægningsmøde, der er ingen markeret overgang, bortset fra at det nu er D som er ordfører og ordstyrer. De allerede stående forbliver således stående. Konklussion Efter selve observeringen undrede det os, at der ikke havde været en mere grundig planlægning inden projektet startede. Der hersker en generel uklarhed i mange af de væsentlige aspekter, i projektet; det endelige aflevering materiale, de udefinerede arbejdspakker og dokumentationen af tidligere afsluttede arbejdspakker. Arkitektbranchen er en turbulent branche med konstant skiftende krav. Dette må imidlertid aldrig bruges som en undskyldning for ikke at definere og strukturere det arbejde, der skal gøres for så vidt som det er muligt. Den tid man eventuelt ville bruge på et sprint review møde (otte timer) vil sandsynligvis i sidste ende være med til at afklare nogle problematikker, der ellers skal findes løsning på, på et senere tidspunkt, hvor tiden er knap og stressen har sat ind. 47 S ide

48 De vigtigste elementer fra observationen 1. Post- it: De er i nogen tilfælde svære at læse, de er ikke uddybende nok, kan falde ned (jævnfør Joos) 2. Sygdom: akut problem hele processen afhænger af, at alle får lavet de opgaver de får tildelt, hvad er proceduren når en medarbejder bliver syg, 3. Information og dokumentering: både af pågående men mest af afsluttet arbejde. Generelle problemer: 4. Roller: hvem står for hvad? Opdelingen imellem Scrummaster, productejer, og team er uklar. 5. Møderne: Hvis det er meningen at projektet skal ledes med Scrum er det vigtig at "reglerne" bliver respekteret Andre kilder Udover at observere og interviewe Arkitema har vi også indhentet information andre steder. Vi bl.a. foretaget en observation og et åbent interview hos Danske Spil af projektleder Karin Hansen. I forhold til Arkitemas brug af Scrum, har DS en helt anden struktureret tilgang til brugen af Scrum. Dog virkede de for os mindre tilgængelige i forhold til et samarbejde, da deres meget klare strukturer gjorde det svære at ændre uden at forstyrre deres proces. Derudover har vi deltaget i en forelæsning på ITU omhandlende agile metoder herunder Scrum, hvor Karin Hansen holdte oplæg (Hansen, 2008), samt deltaget i en konference hos Nykredit, hvor forskellige virksomheder og organisationer diskuterede fordele og ulemper ved agile metoder, hvor blandt andet Tim Kasse holdte oplæg (Kasse, 2008). Vi har også talt med konsulent Kristian Haugård fra goagile angående om hans kendskab til Scrum og erfaringer hermed som dog vil blive behandlet overfladisk i perspektiveringen Delkonklusion og kravspecifikation I dette afsnit vil vi redegøre for de behov opstillet i rapportens første del. Hoveddelen af disse behov vil være baseret på observationen, da problemer har en tendens til oftere at fremstå tydeligere igennem handling frem for tale (Robson, 2002). Både Morten og Joos benytter sig af en lav praktisk model, hvor post it spiller en stor rolle. 48 S ide

49 Ved vores observation fremgik det tydeligt, at post-it'ne på trods af deres symbolske værdi som innovative og håndgribelige, havde visse bagsider og begrænsninger. Både Morten og Joos efterlyser historik, hvilket også tydeligt fremgik af observationen. Udover at være et problem i de tilfælde, hvor det slet ikke var muligt at genfinde en tabt information, gik en stor mængde spildtid med at diskutere sig frem til informationen. Samtidig havde post-it'ne den bagside at de var små og derfor var det begrænset hvor meget beskrivelse der kunne tilføjes, hvilket ligeledes førte til væsentlig spildtid. Vi så ved observationen at der var stor udskiftning mellem Planlægningstavlen og Scrum tavlen, det skabte det dynamiske overblik som Joos efterlyste ved sin brug af Project. Derfor ser vi det også som et essentielt behov, at designet ligeledes indeholder både planlægnings- og Scrumtavle. Commitment to Scrum så vel som commitment til projektet er essentielt, hvis et Scrum ledet projekt skal bliver vellykket, hvilket Joos ligeledes nævnte som en vigtig faktor i sit interview. Ved observationen så vi imidlertid netop manglen på commitement og hvilke bagsider dette medførte. Denne manglende comitment skyldes imidlertid ikke kun manglende lyst, men skyldes i lige så høj grad de fysiske ramme, der ikke tillod opfyldelsen af de basale regler inden for Scrum, som for eksempel at stå op og overholde de 15 minutter. Vi kunne ved observationen og også ved interviewene se og høre, den overvejende tilfredshed der var med den lav praktiske model. Post-it'ne var med til at gøre det uprætentiøst, uhøjtideligt og der var ikke så mange dikkedarer, idet ikke krævede, at teamet først skulle sættes ind. Derfor så vi det som meget vigtig at vores design var intuitivt, overskueligt og håndgribeligt. Som Joos udtrykte det var det ikke noget man skulle på kursus i to uger for at kunne benytte sig af (40:05). Imidlertid kan man overveje om det upræsentiøese i virkeligheden også var med til at nedbryde den commitment og autoritet for Scrum som vi efterlyste ovenfor. Samtidig var den lav praktiske model dog også let tilgængelig og driftsikker, da den hverken skulle bruge flere minutter på opstart eller for den sags pludselig ville bryde sammen, hvilket ligeledes blev pointeret som et væsentligt behov i interviewene. Ud over de umiddelbare krav som opstår ud fra behovene til designet, var der også et par behov som fald uden for kategori. Vi kunne godt tænke os at få dem op af stolene, og få den energi som der burde have været. Derfor besluttede vi at vi som en lille bibeskæftigelse ville prøve at forbedre de fysiske rammer for deres Scrum møde, så vidt som det var muligt. 49 S ide

50 Del 3 Designproces 5. Design 5.1. Overordnet forløb Vi var fra begyndelsen overbevist om at benytte os af en agil og iterativ tilgang til vores designforløb. Naturligvis var dette et logisk valg, eftersom vores projekt netop behandler en agil metode. Imidlertid skyldes valget i lige så høj grad, de agile metoders relevans overfor komplekse og svært definerbare projekter (Schwaber, Agile Project Management with Scrum, 2004, s. 5) som vi overordnet opfattede vores eget som værende. Projektet, besluttede vi, skulle falde i 3 iterationer (se nedenfor): en mental designfase, hvor tanker og idéer blev fastlagt i mockups og storyboards, en fysisk implementeringsfase, hvor tanker blev oversat til kode, samt en afsluttende tilpasningsfase, hvor designet igennem en række tests blev tilpasset til den konkrete brug. På et overordnet plan var der altså tale om et lineært udviklings forløb. 50 S ide

51 Uge 1: Uge 2 2: Uge e3: Men ntalt deesign Imp plemen nteringg Tilpassning Defineering af desiggnbehov Redesign af sto oryboard Redesign / ffejlretning Arkitektur B Brainstorm/Id deo Test v. Arrkitema Lån af opensourrce classer Ce entrale mockkups Grafisk mockup Evalueringg af test Storyboard d Implementeringg af design Feejlretning pbaa. Arkitemas kommen ntarer S Storyboard te est Tænkehøjt FForsøg Evvaluering af ttest Evaluering aaf test Afprøvn ning af design v. A Arkitema Figur 8: Grafiisk fremstillin ng af designprroces At man alligevel kan tale om et iterativt fo orløb skylde es den heftige brug aff tests og re edesign igennem hele h forløbe et. Ser man n på hver en nkelt fase s ses det at hver h enkelt fase genne emløber de e samme tre e processorr. Der er alttså tale om m en spiralfo ormet udviklingsmode el. Sidste fa ase gennemløb ber dog alle e faserne 2 gange. 51 S i d e

52 Design n Evaluering T Test Figur 9: Illusstration af de indre iteratio oner Da de enk kelte tests og o de enkellte designfa aser er nærrmere indby yrdes forbu undet end med m deres kronologis ske naboer vil vi neden nfor først gennemgå g d de design teknikker vii har benytttet os af sa amt de væsenttligste og mest m centrale observattioner vi gjorde os und dervejs, hv vorefter de forskellige testformerr vil gennem mgå samme behandlin ng. Af hens syn til plads sen har vi v valgt ikke at a dykke ne ed i samtlige processer. p 5.2. Metode e og tekn nik Til den me entale desig gnproces be enyttede vii De Bonos tænkehattte (Bono, ). De bonos tænkehattte er en me etode til at stimulere kreativ k tæn nkning. Teorien er, at ens kreativ vitet almindeligvis bevæge er sig i de samme s rille er men, ved d at indtage e foruddefinerede tæn nkeposition ner e sig selv til at bryde med m denne tendens. Konkret K gørres det ved d, at man sk kiftes til at kan tvinge have én aff de seks fo orskellige "hatte" på, hattene rep præsentere er hver isærr en konkre et tilgang og o indstilling. I vores brug benyttede vi imidle ertid til tide er to hatte på samme tid for at åbne å erne mere op o (Pries-Heje (red.), 2008A, forrelæsning 7 sl. 27). mulighede Bonos røde e og grønne e hat lod vi os desuden n inspirere af den ame erikanske Under brugen af De B ed IDEO's te eknik til udarbejdning g af idéer (P Pries-Heje (red.), ( 2008A, 7. forelæsning). virksomhe 52 S i d e

53 Teknikken går i al sin enkelthed ud på, at alle byder ind med sine egne vidt forskellige løsninger på et problem. Som små byggeklodser hentes så de bedste idéer fra hver enkelt løsning og forsøges samlet i én fælles løsning. Senere i forløbet benyttede vi tre prototypeteknikker: papirprototyper, computermockups (papirsprototyper udarbejdet på computer), samt storyboardteknikken. Udover at fungere som brainstormingsværktøj blev disse ligeledes blandt andet benyttet for at sikre, at projektets overordnede designkoncepter ikke forsvandt under udarbejdelsen af koden. Storyboard teknikken valgte vi desuden at benytte os af, da vi herved nemt kunne omsætte vores designforslag til en designhistorie og dermed afprøve om vi havde fået alle aspekter af et scrummøde med Designforløb Vi startede vores designproces med at brainstorme udefra, hvilke behov vi havde fundet igennem observation og interviews hos Arkitema. Under brainstorm brugte vi den hvide og den gule tænkehat. Den hvide idet vi ikke var kritiske og forholdt os objektive til ideerne og forslagene. Den gule fordi vi var i opstartsfasen, hvor vi endnu ikke ville forholde os til hvad der ikke ville kunne lade sig gøre, men i stedet fokusere på at producere en masse ideer. Da vi følte at alle centrale behov fra vores behovsanalyse var indsamlet og nedskrevet gik vi hver til sit og udarbejdede forskellige forslag til, hvordan vi så det endelig produkt. Da vi samledes igen tog vi den grønne og den røde hat på. Den grønne hat for at lade ideerne flyve og den røde for at sikre spontanitet og begejstring så vi ikke lagde bånd på os selv. I løbet af dagen skiftedes vi til at diskuterede de forskellige forslag og gå i tænkebokse, hver for sig eller to og to, og udarbejde nye forslag. Figur 10: 12 centrale behov 53 S ide

54 Efterhånden som arbejdet skred frem skete 3 ting: For det første blev gode designidéer løbende genbrugt. Således blev de idéer vi var mest begejstrede for hængende fra version til version imens middelmådige løsninger forsvandt igen. For det andet kom vores udkast indbyrdes til at ligne hinanden efterhånden som vi så perspektiverne i de forskellige idéer. For det tredje blev detaljegraden større og større fra udkast til udkast i takt med at de overordnede linjer blev mere og mere faste. Figur 11 Visuel idéudvikling Da vi afslutningsvis følte os tilfredse med resultatet udarbejdede vi sammen et detaljeret storyboard af hver enkelt 'skærmbillede' ved brug af den blå hat. Her tilføjede vi også kommentarer om det grundlæggende grafiske design, samt detaljeret beskrivelse af programmets reaktioner på klik og lignende. I den forbindelse benyttede vi os samtidig af den sorte hat og fjernede meget tidskonsumerende funktionaliteter samt sektioner som vi vurderede Arkitema i vores test alligevel ikke ville støde på. 54 S ide

55 Figur 12 Udkast fra papirprototypen Efter at have gennemført vores første test, rettet og tilføjet de mangler som testen havde påvist havde vi et godt billede af hvordan vi ønskede applikationen udformet. Vi udarbejdede herefter sidens arkitektur ved brug af pseudokode. Kort før vi var færdige med at udvikle pseudokode gav vi os i lag med at søge inspiration og opensource klasser online til at løse et specielt tricky problem vi var stødt ind i. Her blev vi imidlertid meget forundrede over at finde ikke bare små tilgængelige løsninger, men hele veldokumenterede systemer. Diskussion De Bonos tænkehatte hjalp os til at holde fokus i designprocessen og for eksempel at minde hinanden om ikke at kritisere forslag under brainstormen. Eksemple på pseudokode: [...] hent alle arbejdsopgaver 'sprint_uge' == 'uge_aktuel' 'sprint_uge' == null order by 'navn' for hver bruger(){ skriv navn skift kolone for(i=<3; i=1; i++){ for hver opgave hvor 'status' == i && ansvar==bruger[j]{ indsæt postit med titel, ekstern deadline } gå til næste kolone } gå til næste række} gå til næste række [...] Vi er fuldt bevidst om, at vores brug af flere tænkehatte på én gang, står i kontrast til metodens mål om at komme helt i dybden med ét aspekt (Pries-Heje (red.), 2008A, 7. forelæsning, sl. 37 ). Imidlertid kan man diskutere om dette mål i virkeligheden ikke også står i kontrast til De Bonos 55 S ide

56 eget ønske om at skabe et diskussionsmiljø, hvor flere tænkemåder bringes i anvendelse (sl. 28, samme forelæsning). I hvert falde kan man pointere, at den meget store optagethed af tværfagligt arbejde jo netop skyldes en tro på, at det kreative netop opstår, hvor kontrasterne mødes. Således betvivler vi ikke De Bonos argument om, at kreativitet opstår uden for ens sædvanlige tænkepositioner. Derimod er det vores oplevelse, at en diskussion imellem mange mennesker med identisk tænkeposition også hurtig mister en smule af sin energi og nerve, og dermed efter vores mening også en del af sin kreativitet. Det er vores oplevelse at hattene ikke umiddelbart fungerede dårligere ved brug af to hatte på samme tid - Dette kan dog måske i ligeså høj grad forklares som et temperaments spørgsmål. En nærmere undersøgelse af dette vil dog være nødvendig før nogle egentlige erfaringer kan dannes.. Det var vores oplevelse, at IDEO tilgangen var meget velfungerende og sikrede en meget frugtbar brainstorm. Samtidig var det gruppens oplevelse, at den meget praktisk orienterede designproces var med til at vende op pg ned på de traditionelle grupperoller. Hvor et gruppemedlems retoriske evner almindeligvis er afgørende for videreformidlingen af hans tanker var det pludselig andre mere visuelle evner der var væsentlige, hvilket vi opfattede som en sund oplevelse for gruppen. Samtidig åbnede processen op for, at man ikke nødvendigvis behøvede at blive enige om den bedste løsning. I stedet viste det sig hurtigt, at kun de idéer som gruppemedlemmer virkelig brændte for gik videre fra runde til runde og dermed i sidste ende blev en del af det endelige design. At arbejdet med IDEO tilgangen blev oplevet så meget som en succes skyldes sandsynligvis i lige så høj grad brugen af papirsprototyper, der var sådan en succes, at vi hurtigt helt opgav brugen af computere. En af fordelene herved var oplevelsen af en kortere vej fra idé til mediering, der netop ofte anføres som argument for den fortsatte brug af papir i sådanne sammenhænge. Imidlertid blev vi også opmærksomme på den mindre åbenlyse fordel, at papir som medie hele tiden tvinger en til at starte forfra i modsætning til computermediet, hvor man ofte bliver ved med at rette i den samme fil. Herved mistes historikken og muligheder for at arbejde med flere sideløbende idéer ved at man hele tiden kan vende tilbage til det og se hvad man tidligere havde tænkt på. Samtidig hjælper tvangen om hele tiden at skulle starte forfra en til at blive ved med at stille spørgsmål til hele designet. Hen mod slutningen, hvor flere elementer var låst definitivt fast ophørte dette imidlertid med at være en fordel, hvorfor man måske med fordel her kunne have vendt tilbage til computer mediet. 56 S ide

57 Ved hjælp af pseudokoden havde vi en mere detaljeret forståelse af hvilke etaper, der skulle tages før vores design var i mål, samt hvor lange de forskellige etaper ville være. Samtidig bidrog pseudokoden til, at de medlemmer af gruppen, der ikke havde tidligere erfaring med programmering, fik en større forståelse af dette. Imidlertid oplevede vi en klar problematik ved at kombinere vores udviklede pseudokode med vores ønske om at benytte allerede eksisterende systemer. Disse systemer havde nemlig imidlertid en væsentlig anderledes arkitektur, som var svært forenelig med vores pseudokode. Tilgangen var dog stadig en meget givende proces, da den gav os en mere jordnær og praktisk forbindelse imellem koncepter og kode, men det er vores overbevisning at man, i forhold til muligheden for at kombinere med tidligere udviklet kode, bør eftersøge sådan kode før man begynder at opbygge sin arkitektur. Brugen af en iterativ designproces sikrede at vi hele tiden kunne tilpasse vores applikation. F.eks. viste det sig, at med en tegnestue som testbruger, blev der fokuseret meget med det grafiske udtryk. Vores agile metode bidrog således til, at vi fik et produkt med færre fejl. Brug af metaforer Et af de overordnede behov har været, at designet skulle være intuitivt. På forsiden har vi forsøgt at overholde denne intuitive tilgang ved grafisk at skabe fire store og indbydende knapper. For at opnå den indbydende effekt er knapperne blevet pålagt skygge og lyseffekt på oversiden. Skyggen giver brugeren en association til at knappen kan trykkes ind vi forsøger på denne måde at skabe en metafor for den virkelige verdens knapper. Denne metafor underbygges yderligere når interfacet tages ud af den traditionelle computerskærm og føres over på smartboardet, hvor brugeren anvender sin hånd som styreredskab og derved opnår følelsen af at trykke på en fysisk genstand. Herved opstår der en spændende krydsning af virkelighed og det virtuelle. Dette er en metafor vi benytter gennemgående i mange af applikationens øvrige knapper. Som behandlet i foranalysen har det været essentielt, at vores applikation skulle kunne indgå forholdsvis gnidningsfrit i det daglige scrummøde, og derved spare brugeren tidskrævende indlæring. Det er af denne grund, at vi har arbejdet meget med metaforer i designet af vores applikation, metaforer som vi har taget fra brugernes egen verden. I denne sammenhæng har post-it note en som symbol været meget væsentlig. Ved at bibeholde post-it-metaforen fra det eksisterende lav praktiske værktøj som vores brugere benyttede, har idealet været at oparbejde en intuitiv forståelse af applikationens funktioner. Metaforen bruges altså til at imødekomme den 57 S ide

58 mentale model hos brugerne (Holden, Lidwell, & Nutler, 2003, s. 130) ved at trække på brugernes eksisterende erfaringer med post-it notes som det bærende element i projektkoordineringen. På denne baggrund har det været vigtigt at post-it note en i applikationen, fik egenskaber der var nært beslægtet til de fysiske post-it notes. Det er derfor muligt at trække post it note en frit rundt på skærmbilledet. I denne forbindelse kan man også tale om begrebet affordance 12 (Holden, Lidwell, & Nutler, 2003, s. 20). I forbindelse med flytningen af post-it notes i applikationen, har vi gjort os en række overvejelser i forhold til affordance. Her kan det nævnes at, det skulle være muligt at bruge hele post-it note ens flade til at trække denne rundt, uden at gøre brugeren eksplicit opmærksom at dette er muligt. Det skulle altså fremstå således, at brugeren selv ser det som en mulig aktion, at han kan trække post-it note en rundt på skærmen. En anden overvejelse i forhold til affordance har været det man kan kalde snap-funktionen 13, det vil sige den funktion som får post-it note en til falde på falde på plads selvom man slipper den lidt skævt i forhold til der hvor den skal sidde. 6. Test og evaluering 6.1. Overordnede tanker Jakob Nielsen, en af de mest anerkendte navne inden for usability området, fremlagde i 2007 en længere diskussion, hvor han gjorte opmærksom på nogle af de usability faldgruber, der forbinder sig til brugen af agile metoder (Nielsen, 2008). Han advarer her imod den fare, der ligger i at de overordnede usability koncepter forglemmes, når man deler opgaverne op i mange små bider. På den baggrund anbefaler han blandt andet at man indarbejder mange hyppige tests og benytter overordnede prototyper eller storyboards tidligt i processen. Disse anbefalinger passede efter vores vurdering utrolig godt i vores eget agile designforløb, hvor vi ligeledes så en fare for at miste de overordnede koncepter og vores overblik. Samtidig havde ikke alle i gruppen lige stor programmeringserfaring, hvorfor arbejdet med papirsprototyper, fuldstændig uden kode, ville sikre en mere ligeværdig deltagelse. Udover disse anbefalinger var 12 Vi er bevidste om diskussionen af perceived affordance(jf. Don Norman), vi vælger dog at adoptere en simpel tilgang til termen, med udgangspunkt i Universial Principles of Design[ (Holden, Lidwell, & Nutler, 2003). 13 fra engelsk to snap: to move, or to move something into position quickly, Oxford English Dictionary 58 S ide

59 hele gruppen meget inspireret af de tanker lektor Jesper Simonsen knytter til 'participatory design (Simonsen, 2008), hvorfor vi har været ekstra fokuserede på inddragelse af brugeren. På den baggrund fastsatte vi et mål om tre design iterationer med tre tests: papirprototyping, tænkehøjtforsøg samt afslutningsvis, en større brugerinddragelses test i en autentisk kontekst. På den nedenstående figur er dette vist med udgangspunkt i Strategies for design science research evaluation (Pries-Heje et al, 2008B)(SDSRE), jævnfør kapitel tre Test i naturlig kontekst Figur 13: Evalueringsmodel hentet fra SDSRE For alle tre tests gælder det er, at de foregår ex post, hvilket fortæller at de alle foregår efter at selve systemet er konstrueret, derudover i naturalistisk kontekst hvilket fremgår på ovenstående figur. Figuren ovenfor har specielt relevans i forhold til den afsluttende test, hvor vi havde brugerinddragelse i en naturalistisk kontekst(naturalistic). Ligesom beskrevet i kapitel tre tager evaluering udgangspunkt i en proces og et kriterie - jævnfør figuren(p og C). I denne ex post evaluering er processen(p) at måle brugervenligheden gennem brugerinddragelse (usability test). Og kriteriet er at finde forbedringsmuligheder(c) på baggrund af usability testen. Det kan diskuteres hvordan man skal måle evalueringen, og afkastet heraf, i vores tilfælde fokuserede vi på brugervenlighed og forbedringsmulgheder af denne. SDSRE behandler denne problemstilling; her taler man om at anvende rammeværket normativt (Applying the strategic framework normatively (Pries-Heje et al, 2008B)). Med dette udgangspunkt anvendte vi en user based quality definition, hvor kvalitet ses som egnethed i forhold til tilsigtet anvendelighed 59 S ide

60 (behov). Med udgangspunkt i det normative rammeværk har vi i forbindelse med de tre gennemførte tests, målt kvaliteten af vores design produkt, i forhold til de behov vi har opstillet i behovsanalysens afsluttende kapitel, sammenholdt med hvordan slutbrugerne rent faktisk anvendte produktet. Her igennem har vi haft en måde at måle og finde mulighederne for forbedring af design produktet Papirprototyping Undersøgelsesdesign For at skabe et bedre overblik over hvad vi ønskede vores endelige design skulle kunne rumme, fremstillede vi en papirprototype, en såkaldt mockup. Denne fremstillede vi inden vi havde produceret noget kode for på den måde at kunne teste applikationen inden den var færdig og herigennem allerede i opløbet fange eventuelle problemer eller komplikationer. Ved produktionen af en prototype taler man om fire dimensioner; blivende overfor smid væk, vertikal overfor horisontal, problemafklarende overfor løsningsorienteret, og endelig om der er stor eller lille lighed med det endelige produkt (Pries-Heje (red.), 2008A, 9. forelæsning sl. 31). Eftersom vi havde besluttet at lave en papirprototype, var der lille lighed med det endelige produkt, da den var lige til at smide væk, den var problemafklarende og horisontal, altså vi gik ikke ned i en enkelt detalje, men så på det brede spektrum og den var med til at gøre os opmærksom på relevante problemer relateret til værktøjet. Vi havde i forvejen brugt storyboards i idé udviklingsfasen, og havde derigennem dannet os et godt indtryk af hvad vi ønskede det endelige design skulle indeholde. Papirprototypen fremstillede vi med et håndtegnet A4 ark per skærmbillede. Selve fremstillingen af hvert skærmbillede var meget frugtbar, da vi her blev tvunget til at tage stilling til præcis hvad brugeren skulle kunne foretage sig på hver enkelt side. Diskussion Som udgangspunkt skal en papirprototype testet på en reel bruger (Gardner, 2000), i vores tilfælde gjorde ydre omstændigheder desværre ikke dette muligt, da vi desværre ikke kunne benytte os af vores samarbejdspartnere hos Arkitema, eftersom deres tid var stramt beslaglagt. Dette var et kompromis vi måtte forlige os med. 60 S ide

61 På trods af at afprøvningen blev foretaget internt i gruppen fandt vi flere steder, hvor der var brug for forbedringer, der ville kunne gøre det nemmere for brugeren at navigere rundt. Når der opstod et konkret problem, noterede vi det ned og diskuterede derefter hvad der skulle til for at undgå det, i andre tilfælde kunne vi under selve testen tilføje de features til papirprototypen, der blev efterspurgt. Vi valgte derfor i stedet at teste papirprototypen internt i gruppen, da vi stadig så stor værdi i testen, også selvom denne nu forekom mindre naturalistisk Tænkehøjtforsøg Undersøgelsesdesign Til den anden test af vores design udfærdigede vi en række spørgsmål, som vi benyttede os af til at guide os, og testpersonen, igennem testen (se bilag F). Spørgsmålene var udfærdiget så samtlige sektioner og funktionaliteter blev berørt. Flere undersøgelser har vist (Studiestrategi, 2007) at et menneskes koncentration daler kraftigt efter ca. 50 minutter, hvorfor vi forsøgte at sammensætte en kort test. Dette er også begrundet af, at vi ligeledes arbejder med et produkt, hvis daglige brugstid ikke bør overstige 15 minutter, derfor vurderede vi at en testtid på mere end 45 minutter blot ville gøre testmiljøet mere kunstigt. På grund af den nedprioriterede efterbearbejdning valgte vi at opstille vores egen simple kategoriseringsteknik med inspiration fra to anerkendte kategoriserings metoder. (Jensen J. J., 2007), (Lauesen, 2005, s. 4-18). Denne kategoriseringsteknik er ligeledes tilgængeligt i bilag F. Vi havde, jævnfør vores tidligere nævnte overordnede tanker, valgt at nedprioritere forberedelserne til denne test ud fra devisen om mange små og hurtige test/iterationer frem for en lang velforberedt tests. Således valgte vi i vores undersøgelsesdesign kun at teste med en deltager, samt hverken at optage forløbet, testperson eller skærmaktivitet, som vi for eksempel gjorde med vores afsluttende test - optagelser, hvis efterbearbejdning hurtigt kunne sluge den samme mængde tid som en ekstra test ville have taget. Det er klart at begge dele væsentligt nedprioriterer undersøgelsens validitet. Vi mener imidlertid at denne tilgang i alt taget i betragtning, kan forsvares udefra det faktum, at vores hovedformål med projektet, ikke er skabelsen af det perfekte produkt, men derimod en nærmere undersøgelse af vejen dertil. 61 S ide

62 Diskussion Resultatet af vores tænkehøjt forsøg var overvejende positivt. På meget kort tid opnåede vi at opstille 19 problemer relateret til produktet - problemer som vi ikke var os bevidst før testen, hvilket er lidt over hvad der almindeligvis forefindes på 30 min. (Pries-Heje (red.) 2008A, 10. forelæsning, sl. 34). Endvidere havde vores valg af en arkitekt højnet chancen for, at de fejl der blev fundet, faktisk også ville betragtes som fejl for de brugere, der senere skulle benytte produktet ( (Pries-Heje (red.), 2008A)slide 38, 10 forlæsning). Helt konkret resulterede vores valg af testperson med nær tilknytning til slutbrugerne i, at ca. 50 % af fejlene relaterede sig til det æstetiske. Imidlertid er det vores vurdering, at dette udelukkende var en fordel, da produktets slutbrugere ligeledes var arkitekter og lignende, og derfor sandsynligvis også vil have en øget fokus på dette aspekt. Et væsentligt problem vi oplevede under forløbet er, den meget omtalte tendens til aldrig at føle sig helt klart til en test - i almindelig tale kaldet præsentations angst. Som udviklere er man ofte sygeligt fokuseret på en mængde småfejl på produktet - fejl som hos slutbrugeren ofte ikke engang opdages - men som støder ens 'faglige' stolthed. Det er imidlertid netop som svar på denne problematik, at brugertests kommer til sin ret. Igennem testen sikres nemlig en fortsat fokus på de elementer som brugeren faktisk vurderer som væsentlige. Fordi vi netop havde erfaring med denne effekt, undgik vi at udskyde testen fire timer, hvilket selv i et kort designforløb som vores, må betegnes som. Det er imidlertid vigtigt at bemærke, at de problemer vi fik identificeret under testen i alvorlighedsgrad, stod i skarp kontrast til de problemer vi arbejdede med forinden. Det er således muligt at de fier timer alligevel kunne være blevet brugt mere fornuftigt efter testen. Et andet væsentligt problem vi dog oplevede under testen skyldtes efter vores vurdering, at vi valgte at gennemføre testen i testpersonens eget hjem på en fredelig søndag. Kombineret med en utrolig stor interesse i vores produkt fra testpersonens side, erfarede vi at testpersonen hurtigt mistede interessen i vores spørgsmål og i stedet gav sig til at lege med programmet, som om han gennemførte sit eget lille scrummøde. Det var imidlertid tydeligt for os alle, at denne naturlige interesse stimulerede en langt mere naturlig brug af værktøjet, hvorfor vi ikke afbrød dette men i stedet blot kom ind med passende spørgsmål, for at nå ud i alle krogene af systemet samt stimulere forsøgspersonen nysgerrighed, når denne virkede til at gå død i en sektion. 62 S ide

63 6.5. Afsluttende test hos Arkitema Jævnfør vores tidligere nævnte anskuelser i afsnit 'foranalyse', har vi tidligt valgt at ville benytte en ex post evaluering i naturalistisk til afsluttende evaluering af designet. Den tredje og fjerde test, af vores endelige design finder sted hos Arkitema, hvor vi i forhold til vores to tidligere tests har en naturalistisk kontekst. Desuden benyttes for første gang smartboardet, et "ægte" team, samt en virkelig arbejdskontekst. Efter tredje test talte vi kortvarigt med projektleder Morten Stahlschmidt, efter fjerde kortvarigt med et "menigt" team medlem, Elin Sjöstrand. Analyse og diskussion På grund af den data vi havde fundet ved observationen hos Arkitema d. 4. november, valgte vi at flytte scrummødet ind i et andet rum, hvor der var plads til, at alle kunne stå op, centreret om smartboardet. Alle står op til testen og der er stort engagement blandt de ansatte, her mente Morten Stahlschmidt, at visualiseringen af Scrumtavlen gør scrummødet mere pædagogisk, hvilket efter vores betragtning også giver mere commitment og respekt overfor Scrum. Efter klargørelse og opstilling, introducerer vi Scrummasteren, der er hurtig til at adaptere funktionaliteterne, hvilket begrunder at vores applikation netop lever op til et af de mest centrale behov, om applikationen er intuitiv. Dette bliver også begrundet i interview efter testen på anden dag (lydfil 4, tid: 3.30), i samme interview kommenteres det også, at vores applikation på mange måder fungerer på samme måde, som Arkitemas lav praktiske model (lydfil 4, 0:38). Man kunne frygte at smartboardet afskrækkede nogen fra at være Scrummaster, men i interviewet efter anden dags test, får vi dette afkræftet (lydfil 4, 3:53). Også Morten og Scrummasteren er positivt stemt overfor at arbejdspakkerne er blevet gjort fysiske ved hjælp post-its'ne. Scrummasteren beretter endog entusiastisk om genkendelighedens glæde, da han intuitivt prøver at krølle en af post it ne samme i håb om derved at skal den (lydfil 3, tid: 2.08). Synlige mangler i applikationen bemærkes første gang ved, at Scrummasteren mangler en søjle, hvori overordnede ansvarsområder hos de ansatte, kunne noteres. Samtidig viste det sig at søjlen Generelt, som var tiltænkt opgaver der endnu ikke var tildelt et team medlem, overvejende lå ubenyttet hen, stærkt imod vores forventninger. På fjerde test havde vi derfor ændret generelsøjlens funktion til at være holdeplads for ansvarsområderne for hvert team medlem. Vi oplevede at ændringen hurtigt faldt i deres smag (lydfil 3, tid: 11.40). I denne ændring ser vi samtidig, hvordan en lille bitte ændring kan have en kolossal effekt på brugerens brug af designet. Samtidig viser det vigtigheden af tests i naturlige omgivelser. 63 S ide

64 Vi så at vores applikation virkede for langsom til testen. Her var det to faktorer der lå til grund. For det første var båndbredden på vores medbragte mobile internetopkobling simpelthen for lav, men derforuden havde vi i god usability stil sørget for rigelig feedback til brugeren på de handlinger de foretog sig. Kombineret med internetopkoblingen voksede problemet imidlertid blot yderligere og Morten Stahlschmidt fremhævede i det efterfølgende interview, at dette applikationens største problem, og at han så dette som et væsentligt problem i forhold til at holde de ansattes interesse og opnå et flow i mødet (lydfil 4, tid: 2.20). Da vi ikke havde mulighed for at forbedre internetopkoblingen valgte vi at lade programmet opdatere sig selv sjældnere samt fjerne noget af brugerfeedbacken. Dette er et godt eksempel på hvordan brugerinddraget design kan gøre en opmærksom på uforudsete problemer. Samtidig ses styrken ved at teste over flere dage, for derved at få hurtig feedback på ens løsning. I vores design havde vi søgt at integrere en større respekt for Scrum. Dette blev forsøgt gjort igennem dels indførelse af nye Scrum begreber som 'done done' der straks blev taget i brug ( lydfil 3, tid: 2.16), samt en mere styret proces. Umiddelbart skal man som hovedregel nok være lidt forsigtig med at tvinge folk for meget til at gøre det på en specifik måde. Imidlertid giver dele af teamet udtryk for at, de faktisk velkommer en sådan styring fordi de derved undgår uoverflødige indholdssnak. (lydfil 4, tid: 0:48). Under den fjerde test overholder temaet tiden, med kun to minutters overskridelse, hvilket må siges at være rigtig godt, i forhold til en overskridelse på små 30 minutter til vores første observation. Ligeledes beder vi Morten Stahlschmidt fremstiller tre positive forbedringer som han synes vores værktøj har medført. Her fokusere er hans nummer et meget klart den øgede struktur som værktøjet skaber, synliggørelse af sammenhæng mellem Scrum og hele sprintet (planlægningstavlen) og til sidst at værktøjet giver mulighed for dokumentation, så man kan "spole tilbage i tiden". Opsummering Alle tre test former, har været med til at gøre os opmærksomme på oversete problemer og komplikationer, der er opstået undervejs i vores udvikling af værktøjet, og fordi vi løbende har udført tests har vi også løbende kunne rette værktøjet til. Via papirprototypen blev vi gjort bevidste om problemer og komplikationer, i forhold til det storyboard vi lavede, for at sammenfatte alle de ønskede funktioner. Vi blev også her gjort 64 S ide

65 opmærksomme på features, der kunne tilføjes til de enkelte dele af applikationen og vi blev tvunget til at foretage relevante valg, for at kunne komme videre. Af praktiske og tidsmæssige årsager var vi nødsaget til internt i gruppen at agere testpersoner i denne test. Det havde den fordel, at vi lynhurtigt blev opmærksomme på problematikkerne i forhold til storyboardet. At vi testede på os selv gjorde dog at vi ikke helt levede op til de overvejelser vi har gjort os i forhold til test i naturalistiske rammer. I tænke højt forsøget fik vi en guidet tur rundt i applikationen, da størstedelen af testen blev styret af testpersonens egen intuition og nysgerrighed, her blev vi i forhold til den tidligere test gjort mere opmærksomme på småfejl med overvægt i det æstetiske, der i sidste ende viste sig at være lige så vigtige i forhold til brugerens oplevelse af applikationen, som de mere grundlæggende funktionalitetsfejl vi havde beskæftiget os med indtil da. At testbruger under tænke højt forsøget selv er arkitekt, gav os et klart forspring i forhold til vores afsluttende test hos Arkitema. At der til trods for to forudgående tests, blev opfanget en mængde større problemer i vores afsluttende test, skyldes den kontekst hvori testen foregik. Vi har stræbt efter alle ex post tests skulle forgå i en naturalistisk kontekst. Vi har dog erfaret, at den naturalistiske kontekst kommer i flere grader, påvirket af eksterne parametre. Her kan i forhold til den tredje test nævnes at brugen af smartboard, samt deltagelsen af et helt team som parametre tydeligt ændrede den afsluttende tests kontekst. Ændringer som begge viste sig i evalueringerne. I forhold til smartboardet oplevede vi, at der opstod små tekniske fejl på grund af smartboardets manglende præcision og følsomhed. Hvilket vi tolker som at teknikken bag smartboardet stadig er i sin vorden. En anden kontekstmæssig erfaring var den store afstand fra testbruger til slutbrugerne. Selvom mange af de æstetiske aspekter kan sammenlignes fra tænke højt forsøgspersonen og de afsluttende testpersoner, er det en stor forskel at gå fra 1 person til 15 personer, hvilket danner en helt anden kontekst. En stor del af de opdagelser vi gjorde os til den afsluttende test var æstetiske. Vores test viste, at ved inddragelse at flere personer, blev der opdaget flere fejl og flere menneskers værdier skulle tilfredsstilles, et eksempel kan være teamets store fokusering på de elementer der var blevet fysiske. Eksempelvis efterlyste teamet til den afsluttende test, at de gerne ville have gjort slettefunktionen mere fysisk. Denne tilbagemelding fik vi ikke fra vores tænkehøjt forsøgs testperson, hvilet vi begrunder med at han sad alene foran en skærm. 65 S ide

66 De to tidlige test sammenlignet med den afsluttende test, viser tydeligt hvor meget konteksten betyder for test og evaluering Til sidst bør nævnes den væsentligste, og eneste katastrofale fejl vi oplevede under de afsluttende test, nemlig applikationens hastighed. Programmet var tungt, hvilket både evalueringer under testen og de efterfølgende interviews klart viste. Dette skyldtes, i høj grad at vi var nødsaget til at benytte en relativ langsom internetopkobling under testen. Vi vil derfor påstå at dette vil kunne afhjælpes ved en hurtigere internethastighed. 7. Designbeskrivelse 14 Frugten af vores designproces er blevet til den applikation, vi har valgt at kalde for Scrummer. I designprocessen er de overordnede funktionaliteter og behov til værktøjet blevet defineret, disse er blevet afklaret og præciseret yderligere ved hjælp af tidlige mockups, storyboards og andre designmetoder. Resultatet af dette er blevet til en sammensmeltning af praktisk erfaring (behovsanalyse) og overvejelser i forhold til at efterkomme de teoretiske rammer, Scrum opstiller. Designet er udviklet i programmeringssprogene php, java(med understøttende brug af ajax), css og html. Til at lagre informationer har vi benyttet en mysql database. En af fordelene ved disse sprog samt mysql er, at de alle er web kompatible og derfor giver den enkelte bruger adgang til Scrummer fra sin personlige computer. Den enkelte brugers adgang til systemet har imidlertid ikke været vores fokus, hvorfor vi blandt andet blot har lavet en attrap login funktion (noget vi berører senere i afsnittet). Vores fokus har været på anvendelsen af applikationen i samspil med et smartboard, hvilket derved har gjort applikationen tangible Programmets funktioner I sin grundform tager Scrummer udgangspunkt i fire grundelementer; DailyScrum, ScrumBoard, Planlægningstavle og Arkiv. På forsiden ses fire knapper, disse knapper henviser til de fire grundelementer/undersider. 14 Det udviklede design ligger til afprøvning på bemærk dog at systemet er optimeret til Firefox. Der er ikke brug for login. 66 S ide

67 Grundlæggende er Scrummer bygget op om muligheden til at oprette arbejdsopgaver, i arkitektbranchen kaldet arbejdspakker, og derefter uddelegere dem til de personer i projektteamet, der er ansvarlig for en given opgave. Pointen er, at man til en hver tid kan flytte, slette eller oprette nye arbejdspakker. Visuelt ser det således ud; Figur 14: Screenshot af ScrumBoard En arbejdspakke symboliseres ved gule firkanter ('post-it' notes). Når en arbejdspakke oprettes, hvilket gøres ved at klikke og trække musen nedad (på smartboardet gøres dette med hånden), er der blandt andet mulighed for at tildele opgaven titel, beskrivelse, ansvarlig person og dato for oprettelse. Disse informationer gemmes i en database og vil derfor være tilgængelige på et senere tidspunkt. På denne måde skabes der historik i arbejdspakkerne. Hvis arbejdspakken flyttes til en anden ansvarlig person eller status på arbejdspakken ændres, bliver dette automatisk opdateret i databasen. På det ovenstående skærmbillede ses 6 kolonner, den første kolonne angiver navn på de ansatte, resten af kolonnerne beskriver en given arbejdspakkes status. Samlet dækker de fire isblå kolonner og den ene sorte kolonne over en tidsperiode på en uge. Når en uge er omme, bliver de arbejdspakker, der ligger i kolonnen Done Done overført til Arkiv (forklaring af dette følger senere i afsnittet) og samtidig overføres nye arbejdspakker fra Planlægningstavlen til både ScrumBoard og DailyScrum. Disse to undersider, Scrumboard og DailyScrum, viser de samme arbejdspakker for den givne uge, dog adskiller DailyScrum sig ved at have ekstra funktioner. 67 S ide

68 Ideen med at have to så umiddelbart ens undersider er, at de hver især er relevante i en given situation. ScrumBoard er tænkt som et redskab, hvor brugeren til en hver tid kan tjekke status for sine arbejdspakker, hvor DailyScrum kun skal aktiveres i forbindelse med det daglige Scrummøde (deraf DailyScrum). Nedenstående ses et skærmbillede af DailyScrum. Figur 15 På denne side er det muligt at gennemgå hver enkelt medarbejders arbejdspakker På Planlægningstavlen er princippet det samme som ved DailyScrum og ScrumBoard, dog adskiller Planlægningstavlen sig ved, at denne varetager den planlægning, der går mere end en uge frem i tiden. På Planlægningstavlen er det muligt at plotte arbejdspakker ind, der ligger ude i fremtiden, disse opgaver placeres i den kolonne, der hedder Kommende. Når ugen ankommer, hvor den aktuelle opgave skal eksekveres, vil opgaven automatisk blive lagt ind på den aktuelle uges ScrumBoard og DailyScrum. Denne funktion er ikke blevet implementeret, ligesom Planlægningstavlen kun delvist er blevet implementeret. Arkiv funktionen er heller ikke blevet implementeret, vi vil her alligevel præsentere de tanker vi har gjort os om arkivets funktioner. I arkivet skal det være muligt at søge efter færdiggjorte arbejdspakker. Dette er ikke så kompliceret, da alle arbejdspakker ligger i applikationens database, eksempelvis kan der søges på information om: dato for færdiggørelse, den ansvarlige person, titel eller beskrivelse af arbejdspakken. Af tidsmæssige årsager er dette dog ikke blevet implementeret. 68 S ide

Kvalitetssikring og agile udvikling

Kvalitetssikring og agile udvikling Kvalitetssikring og agile udvikling Gæsteforelæsning for dsoftark-e10 på Århus Universitet Dagsorden Hvem er jeg og hvad er min baggrund i test og agile? Hvad kan I forvente? Agile og scrum Kvalitetssikring

Læs mere

Projektarbejde med scrum- metoden

Projektarbejde med scrum- metoden Projektarbejde med scrum- metoden Indhold Indhold... 1 1 Indledning... 2 2 Roller og terminologi i scrum... 3 Opgavestilleren... 3 Scrum Masteren... 3 Projektgruppen... 3 Sprint... 3 3 Møder... 3 Planlægningsmødet...

Læs mere

PRODUKTIONSSTYRING OG -PLANLÆGNING

PRODUKTIONSSTYRING OG -PLANLÆGNING PRODUKTIONSSTYRING OG -PLANLÆGNING Introduktion Er det egentlig præcist at tale om produktion når temaet er spiludvikling? For produktion dufter jo af faste procedurer, kendte milepæle, og definerede krav

Læs mere

IT-Universitetet, Projekt- og Programledelse November 2013 AGIL PROGRAMLEDELSE 13-11-2013 1

IT-Universitetet, Projekt- og Programledelse November 2013 AGIL PROGRAMLEDELSE 13-11-2013 1 IT-Universitetet, Projekt- og Programledelse November 2013 AGIL PROGRAMLEDELSE 1 AGENDA Hvem snakker? De betydende faktorer Agil forretningsudvikling D60 leverancemodel - Bedrock Opsamling og? 2 Hvem snakker?

Læs mere

Det vigtigste først! Dette er måske den vigtigste bog der nogensinde er skrevet om agile vs. vandfald. Muligvis fordi det vel stadig er den eneste

Det vigtigste først! Dette er måske den vigtigste bog der nogensinde er skrevet om agile vs. vandfald. Muligvis fordi det vel stadig er den eneste WTF? Thomas Schou-Moldt, Miracle A/S (siden 2008) Arkitekt, udvikler, teknisk projektleder, mv. Indtil videre afsonet lidt over 20 år i branchen, ingen udsigt til prøveløsladelse tsm@miracleas.dk, 5374

Læs mere

Forberedelse. Forberedelse. Forberedelse

Forberedelse. Forberedelse. Forberedelse Formidlingsopgave AT er i høj grad en formidlingsopgave. I mange tilfælde vil du vide mere om emnet end din lærer og din censor. Dæng dem til med fakta! Det betyder at du skal formidle den viden som du

Læs mere

Bierhverv Ekstern Lektor på Institut for Ledelse. Uddannelse Cand. Oecon. Master i Organisationspsykologi PRINCE 2, Scrum-Master, Pædagogikum, etc.

Bierhverv Ekstern Lektor på Institut for Ledelse. Uddannelse Cand. Oecon. Master i Organisationspsykologi PRINCE 2, Scrum-Master, Pædagogikum, etc. Erfaring Direktør & konsulent Rosenmeiers Konsulenthus ApS Direktør ved Marselisborg Uddannelse & Management Business Manager ved ATTRACTOR Rambøll Management Udviklingschef ved ATTRACTOR Organisations

Læs mere

Ledelsesevaluering. Formål med afsæt i ledelsespolitik og ledelsesværdier. Inspiration til forberedelse og gennemførelse

Ledelsesevaluering. Formål med afsæt i ledelsespolitik og ledelsesværdier. Inspiration til forberedelse og gennemførelse Ledelsesevaluering Inspiration til forberedelse og gennemførelse At gennemføre en ledelsesevaluering kræver grundig forberedelse for at give et godt resultat. Her finder I inspiration og gode råd til at

Læs mere

3.g elevernes tidsplan for eksamensforløbet i AT 2015

3.g elevernes tidsplan for eksamensforløbet i AT 2015 Mandag d. 26.1.15 i 4. modul Mandag d. 2.2.15 i 1. og 2. modul 3.g elevernes tidsplan for eksamensforløbet i AT 2015 AT emnet offentliggøres kl.13.30. Klasserne er fordelt 4 steder se fordeling i Lectio:

Læs mere

Matematik i AT (til elever)

Matematik i AT (til elever) 1 Matematik i AT (til elever) Matematik i AT (til elever) INDHOLD 1. MATEMATIK I AT 2 2. METODER I MATEMATIK OG MATEMATIKKENS VIDENSKABSTEORI 2 3. AFSLUTTENDE AT-EKSAMEN 3 4. SYNOPSIS MED MATEMATIK 4 5.

Læs mere

Objektorienterede metoder

Objektorienterede metoder Objektorienterede metoder Gang 12. Kvalitet i større systemer Evt.: Ekstremprogrammering (XP) Dette materiale er under Åben Dokumentlicens, se http://www.sslug.dk/linuxbog/licens.html projektopgaven i

Læs mere

Tips og vejledning vedrørende den tredelte prøve i AT, Nakskov Gymnasium og HF

Tips og vejledning vedrørende den tredelte prøve i AT, Nakskov Gymnasium og HF Tips og vejledning vedrørende den tredelte prøve i AT, Nakskov Gymnasium og HF Den afsluttende prøve i AT består af tre dele, synopsen, det mundtlige elevoplæg og dialogen med eksaminator og censor. De

Læs mere

LEAN. i byggeriet. lean & last planner _ Perspektiver på byggeriets problematikker _ MAGASIN BENSPÆND _ s. 35

LEAN. i byggeriet. lean & last planner _ Perspektiver på byggeriets problematikker _ MAGASIN BENSPÆND _ s. 35 lean & last planner _ Perspektiver på byggeriets problematikker _ MAGASIN BENSPÆND _ s. 35 LEAN i byggeriet INTERVIEW med Ph. D. Kenneth Brinch Jensen, Center for ledelse i byggeriet / CBS I byggeprojekter

Læs mere

SYNOPSIS 1. SEMESTER 2013 E-CONCEPT DEVELOPMENT

SYNOPSIS 1. SEMESTER 2013 E-CONCEPT DEVELOPMENT SYNOPSIS E-CONCEPT DEVELOPMENT INDHOLD 1. JONAS KROGSLUND HVEM ER JEG?... Side 3 2. PRÆSENTATION & MOTIVATION... Side 3 3. FAGLIGE UDFORDRINGER & PROBLEMER... Side 4 3.1 SCRUM...... Side 4 3.2 KRAVSPECOFIKATION...

Læs mere

Cindie Mortensen, Merete Koudahl, Pernille Tramp Webdesign, gruppeprojekt exercise 7. Menu A/S

Cindie Mortensen, Merete Koudahl, Pernille Tramp Webdesign, gruppeprojekt exercise 7. Menu A/S Menu A/S Problemfelt MENU A/S (MENU) er en dansk design virksomhed og producent. MENU har specialiseret sig indenfor skandinavisk design samt deres evige stræben efter at lave noget originalt. De repræsenterer

Læs mere

INTERAKTIONSDESIGN PROCESSEN (KAP 9), REPETITION, KÅRING AF ÅRETS BEDSTE MUSIKVIDEO OG PROJETK

INTERAKTIONSDESIGN PROCESSEN (KAP 9), REPETITION, KÅRING AF ÅRETS BEDSTE MUSIKVIDEO OG PROJETK INTERAKTIONSDESIGN PROCESSEN (KAP 9), REPETITION, KÅRING AF ÅRETS BEDSTE MUSIKVIDEO OG PROJETK Marianne Graves Petersen Associate Professor Computer Science Dept, University of Aarhus Center for Interactive

Læs mere

Accelerate Agil implementering fra EG NeoProcess

Accelerate Agil implementering fra EG NeoProcess Accelerate Prioritise Sprint Accelerate Agil implementering fra EG NeoProcess EG NeoProcess www.eg-neoprocess.dk Accelerate den agile implementering Verden og hverdagen er kompleks og i konstant forandring

Læs mere

Ny Nordisk Skole. Inspiration til arbejdet med at følge jeres forandringer

Ny Nordisk Skole. Inspiration til arbejdet med at følge jeres forandringer Ny Nordisk Skole Inspiration til arbejdet med at følge jeres forandringer Hvorfor følge forandringerne i jeres pædagogiske praksis? 3 Undersøgelse af børns og unges perspektiver 4 Observationer af den

Læs mere

Forberedelse. Forberedelse. Forberedelse

Forberedelse. Forberedelse. Forberedelse Formidlingsopgave AT er i høj grad en formidlingsopgave. I mange tilfælde vil du vide mere om emnet end din lærer og din censor. Dæng dem til med fakta. Det betyder at du skal formidle den viden som du

Læs mere

Diplomuddannelsen i ledelse. Dele af litteraturen kan være på engelsk eller de nordiske sprog

Diplomuddannelsen i ledelse. Dele af litteraturen kan være på engelsk eller de nordiske sprog AU HERNING BUSINESS AND SOCIAL SCIENCES Aarhus Universitet Fagmodulets navn Ledelse og coaching Udbydende udd.retning samt kursuskode Diplomuddannelsen i ledelse Uddannelsen er en 2-årig erhvervsrettet

Læs mere

Dynamisk hverdag Dynamiske processer

Dynamisk hverdag Dynamiske processer Dynamisk hverdag Dynamiske processer Verden og hverdagen er kompleks og i konstant forandring - og derfor skal den måde vi arbejder med projekter og implementering være enkel og forandringsparat. Agil

Læs mere

INDHOLDSFORTEGNELSE. Forord... 9

INDHOLDSFORTEGNELSE. Forord... 9 INDHOLDSFORTEGNELSE Forord... 9 Kapitel 1 Projektkompetencer... 11 Hvorfor projektkompetencer?... 11 Projektformens udbredelse... 14 Projektorganiseringens arbejdsmiljø... 19 Projektfeltets teorier...

Læs mere

INDHOLDSFORTEGNELSE FORORD... 9

INDHOLDSFORTEGNELSE FORORD... 9 INDHOLDSFORTEGNELSE FORORD... 9 KAPITEL 1 PROJEKTKOMPETENCER.... 11 Hvorfor projektkompetencer?.... 11 Projektformens udbredelse... 14 Projektorganiseringens arbejdsmiljø... 19 Projektfeltets teorier...

Læs mere

leverer forventet udbytte Kun 10% af strategiske projekter

leverer forventet udbytte Kun 10% af strategiske projekter leverer forventet udbytte Kun 10% af strategiske projekter Hvem er Crevato Crevato er et professionelt konsulenthus der bistår danske og internationale virksomheder i forbindelse med: Strategi Portefølje

Læs mere

Delaflevering FUA.4 Betina Korsbro, Mi Louise Hansen, Jesper Led Lauridsen og Knud Back

Delaflevering FUA.4 Betina Korsbro, Mi Louise Hansen, Jesper Led Lauridsen og Knud Back Delaflevering FUA.4 Betina Korsbro, Mi Louise Hansen, Jesper Led Lauridsen og Knud Back 1 Indhold 1.1 Generelt i forhold til projektet 1.1.1 Problemformulering Kalundborg kommune har gennem de senere år

Læs mere

Ud af krisen. Software på tværs, 15. juni 2009

Ud af krisen. Software på tværs, 15. juni 2009 Ud af krisen Software på tværs, 15. juni 2009 Om Ative Agile udvikling og rådgivning Klassisk udviklingsmodel Krav Design Ændrer sig Implementering Tager for lang tid Springes over Mareridt Test Deployment

Læs mere

Indledende bemærkninger til genreoversigten

Indledende bemærkninger til genreoversigten Indledende bemærkninger til genreoversigten Følgende genreoversigt kan fungere som en tjekliste, når eleverne skal træne de skriftlige genrer til studentereksamenen i skriftlig fransk, spansk eller italiensk.

Læs mere

Manuskriptvejledning pr. 2015 Bachelorprisen

Manuskriptvejledning pr. 2015 Bachelorprisen Manuskriptvejledning pr. 2015 Bachelorprisen Fremsendelse af artikel Artikler skrevet på baggrund af bachelorprojekter, der er afleveret og bestået på det annoncerede tidspunkt, kan deltage i konkurrencen

Læs mere

BRUGSKONTEKST, BRUGERNES BEHOV OG ETABLERING AF KRAV

BRUGSKONTEKST, BRUGERNES BEHOV OG ETABLERING AF KRAV BRUGSKONTEKST, BRUGERNES BEHOV OG ETABLERING AF KRAV Marianne Graves Petersen Associate Professor Computer Science Dept, University of Aarhus Center for Interactive Spaces, mgraves@cs.au.dk Interaktionsdesign

Læs mere

Projekter skal ikke styres de skal ledes Microsoft-seminar

Projekter skal ikke styres de skal ledes Microsoft-seminar Projekter skal ikke styres de skal ledes Microsoft-seminar Frank Madsen PA Consulting Group 17. april 2007 Hvor moden er din virksomhed? Taktiske projekt gennemførelser Styret ProjektPortefølje Projektinitiering

Læs mere

Indledning. Ole Michael Spaten

Indledning. Ole Michael Spaten Indledning Under menneskets identitetsdannelse synes der at være perioder, hvor individet er særlig udfordret og fokuseret på definition og skabelse af forståelse af, hvem man er. Ungdomstiden byder på

Læs mere

Innovation i Almen Studieforberedelse 2015 Elevudgave

Innovation i Almen Studieforberedelse 2015 Elevudgave Innovation i Almen Studieforberedelse 2015 Elevudgave Udover den klassiske opgave kan der til eksamen i AT indgå en opgave med innovation. Dette dokument beskriver arbejdet med innovation i AT og indeholder:

Læs mere

PRINCE2 - et strategisk valg

PRINCE2 - et strategisk valg PRINCE2 - et strategisk valg Per Palmkvist Knudsen, IT-direktør JP/Politikens Hus Per Palmkvist Knudsen fører dig gennem en rejse af faldgruber og succeser med PRINCE2, herunder: - Hvordan organiserer

Læs mere

Scrum guiden. Den ultimative guide til Scrum: Spillets regler. Oktober 2011. Udviklet og vedligeholdt af Ken Schwaber og Jeff Sutherland

Scrum guiden. Den ultimative guide til Scrum: Spillets regler. Oktober 2011. Udviklet og vedligeholdt af Ken Schwaber og Jeff Sutherland Scrum guiden Den ultimative guide til Scrum: Spillets regler Oktober 2011 Udviklet og vedligeholdt af Ken Schwaber og Jeff Sutherland Indholdsfortegnelse Formålet med Scrum guiden... 3 Scrum overblik...

Læs mere

strategi drejer sig om at udvælge de midler, processer og de handlinger, der gør det muligt at nå det kommunikationsmæssige mål. 2

strategi drejer sig om at udvælge de midler, processer og de handlinger, der gør det muligt at nå det kommunikationsmæssige mål. 2 KOMMUNIKATIONSSTRATEGIENS TEORETISKE FUNDAMENT I den litteratur, jeg har haft adgang til under tilblivelsen af denne publikation, har jeg ikke fundet nogen entydig definition på, hvad en kommunikationsstrategi

Læs mere

Metoder og erkendelsesteori

Metoder og erkendelsesteori Metoder og erkendelsesteori Af Ole Bjerg Inden for folkesundhedsvidenskabelig forskning finder vi to forskellige metodiske tilgange: det kvantitative og det kvalitative. Ser vi på disse, kan vi konstatere

Læs mere

It-håndbogen. Uddrag af artikel trykt i It-håndbogen. Gengivelse af denne artikel eller dele heraf er ikke tilladt ifølge dansk lov om ophavsret.

It-håndbogen. Uddrag af artikel trykt i It-håndbogen. Gengivelse af denne artikel eller dele heraf er ikke tilladt ifølge dansk lov om ophavsret. It-håndbogen Uddrag af artikel trykt i It-håndbogen. Gengivelse af denne artikel eller dele heraf er ikke tilladt ifølge dansk lov om ophavsret. Børsen Ledelseshåndbøger er Danmarks største og stærkeste

Læs mere

Honey og Munfords læringsstile med udgangspunkt i Kolbs læringsteori

Honey og Munfords læringsstile med udgangspunkt i Kolbs læringsteori Honey og Munfords læringsstile med udgangspunkt i Kolbs læringsteori Læringscyklus Kolbs model tager udgangspunkt i, at vi lærer af de erfaringer, vi gør os. Erfaringen er altså udgangspunktet, for det

Læs mere

At sætte bevægelse i en organisation. - 3 vektorer, der gør en forskel

At sætte bevægelse i en organisation. - 3 vektorer, der gør en forskel At sætte bevægelse i en organisation - 3 vektorer, der gør en forskel Af Christoffer Rude, Arbejdstilsynet juni 2009 Kan systemteori levere praktiske og konstruktive værktøjer til det komplekse kommunikationsarbejde?

Læs mere

Modulbeskrivelse. Modul 14. Bachelorprojekt. Professionsbachelor i sygepleje

Modulbeskrivelse. Modul 14. Bachelorprojekt. Professionsbachelor i sygepleje Sygeplejerskeuddannelsen UCSJ Modulbeskrivelse Modul 14 Bachelorprojekt Professionsbachelor i sygepleje Indholdsfortegnelse Introduktion til modul 14 beskrivelsen... 3 Modul 14 - Bachelorprojekt... 3 Studieaktivitetsmodel

Læs mere

Forskellige projekttyper, undersøgelsesmetoder og faser i projektet

Forskellige projekttyper, undersøgelsesmetoder og faser i projektet Forskellige projekttyper, undersøgelsesmetoder og faser i projektet Birgit Henriksen, Lektor Institut for Engelsk, Germansk og Romansk, KU Gymnasieprojektet, Middelfart seminaret 14. september Metode sammenholdt

Læs mere

Uge 5.3: (Search,) Select & implement and development methods

Uge 5.3: (Search,) Select & implement and development methods Innovationsprocesser Uge 5.3: (Search,) Select & implement and development methods A A R H U S U N I V E R S I T E T Department of Computer Science 1 Innovation & ICT development *** Innovation *** * ***

Læs mere

4. Hvordan er du primært involveret i projekter? Er det som:

4. Hvordan er du primært involveret i projekter? Er det som: Mannaz undersøgelse 2011 Rapporten er udarbejdet på baggrund af undersøgelsen gennemført i juni 2011 med svar fra 672 respondenter. Formålet med rapporten er at tage temperaturen på ProjektDanmark og afdække

Læs mere

Det erhvervsrelaterede projekt 7. semester. Projekt plan

Det erhvervsrelaterede projekt 7. semester. Projekt plan Det erhvervsrelaterede projekt 7. semester Projekt plan Titel på projekt: TAKSONOM: PETER KRISTIANSENS ARKIV (SKRIVES MED BLOKBOGSTAVER) Projektsted: LARM AUDIO RESEARCH ARCHIVE (SKRIVES MED BLOKBOGSTAVER)

Læs mere

Programmering C Eksamensprojekt. Lavet af Suayb Köse & Nikolaj Egholk Jakobsen

Programmering C Eksamensprojekt. Lavet af Suayb Köse & Nikolaj Egholk Jakobsen Programmering C Eksamensprojekt Lavet af Suayb Köse & Nikolaj Egholk Jakobsen Indledning Analyse Læring er en svær størrelse. Der er hele tiden fokus fra politikerne på, hvordan de danske skoleelever kan

Læs mere

BackEnd Programmering PHP

BackEnd Programmering PHP 17708 08/ 02/ 2013 BackEnd Programmering PHP Prototype (CMS system) 371615m02dka.sub.ots.dk/historyspot eller linket CMS system på: qrguide.mmd.eal.dk Login CMS Username: admin Password: 1234 Source kode

Læs mere

Helhedsorienteret Projektledelse

Helhedsorienteret Projektledelse Helhedsorienteret Projektledelse I århundreder har vi spillet ludo og dygtiggøre os i spillet. Moderne ledelsesudvikling - dans på bordene Gode ledere tør og har evnerne til at sætte sig mål, som andre

Læs mere

DGI Leder- og Foreningsudvikling

DGI Leder- og Foreningsudvikling Undervisningsplatform for Fremtidens Idrætsleder 2014 2016 Formål for Fremtidens Idrætsleder Fremtidens Idrætsleder og det samlede højskoleophold har til hensigt: At skabe potentielle unge idræts-/foreningsledere

Læs mere

Lean Construction-DK s. Guide til bedre planlægning med Last Planner System

Lean Construction-DK s. Guide til bedre planlægning med Last Planner System Lean Construction-DK s Guide til bedre planlægning med Last Planner System Introduktion Last Planner System er et værktøj i Lean Construction udviklet specielt til byggeriet og med hensyn til byggeriets

Læs mere

fra udvikler til leder med Pomodoro-teknikken Troels Richter 2009

fra udvikler til leder med Pomodoro-teknikken Troels Richter 2009 fra udvikler til leder med Pomodoro-teknikken Troels Richter 2009 Baggrund Professionel software udvikler gennem 9 år Knap 2 års erfaring som SCRUM Master (projektleder) Leder for 4-7 mand gennem det seneste

Læs mere

FORRETNINGSSTRATEGI SUNDHED.DK

FORRETNINGSSTRATEGI SUNDHED.DK FORRETNINGSSTRATEGI SUNDHED.DK INDHOLD 01 Om dokumentet 3 02 Sundhed.dk s forretning 4 02.1 Mission og vision 4 02.2 Sundhed.dk s position og marked 4 02.3 Sundhed.dk s fundament og leverancer 5 02.4 Målgrupper

Læs mere

Møder til glæde og gavn i Vesthimmerlands Kommune

Møder til glæde og gavn i Vesthimmerlands Kommune Møder til glæde og gavn i Vesthimmerlands Kommune Møder til glæde og gavn? Møder, møder, møder Du kan sikkert nikke genkendende til, at en betragtelig del af din arbejdstid bruges på forskellige møder.

Læs mere

Projektorganisering side 1 IVA-materiale / Virksomhedsspil

Projektorganisering side 1 IVA-materiale / Virksomhedsspil Projektorganisering side 1 Projektorganisering Indholdsfortegnelse: 1. Hvad er et projekt?... 2 1.1 Projektbegrebet... 2 1.2 Studieprojekter og professionelle projekter... 3 2. Projektfaser... 4 2.1 Fase-begrebet...

Læs mere

At udvikle og evaluere praktisk arbejde i naturfag

At udvikle og evaluere praktisk arbejde i naturfag Kapitel 5 At udvikle og evaluere praktisk arbejde i naturfag Robin Millar Praktisk arbejde er en væsentlig del af undervisningen i naturfag. I naturfag forsøger vi at udvikle elevernes kendskab til naturen

Læs mere

Skyen der er skræddersyet til din forretning.

Skyen der er skræddersyet til din forretning. Skyen der er skræddersyet til din forretning. Dette er Microsoft Cloud. Alle virksomheder er unikke. Fra sundhedsvæsen til detail, produktion eller finans der er ikke to virksomheder, der opererer på samme

Læs mere

VSA. Hvordan skaber vi et overblik over produktionen, så vi kan skabe forbedringer for hele værdikæden

VSA. Hvordan skaber vi et overblik over produktionen, så vi kan skabe forbedringer for hele værdikæden VSA Hvordan skaber vi et overblik over produktionen, så vi kan skabe forbedringer for hele værdikæden 2013 Lean Akademiet - Danmark Hvordan skaber vi et overblik over produktionen, så vi kan skabe forbedringer

Læs mere

LEDELSE Læseplan. Underviser: Kristian Malver, ekstern lektor, Chef for Personelstrategisektionen, Forsvarskommandoen.

LEDELSE Læseplan. Underviser: Kristian Malver, ekstern lektor, Chef for Personelstrategisektionen, Forsvarskommandoen. Syddansk Universitet Samfundsvidenskabelig Fakultet Master of Public Management Årgang 2013, 2. semester, foråret 2014 LEDELSE Læseplan 25. november 2014 Underviser: Kristian Malver, ekstern lektor, Chef

Læs mere

Hjemmestyrets bekendtgørelse nr. 2 af 9. januar 2009 om evaluering og dokumentation i folkeskolen

Hjemmestyrets bekendtgørelse nr. 2 af 9. januar 2009 om evaluering og dokumentation i folkeskolen Hjemmestyrets bekendtgørelse nr. 2 af 9. januar 2009 om evaluering og dokumentation i folkeskolen I henhold til 17, stk. 4, og 18, stk. 1-3, i landstingsforordning nr. 8 af 21. maj 2002 om folkeskolen,

Læs mere

Almen studieforberedelse

Almen studieforberedelse Almen studieforberedelse Synopsiseksamen 2014 - specielt om opgaven med innovation Thisted Gymnasium & HF-Kursus Ringvej 32, 7700 Thisted www.thisted-gymnasium.dk post@thisted-gymnasium.dk tlf. 97923488

Læs mere

Facilitering og rollen som facilitator

Facilitering og rollen som facilitator Facilitering og rollen som facilitator Fokus på facilitering og rollen som facilitator Ved møder og seminarer i et projekt sker det jævnligt, at den indholdsmæssige diskussion sluger al opmærksomhed fra

Læs mere

Hassansalem.dk/delpin User: admin Pass: admin INTERFACE DESIGN

Hassansalem.dk/delpin User: admin Pass: admin INTERFACE DESIGN Hassansalem.dk/delpin User: admin Pass: admin INTERFACE DESIGN 1/20 Indledning Dette projekt er den afsluttende del af webudvikling-studiet på Erhvervs Lillebælt 1. semester. Projektet er udarbejdet med

Læs mere

Fra At lære en håndbog i studiekompetence, Samfundslitteratur 2003. Kapitel 6, s. 75-87.

Fra At lære en håndbog i studiekompetence, Samfundslitteratur 2003. Kapitel 6, s. 75-87. Side 1 af 10 Fra At lære en håndbog i studiekompetence, Samfundslitteratur 2003. Kapitel 6, s. 75-87. At skrive At skrive er en væsentlig del af både din uddannelse og eksamen. Når du har bestået din eksamen,

Læs mere

Visual Studio Team System. Team Build en grundpille i søgen efter it-projektproduktivitet?

Visual Studio Team System. Team Build en grundpille i søgen efter it-projektproduktivitet? Visual Studio Team System Team Build en grundpille i søgen efter it-projektproduktivitet? Agenda: Introduktion Hvorfor Automatiseret Build Microsoft Team Build Rapportering/Data warehouse Commentor A/S

Læs mere

Uddannelsesplan. Pædagogisk ledelse valgmodul Diplom i ledelse

Uddannelsesplan. Pædagogisk ledelse valgmodul Diplom i ledelse Uddannelsesplan Pædagogisk ledelse valgmodul Diplom i ledelse Undervisere: Jens Andersen, psykolog, Ledelses- og organisationskonsulent, act2learn, mail: jna@ucnact2learn.dk, mobil: 72690408 Ane Davidsen,

Læs mere

Forhandlingsteknik for erfarne forhandlere

Forhandlingsteknik for erfarne forhandlere Forhandlingsteknik for erfarne forhandlere Forhandlingsteknik for erfarne forhandlere Skab resultater med større power og personlig gennemslagskraft Personlig gennemslagskraft styrker dine forhandlinger

Læs mere

Iterativ og Agil udvikling

Iterativ og Agil udvikling Iterativ og Agil udvikling 1 2 Udfordringer i hverdagen En liste over de udfordringer man står overfor ved implementering af iterativ og agil udvikling. 3 Udfordringer med Iterationer 4 Iterationer, I

Læs mere

Computeren repræsenterer en teknologi, som er tæt knyttet til den naturvidenskabelige tilgang.

Computeren repræsenterer en teknologi, som er tæt knyttet til den naturvidenskabelige tilgang. Den tekniske platform Af redaktionen Computeren repræsenterer en teknologi, som er tæt knyttet til den naturvidenskabelige tilgang. Teknologisk udvikling går således hånd i hånd med videnskabelig udvikling.

Læs mere

Diplomuddannelsen i ledelse. Dele af litteraturen kan være på engelsk eller de nordiske sprog

Diplomuddannelsen i ledelse. Dele af litteraturen kan være på engelsk eller de nordiske sprog AU HERNING BUSINESS AND SOCIAL SCIENCES Aarhus Universitet Fagmodulets navn Ledelse og coaching Udbydende udd.retning samt kursuskode Diplomuddannelsen i ledelse Uddannelsen er en 2-årig erhvervsrettet

Læs mere

Vurdering af duka PC

Vurdering af duka PC KØBENHAVNS KOMMUNE Sundheds- og Omsorgsforvaltningen Center for Sundhed Vurdering af duka PC Sundheds- og Omsorgsforvaltningen i Københavns Kommune har i regi af afdeling for Sund Vækst vurderet duka PC.

Læs mere

Dagens program. Digital formidling - med udgangspunkt i Ting. Proces og output. Projektbeskrivelserne. Walk the Talk - Formål

Dagens program. Digital formidling - med udgangspunkt i Ting. Proces og output. Projektbeskrivelserne. Walk the Talk - Formål Digital formidling - med udgangspunkt i Ting Den 22. april 2010 2. møde i det faglige udviklingsforum Dagens program Kl. 9 Velkomst og morgensang Kl. 9.15 Projekterne Kl. 10 Definition af Digital strategi

Læs mere

Vidensmedarbejdere i innovative processer

Vidensmedarbejdere i innovative processer Vidensmedarbejdere i innovative processer Vidensmedarbejdere i innovative processer af direktør og partner Jakob Rasmussen, jr@hovedkontoret.dk, HOVEDkontoret ApS 1. Indledning Fra hårdt til blødt samfund

Læs mere

a) Borger- og medarbejdernære hverdagsteknologier b) Stedfortræderteknologier c) Synkrone online læringsmiljøer

a) Borger- og medarbejdernære hverdagsteknologier b) Stedfortræderteknologier c) Synkrone online læringsmiljøer LUG: Læring Uden Grænser - nye koblinger mellem velfærdsuddannelser, virksomheder, borgere og myndigheder i Region Sjælland (LUG-projektet i daglig tale) Generelt om projektet: Projektet er et partnerskab

Læs mere

10-trins raket til logo-design

10-trins raket til logo-design 10-trins raket til logo-design Stjerne-modellen Dette notat er udarbejdet i forbindelse med foredrag og kurser som supplement til bogen Virksomhedens logo. Ideen er, at det skal fungere sammen med bogen,

Læs mere

Hvordan udarbejdes en strategi

Hvordan udarbejdes en strategi LENNART SVENSTRUP Hvordan udarbejdes en strategi LENNART@KYOEVAENGET.DK 2011 Strategi Alle kan udarbejde en strategi! MEN: For at en strategi er noget værd i praksis, skal den tage udgangspunkt i virkeligheden,

Læs mere

AT SAMTALE SIG TIL VIDEN

AT SAMTALE SIG TIL VIDEN Liv Gjems AT SAMTALE SIG TIL VIDEN SOCIOKULTURELLE TEORIER OM BØRNS LÆRING GENNEM SPROG OG SAMTALE Oversat af Mette Johnsen Indhold Forord................................................. 5 Kapitel 1 Perspektiver

Læs mere

Strategic Management of Professional Service Firms

Strategic Management of Professional Service Firms Strategic Management of Professional Service Firms Bente R. Løwendahl Strategi AALBORG UNIVERSITET Det samfundsvidenskablige fakultet HD i Organisation og Ledelse 8. semester HDO Indhold 1 Professionelle

Læs mere

Opgave, projekt, eller?

Opgave, projekt, eller? Opgave, projekt, eller? Problemstillingen Baggrunden for denne artikel er erfaringer, som jeg har gjort over en årrække i så forskelligeartede organisationer som it-virksomheder og it-afdelinger, eldistributionsselskaber

Læs mere

Almen studieforberedelse stx, juni 2013

Almen studieforberedelse stx, juni 2013 Bilag 9 Almen studieforberedelse stx, juni 2013 1. Identitet og formål 1.1. Identitet Almen studieforberedelse er et samarbejde mellem fag inden for og på tværs af det almene gymnasiums tre faglige hovedområder:

Læs mere

Manual for metoder og processer på Synscenter Refsnæs

Manual for metoder og processer på Synscenter Refsnæs 21. april 2014 Manual for metoder og processer på Synscenter Refsnæs I udviklingsprojektet Det Nye Refsnæs ( Projekt 1 ) er der udviklet en række metoder og processer, der udgør grundstenen i arbejdsmetoder

Læs mere

ÅBENT HUS ANALYSE FORÅRET 2015 ANALYSENS INDHOLD

ÅBENT HUS ANALYSE FORÅRET 2015 ANALYSENS INDHOLD ÅBENT HUS ANALYSE FORÅRET 2015 ANALYSENS INDHOLD I foråret 2015 besøgte CompanYoung tre af landets universiteters åbent hus-arrangementer. Formålet hermed var at give indblik i effekten af åbent hus og

Læs mere

Proces orientering af IT organisationer (ITIL - implementering)

Proces orientering af IT organisationer (ITIL - implementering) Proces orientering af IT organisationer (ITIL - implementering) Af Lars Zobbe Mortensen Indholdsfortegnelse 1 Indledning... 3 1.1 Hvorfor bedst practice processer (f.eks. ITIL)?... 3 2 Beslutning om forandring...

Læs mere

Forbedringspolitik. Strategi

Forbedringspolitik. Strategi Forbedringspolitik Strategi 1 2 Indhold Forord... 3 Formål... 5 Vi vil forandre for at forbedre... 6 Forbedringer tager udgangspunkt i patientforløb og resultatet for patienten... 7 Medarbejder og brugerinvolvering...

Læs mere

INTERAKTIONSDESIGN Q3 2014 DATA ANALYSE KAP. 8. MARIANNE GRAVES PETERSEN ASSOCIATE PROFESSOR AARHUS UNIVERSITY mgraves@cs.au.dk

INTERAKTIONSDESIGN Q3 2014 DATA ANALYSE KAP. 8. MARIANNE GRAVES PETERSEN ASSOCIATE PROFESSOR AARHUS UNIVERSITY mgraves@cs.au.dk INTERAKTIONSDESIGN Q3 2014 DATA ANALYSE KAP. 8 MARIANNE GRAVES PETERSEN ASSOCIATE PROFESSOR AARHUS UNIVERSITY mgraves@cs.au.dk Interaktionsdesign processen Identificer brugernes behov og etabler krav til

Læs mere

Grundlæggende metode og videnskabsteori. 5. september 2011

Grundlæggende metode og videnskabsteori. 5. september 2011 Grundlæggende metode og videnskabsteori 5. september 2011 Dagsorden Metodiske overvejelser Kvantitativ >< Kvalitativ metode Kvalitet i kvantitative undersøgelser: Validitet og reliabilitet Dataindsamling

Læs mere

EVALUERING VIA DELPHI-METODEN

EVALUERING VIA DELPHI-METODEN Evalueringsprojekt på CBS Projekt til styrkelse af CBS evalueringspraksis i relation til de pædagogiske målsætninger Det Pædagogiske Udvalg EVALUERING VIA DELPHI-METODEN Introduktion til Delphi-metoden

Læs mere

Når økonomioutsourcing er den rigtige løsning

Når økonomioutsourcing er den rigtige løsning Når økonomioutsourcing er den rigtige løsning Overvejer I at oursource hele eller dele af jeres økonomifunktion? Dette whitepaper er udarbejdet, så I har et bedre beslutningsgrundlag at handle ud fra.

Læs mere

En midlertidig organisation der etableres for at levere en eller flere leverancer til opnåelse af forandringsevne

En midlertidig organisation der etableres for at levere en eller flere leverancer til opnåelse af forandringsevne Sammenfattende definitioner Definition og beskrivelse Vision En portefølje er en samling af projekter/mer, som vurderes samlet med henblik på at optimere sammensætning og prioritering af strategiske indsatser

Læs mere

Projektlederens guide til tilfredsstillende geoinformationsprodukter

Projektlederens guide til tilfredsstillende geoinformationsprodukter Projektlederens guide til tilfredsstillende geoinformationsprodukter Projektlederens guide er udarbejdet på baggrund af projektet: MobilGIS til natur- og arealforvaltere en web-baseret prototype. Projektet

Læs mere

BUSINESS CASE: STYRKEBASERET LEDELSE

BUSINESS CASE: STYRKEBASERET LEDELSE BUSINESS CASE: STYRKEBASERET LEDELSE..og hvordan I kommer i gang Den nyeste forskning inden for organisationsudvikling og psykologi viser stærke resultater med hensyn til, hvorfor en anderledes tilgang

Læs mere

Teamets funktionalitet en kontinuerlig ledelsesmæssig udfordring

Teamets funktionalitet en kontinuerlig ledelsesmæssig udfordring Teamets funktionalitet en kontinuerlig ledelsesmæssig udfordring Vore samtaler i foråret satte fokus på din beskrivelse og vurdering af funktionen af teamarbejdet på skolen med henblik på - i spil med

Læs mere

Kommunikationsværktøj

Kommunikationsværktøj Hjælp til selvhjælp Kommunikationsværktøj Gode overvejelser til projektlederen om interessenter og kommunikation o o Tænk over projektets interessenter og over kommunikationen af jeres projekt fra start

Læs mere

IntDesign - Kap 7. Kap 1.6.1 s. 20 - Usability goals

IntDesign - Kap 7. Kap 1.6.1 s. 20 - Usability goals IntDesign - Kap 1 Kap 1.6.1 s. 20 - Usability goals Usability goals are viewed as being concerned with meeting specific usability criteria, e.g. efficiency, whereas user experience goals are largely concerned

Læs mere

Lederrunder - Tips og tricks. Guide til dig som vil gå lederrunder

Lederrunder - Tips og tricks. Guide til dig som vil gå lederrunder Lederrunder - Tips og tricks Guide til dig som vil gå lederrunder 1 Lederrunder - Derfor Lederrunder har en positiv effekt på patienten, medarbejderne får feedback på deres arbejde, og lederen får en unik

Læs mere

Studieretningsprojekter i machine learning

Studieretningsprojekter i machine learning i machine learning 1 Introduktion Machine learning (ml) er et område indenfor kunstig intelligens, der beskæftiger sig med at konstruere programmer, der kan kan lære fra data. Tanken er at give en computer

Læs mere

Personprofil og styrker

Personprofil og styrker Personprofil og styrker Et redskab til at forstå dine styrker gennem din personprofil Indhold Dette værktøj er udviklet med henblik på at skabe sammenhæng mellem de 24 karakterstyrker udviklet af The VIA

Læs mere

Skriv en artikel. Korax Kommunikation

Skriv en artikel. Korax Kommunikation Skriv en artikel Indledningen skal vække læserens interesse og få ham eller hende til at læse videre. Den skal altså have en vis appel. Undgå at skrive i kronologisk rækkefølge. Det vækker ofte større

Læs mere

Den 21. august 2014. Sags ID: SAG-2013-07271 Dok.ID: 1829028. JSP@kl.dk/hkm Direkte 3370 3252 Mobil 2947 2313

Den 21. august 2014. Sags ID: SAG-2013-07271 Dok.ID: 1829028. JSP@kl.dk/hkm Direkte 3370 3252 Mobil 2947 2313 Projektbeskrivelse: Afdække og arbejde med nye roller på biblioteksområdet. Udvikling af nye funktioner på folkebibliotekerne hvilke roller og kompetencebehov sætter det på dagsordenen Folkebibliotekerne

Læs mere

PED/15.10.2007 Auditorhåndbog for OTS Version 1

PED/15.10.2007 Auditorhåndbog for OTS Version 1 PED/15.10.2007 Auditorhåndbog for OTS Version 1 Side 1/10 Indhold 1. Forord 2. Hvad er audit? 3. Hvor ofte skal auditor gennemføre audit og med hvilken funktion? 4. Rollen som auditor 5. Planlægning Indkaldelse

Læs mere