Agil udvikling - Perspektiver for innovativ softwareudvikling

Transkript

1 Agil udvikling - Perspektiver for innovativ softwareudvikling 1 Forord Jeg vil i dette kapitel se på agil udvikling fra to vinkler. Den første vinkel er agil udvikling i sig selv. Hvad er agil udvikling? Hvordan adskiller agil udvikling sig fra traditionel plan-orienteret udvikling? Den anden vinkel er de muligheder, som agil udvikling åbner for dansk softwareudvikling. I en globaliseret verden er der grund til at se på, om agil udvikling giver nye muligheder. Det mener jeg er tilfældet, og jeg vil især i dette kapitel pege på mulighederne for at styrke det kreative og innovative element i softwareudviklingen. Jeg går ud fra, at kreativitet og innovation bliver et centralt element i den danske softwareindustris konkurrencestrategi fremover. Den første del af dette kapitel handler således om centrale principper, begreber og teknikker i agil udvikling, mens anden del er mere perspektiverende. I denne sidste del vil jeg beskrive noget af forskningen inden for software innovation i Software Innovation Research Lab (SIRL). For at gøre teksten lidt mere læselig er der ikke referencer i teksten, men sidst i kapitlet er en litteraturliste med forslag til videre læsning. 2 Centrale principper for agil udvikling 2.1 Et nyt paradigme Software Engineering blev foreslået som fag ved en konference i Man stillede sig spørgsmålet, om softwareudvikling kunne og burde udvikles til en ingeniørdisciplin, der kunne sammenlignes med industrialismens paradediscipliner - eksempelvis bygningskonstruktion og maskinkonstruktion. En disciplin hvor der ville være kendte og afprøvede metoder til at komme fra kravspecifikation til færdigt produkt. En disciplin hvor man på sikker grund kunne sige noget om projekters pris, varighed, produktivitet og kvalitet ud fra velprøvede modeler for estimering og planlægning. En disciplin, hvor projekter oftere kunne gennemføres med succes, og hvor fiaskoer ville give værdifulde bidrag til vores viden om faget, så tilsvarende fiaskoer kunne undgås fremover. I de følgende 40 år har hovedlinien i forskningen inden for faget sigtet mod at opnå dette mål. Centrale indsatsområder har med varierende grader af formalisering sigtet mod udviklingen af modeller, teknikker og metoder til understøttelse af planlægning, styring og validering, og grundantagelsen har været, at systematiske gentagelser i form af gennemprøvede rutiner og procedurer i kombination med kvantificering, automatisering og overvågning ville være den bedste strategi for at opnå høj kvalitet og gennemsigtighed i softwareudviklingens faser. Der var således tale om en disciplin, der efterhånden stod på egne fødder, rig på empirisk viden, på udviklede modeller samt sofistikerede teknikker og værktøjer. En Ivan Aaen

2 disciplin hvor lærebøgerne havde udviklet sig til digre værker på 900 sider med over 30 kapitler om de vigtigste emner inden for faget og hvor man bekymrede sig om, hvordan man skulle få plads til mere viden fra et område, der stadig udvikler sig med stormskridt. I 2004 havde faget et etableret fælles vidensgrundlag i form af Software Engineering Body of Knowledge, og der var en næsten ensstemmig tilslutning til modenhedsmodeller som den helt centrale platform for enhver softwareorganisation, der havde ambitioner om at blive bedre til sit arbejde. Tilslutningen til dette syn på faget og dets værdier var som sagt næsten enstemmig. Mange organisationer havde i årevis forgæves prøvet at leve op til forestillingerne om ideel softwareudvikling. Mange forsøg på procesforbedring slog fejl; nogle fordi processerne ikke passede til dynamiske markedsvilkår, andre fordi dygtige medarbejdere ikke fandt processerne anvendelige. Der var derfor en voksende tvivl om, hvorvidt industrialismens kongstanker om kvantificering og systematik gennem omfattende modelbaseret planlægning og gentagelse ville være lige relevante for alle organisationer. Denne tvivl gav sig udtryk i et voksende marked for metoder og teknkker, der nedtonede modelbaseret planlægning og så hvert projekt som noget unikt. Et nyt syn på softwareudvikling voksede frem med fokus på professionelle medarbejdere i etablerede teams, på interaktion med kunden, på partnerskab og på evnen til improvisation i lyset af de uundgåelige usikkerheder og foranderligheder i de fleste projekter. Udviklingen af dette nye syn foregik ikke i forskerkredse, men i konsulentverdenen, hvor nogle siden starten af 90erne havde talt for alternative letvægtsmetoder med fokus på inkrementel udvikling, på udvikling af software mere end på dokumenter og på at holde formaliseringsgraden så lav som muligt. En række af disse konsulenter formulerede i 2001 det Agile Manifest som et frontalangreb på det traditionelle paradigme for softwareudvikling: We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more. Manifestet blev vel modtaget i vide kredse og vi stod derfor med en kløft mellem det traditionelle og det agile paradigme, hvor mange af fagets traditionelle grundsætninger står for skud. 2.2 Hvordan adskiller det agile paradigme sig fra det traditionelle? Industrialismens tankegang har præget det traditionelle paradigme lige siden Således foreslog Bob Bemer det år, at man oprettede software fabrikker for at øge programmørers produktivitet gennem standardiserede værktøjer, programmeringsomgivelser, værktøjer til konfigurationsstyring og databaser med historiske data til økonomisk og ledelsesmæssig styring. Tilsvarende tankegange kan ses i en række samtidige eller senere forslag til europæiske og japanske software Ivan Aaen

3 fabrikker, komponent-fabrikker og modenhedsmodeller baseret ikke mindst på Capability Maturity Models. Fremkomsten af det agile paradigme markerer et brud med det traditionelle plandrevne paradigme til fordel for et syn på softwareudvikling præget af evolution, iteration og fleksibilitet. Agile principper er et meget stort emne, som jeg kun vil behandle overfladisk i dette kapitel. Den interesserede læser kan f.eks på Wikipedia finde en omfattende artikel om Agile Software Development. I dette afsnit vil jeg kort nævne nogle af de centrale principper, der giver nye muligheder for udvikling af software. Opgøret med den traditionelle fremgangsmåde kan siges at foregå på fire fronter: Det produktrettede, det projektrettede, det proces-rettede og det menneskerettede. Disse fire fronter vil jeg i det følgende betegne ved deres engelske navne af hensyn til den senere fremstilling i kapitlet Product Hvor det traditionelle paradigme fokuserer på at gøre fremstillingen af software forudsigelig, sigter det agile paradigme mod udvikling af nye produkter. Den leverede software er teamets produkt. Kendetegnende for produktudvikling er, at kravene til produktet er foranderlige og fordrer dynamisk tilpasning til hyppige og uforudsigelige ændringer. Et af de fire basale udsagn i det agile manifest er working software over comprehensive documentation, der sætter fokus især på produkt-siden af softwareudvikling. Under dette udsagn står bl.a. manifestets principper om at give højest prioritet til at stille kunden tilfreds gennem tidlig og kontinuerlig leverance af værdifuld software, at se fungerende software som det primære mål af fremdrift, og at se enkelhed - maksimering af det arbejde, som man ikke udfører - som essentielt. På kravsiden indebærer disse principper, at det klassiske syn på kravspecifikationen som et produkt i sig selv forsvinder. I traditionel softwareudvikling søges kravspecifikationen stabiliseret, den er grundlaget for forhandlinger, den søges gjort så komplet som muligt gennem omfattende analysemetoder til fremdragelse og systematisering af kravene, der så indbygges i kontrakter og andre aftaleforhold mellem projektets interessenter. I agil udvikling lægges der langt mindre vægt på systematisk kravstyring. Krav ses som noget, der opdages undervejs i projektet. Hyppige leverancer opfattes derfor som en lejlighed for kunden til at opdage nye behov gennem praktisk afprøvning af den nyeste udgave af produktet. Krav repræsenteres i det hele taget mest af personer og i mindre grad i dokumenter. Begreber som Whole Team og Onsite Customer er oplagte eksempler på dette nye syn på repræsentationen af krav. Der er fremkommet teknikker til agil analyse, men disse er karakteriserede ved at være letvægtsmetoder. Et kendt eksempel er Martin Fowlers Analysis Patterns. På designsiden er der traditionelt fokus på at fastlægge arkitekturen i produktet så tilpas tidligt, at der ikke bliver behov for at ændre væsentligt i den senere i projektet. Ændringer i den overordnede arkitektur antages at være omkostningstung og en trussel mod projektets tidsplan, og derfor skal de elementer, der er svære at ændre på undervejs, være rigtige fra starten af. I agil udvikling er man enig i arkitekturens store betydning og man anbefaler, at arkitektur diskuteres tidligt i projektet. Samtidigt er man imidlertid optaget af at Ivan Aaen

4 holde designet emergent -at holde det åbent og plastisk - så der bevares størst mulige arkitektoniske frihedsgrader længst muligt i projektet. Mary Poppendieck anbefaler således, at man undgår design-beslutninger, der ikke kan omgøres senere, og at man derfor udskyder beslutninger til så sent som muligt. Fowler foreslår, at man skifter fra et arkitektursyn, hvor arkitektens opgave er at ramme rigtigt med de ting, der er svære at lave om, til et arkitektursyn, hvor arkitektens fornemste opgave er at eliminere arkitektur-elementer, der er svære at ændre på senere. Fowler bliver derved fortaler for en slags anti-arkitektur. Fowlers arbejde inden for refaktorering af software - det at ændre i eksisterende kode for at forbedre dens struktur uden at ændre funktionalitet - kan også ses som et bidrag til emergent design. På test-siden er der traditionelt fokus på verifikation og validering. Verifikation sigter mod at sikre overensstemmelse mellem kravspecifikation, analysedokumenter, overordnet design og detaljeret design på den ene side og produktet selv på den anden. Validering sigter mod at sikre, at det endelige produkt modsvarer behovene på anvendelsessiden. Verifikation får ofte en destruktiv karakter, idet den oftest retter sig mod at påvise afvigelser fra specifikationen. Verifikation er derfor baseret på dokumenter og modeller, mens validering er baseret på afprøvning og evaluering. I agil udvikling anvendes test aktivt i udviklingsarbejdet. Ofte anbefales det at udvikle testcases forud for kodning som led i afklaringen af kravene til koden og dermed som drivmekanisme i designarbejdet. Aftestning er derfor ikke baseret på dokumenter og modeller, men på udviklerens designovervejelser på grundlag af brugerens udtrykte behov og brugerens egen formulering af acceptkrav. Unit-tests er således udviklerens mikro-kravspecifikation til den metode eller klasse, som skal skrives. Udarbejdelsen af testen er et redskab til afklaring af formålet med koden med henblik på at skrive koden så minimalistisk og enkelt, som muligt. Testene afvikles automatisk før, under og efter koden skrives, og succesfulde testcases afspejler fremskridtene i programmeringsarbejdet. Under refaktorering og funktionelle ændringer lokalt eller i andre dele af produktet tjener den automatiske eksekvering af testene til at sikre mod sideeffekter og bliver dermed reelt til regressions-tests. Automatiske tests er således også et redskab til at sikre robusthed i koden under forandring, og er et vitalt led i bestræbelserne på at holde designet åbent og plastisk - emergent - længst muligt. Acceptance-tests er kunderepræsentantens ansvar med støtte fra udviklerne. Acceptance-test søges også eksekveret automatisk ved anvendelse af rammeværk som eksempelvis Ward Cunninghams FIT-værktøj med samme formål: at hjælpe med at sikre at systemets funktionaliteter bevares under forandring, så sideeffekter identificeres og elimineres så tidligt som muligt. Automatiseringen sikrer systematik i aftestningen, samtidigt med at den beskytter udviklere og kunderepræsentanter mod at gentage de samme tests igen og igen. Automatiseringen af acceptance-test er videre med til at sikre, at acceptance-testene faktisk er testbare og dermed også udtrykt klart og utvetydigt over for udviklerne. Der er i de senere år fremvokset en erkendelse af, at det ofte er utilstrækkeligt at overlade aftestningen af kritisk software til udviklere og kunderepræsentanter. Derfor er der fremkommet forslag til og studier af, hvordan specialiserede aftestere kan indgå i agile projekter og samtidigt bevare projekternes produktfokus, hastighed og fleksibilitet. Egentlige aftestere sigter mod test på tværs af funktionaliteter og f.eks. på korrekthed, stabilitet og performance i storskala-projekter. Erfaringer fra praktiske projekter tyder på, at testere og testarbejde med fordel kan integreres i udviklingsteamet istedet for at holdes adskilt Project Ivan Aaen

5 Traditionelt er styring af software-projekter et af de vigtigste og mest omfattende områder inden for software engineering. Til dette område hører ikke mindst projektopstart og fastlæggelse af projektets scope, projektplanlægning, projektgennemførelse, samt review og evaluering. Det agile paradigme indebærer et skift væk fra styring på omkostninger og tidsplan til levering af forretningsværdi gennem projektet. Det antages, at udvikling af nye produkter ikke kan estimeres pålideligt på pris og varighed i starten af et projekt, men at man kan udarbejde bedre og bedre estimater efterhånden som projektet skrider frem. Når ikke man kan identificere og skemalægge detaljerede aktiviteter ved projektets begyndelse, så må man i stedet bruge adaptiv planlægning med indbyggede feed-back sløjfer. Det agile manifests responding to change over following a plan, sætter især fokus på projekt-siden af softwareudvikling. Under dette udsagn står bl.a. manifestets principper om at levere fungerende software hyppigt, hellere med ugers end med måneders intervaller, at have et dagligt samarbejde mellem kunderepræsentanter og udviklere i hele projektet, at basere projektet på motiverede individer, der får de omgivelser, og den støtte, de har brug for; have tillid til, at de løser opgaven, og at den mest effektive måde at overføre informationer til og i et udviklingsteam er ansigt-til-ansigt kommunikation. Traditionel projektopstart og fastlæggelse af projektets scope omfatter forhandling og fastlæggelse af krav, feasibility-studie og vurdering og revision af kravene undervejs i projektet. Agil udvikling forudsætter ikke, at kravene i store træk er kendte af udviklerne ved projektets start. Kravene er kundens ansvar, men gennem prioritering af projektets vigtigste og/eller mest risikobetonede dele først i projektet antages det, at der tidligt i projektet opnås en ret stabil forståelse af projektets resulater hos kunden og i teamet. Projektplanlægning omfatter traditionelt fastlæggelse af leverancer, estimering af arbejdsmængde, tidsplan og omkostninger, allokering af ressourcer, risikoledelse, kvalitetsledelse og planlægning. Alt dette søges gennemført med inddragelse af flest mulige informationer, så man kan planlægge projektet på detaljeret niveau og tidligt forudsige pris og varighed af projektet. Den traditionelle projektleders arbejde går således bl.a. ud på at opstille lister med opgaver, udarbejde estimater for hver opgave, opstille et Gantt-kort med start- og slutdato og vedligeholde dette Gantt-kort igennem hele projektet. Meget af det traditionelle planlægningsarbejde handler om aktiviteter langt mere end om de produkter, der er projektets mål. Agil udvikling baseres i vid udstrækning på rullende planlægning, idet projekterne gennemføres inkrementelt med hver iteration opbygget som et stort set komplet projekt fra opstilling af krav til levering af løsning inden for et forløb på normalt 4 uger. På den korte bane planlægges relativt detaljeret, mens planlægningen på den lange bane er ganske overordnet. I løbet af de første 2-4 iterationer opnås en fornemmelse af projektets samlede varighed og dermed også af den forventede pris baseret på grove produktivitetsmål for det aktuelle projekt. Risici håndteres primært gennem forebyggelse og eksperimenter, idet meget risikofyldte projektelementer angribes tidligt i projektet. Kvalitetssikring håndteres primært gennem kulturelle virkemidler kombineret med refaktorering, kodefællesskab, parprogrammering, Ivan Aaen

6 afprøvning og løbende aftestning. Når projektet er planlagt er næste opgave traditionelt projektgennemførelse hvor planerne implementeres. I den forbindelse skal der tages hånd om kontraktledelse af leverandører til projektet, måleprogrammer skal implementeres i projektet, projektet skal overvåges med henblik på planoverholdelse og interventioner skal formodentligt foretages. Endelig skal projektets status rapporteres til projektets interessenter. I agil udvikling varetages projektgennemførelse i høj grad af det selvorganiserende team. Der holdes daglige statusmøder af meget kort varighed, hvor den forrige dags resultater opregnes, problemer for indeværende dag diskuteres og fjernes, og forventningerne til dagens resultater opstilles. I tilfælde af større projekter organiseres disse som et antal agile teams, der arbejder så selvstændigt som muligt og indbyrdes koordinerer via hyppige (daglige eller flere gange ugentlige) møder, hvor udpegede medlemmer fra hvert team deltager. Måleprogrammer er simple og sigter mod at belyse specifikke og aktuelle forhold, og projektets status er synlig for alle i og uden for teamet i kraft af leverancer samt visualisering af opgaverne som henholdsvis afsluttede, igang eller endnu ikke påbegyndte. Det traditionelle projekt er opbygget med milepæle, hvor projektets status reviewes og evalueres. Herunder vurderes det, i hvilken grad kravene til projektet er opfyldte, og om projektets performance er tilfredsstillende og om der er behov for tiltag med hensyn til arbejdsprocesser, metoder, værktøjer og personale. I agil udvikling varetages disse hensyn i det væsentlige af de tiltag, der blev nævnt under projektplanlægning og -gennemførelse Process Process management står helt centralt i det traditionelle paradigme med fokus på definering, planlægning, undervisning, udbredelse, implementering, overvågning, kontrol, vurdering, måling og forbedring af processer. I det traditionelle paradigme er processer relativt statiske i håb om, at organisationen projekt for projekt får perfektioneret udførelsen af dem, samtidigt med at de i små skridt tunes til de aktuelle krav. Processerne er udførligt definerede, så nye og gamle medarbejdere kan konsultere dem i tvivlstilfælde. Traditionelt er der således stor fokus på proces-siden - som regel under overskriften procesforbedring. Man kan dele procesforbedring op i flere aktiviteter: Procesudvikling, proces-definering, proces-vurdering samt proces- og produkt-måling. Proces-udvikling handler om at indføre eller modificere arbejdsprocesser. Til dette formål oprettes oftest specialistfunktioner, der rådgiver projekter og udviklere med henblik på at udviklede ensartede og velfungerende processer på organisationsniveau. For at opnå dette opsamles der erfaringer fra organisationen, og der designes nye proceselementer til udrulning i organisationen. Proces-definering sigter mod modellering af processen i form af procedurer, retningslinier eller standarder. Formålet med defineringen er at sikre forståelse og efterfølgelse gennem klar kommunikation til medarbejderne, at give et udgangspunkt for proces-vurdering og videre procesforbedring samt fastlægge hensigtsmæssige former for værktøjsunderstøttelse. Proces-vurdering står i centrum for det traditionelle proces-syn. Softwareprocessen vurderes på et veldefineret metodegrundlag og holdes op mod en generel standard som f.eks. CMMI. Afvigelser fra denne standard er det væsentligste bidrag til fastlæggelse af mål for den videre procesforbedring. En veldefineret opfyldelse af standarden er betingelsen for certificering af processen. Ivan Aaen

7 Endelig gennemføres et antal proces- og produkt-målinger, der sigter mod at belyse i hvilken udstrækning indførelsen eller forandringen af processer er gennemført og give en belysning af konsekvenserne heraf gennem mål fra processen eller fra de udviklede produkter. Når det agile manifest sætter individuals and interactions over processes and tools, så er det et opgør med det traditionelle paradigmes antagelse om, at god softwareudvikling baseres på standardiserede udviklingsprocesser. Agil softwareudvikling lægger således vægten på kompetence, refleksion og produktdesign som udtrykt i disse principper: Konstant fokus på teknisk excellens og godt design forbedrer agiliteten Teamet reflekterer regelmæssigt over, hvordan det kan blive mere effektivt, og justerer og tilpasser sin adfærd derefter. I det agile paradigme er processer ikke produkter - genstande - i sig selv, men aktiviteter - noget man gør. Processer er ikke stabile strukturer, men udvikler sig dynamisk med de erfaringer, som teamet gør sig og opfordrer til improvisation. Teamet ejer og udvikler selv sine processer, hvor det traditionelle paradigme oftest har specialister, der udvikler og vedligeholder processer til organisationen. I det agile paradigme er der ikke specialiserede proces-designere, der fastlægger hvordan andre skal arbejde. Processerne er ikke definerede i det agile paradigme, men overleveres gennem teamets traditioner, gensidig læring og diskussioner People People-perspektivet handler om projekters interessenter. Blandt disse er ledelsen i udviklingsorganisationen, projektledere, udviklere, ledere i brugerorganisationen, superbrugere, slutbrugere, sælgere og marketingfolk. I dette afsnit vil jeg dog især diskutere udviklingsorganisationen og ikke mindst udviklingsteamet. Fokus i dette perspektiv er på organisatorisk, teammæssig og personlig udvikling, på kommunikation og på samarbejde. Ved etableringen og udviklingen af det traditionelle paradigme var de fleste programmører lavtuddannede - ofte selvlærte. Der var stor mangel på kvalificerede udviklere, og man søgte derfor at håndtere dette problem med organisatoriske og ledelsesmæssige midler. Standardisering af opgaver og arbejdsprocesser gav gode muligheder for hurtig oplæring af nyansatte og for udveksling af medarbejdere mellem projekter efter behov. På organisationsniveau har man derfor traditionelt sigtet mod overvejende bureaukratiske former for software produktion baseret på opdeling i opgaver, på planlægning og opgavestyring, hvor opgaver nedbrydes i mindre opgaver, der allokeres i tid og på personer. I det traditionelle paradigme udføres processer ofte af specialister med en klar arbejdsdeling og ofte med en skelnen mellem folk, der planlægger og folk, der udfører, mens agile teams i højere grad er sammensat af mennesker med lige kvalifikationer og kompetencer. I det traditionelle paradigme ses folk som funktioner, hvor mangel på arbejdskraft i et projekt kan løses ved at overføre medarbejdere fra et andet projekt. I det agile paradigme er vægten i langt højere grad på socialisering og på tavs viden, og flytning af medarbejdere mellem projekter er derfor ofte mere problematisk. Synet på kommunikation varierer også ganske meget mellem traditionel og agil udvikling. Traditionelt organiserer man sig hierarkisk i linie-stabs organisationer for at sikre enstrenget ledelse og minimal kommunikation. Kommunikation opfattes som en udgift, tid hvor der ikke produceres, og ikke som en vigtig del af Ivan Aaen

8 udviklingsarbejdet. Dette står i skarp kontrast til agil udvikling, hvor hovedparten af informationerne udveksles i dialog og anden interaktion som antydet i det agile manifests udsagn, Customer collaboration over contract negotiation, hvor kunderepræsentanter integreres som medlemmer af teamet. På teamniveau har billedet været mere nuanceret, idet man traditionelt har varieret mellem chief programmer teams med en skarp rollefordeling til egoless programming, med en mere uformel og flad struktur. Overordnet har den traditionelle fokus dog været på bureaukratiske principper eksemplificeret ved software factories, CASE værktøjer og software procesforbedring; og teams er blevet sammensat til det konkrete projekt ud kompetencer og hvem, der måtte være til rådighed. Agile teams har ofte en mere stabil sammensætning ud fra ideer, der minder meget om holdspil med fokus på kendskab og anerkendelse, på tillid og sympati. Teams er således ikke enheder designet til lejligheden, men noget der vokser frem organisk over tid og formes af de udfordringer, der dukker op med tiden. Symptomatisk for denne sportlige metafor er, at agile teams ofte har en coach-rolle. To af det agile manifests principper udtrykker centrale ideer i det agile syn på mennesker: Agile processer skal kunne fungere over lang tid. Sponsorer, udviklere og brugere bør være i stand til at holde et konstant tempo i ubegrænset tid. De bedste arkitekturer, krav og design kommer fra selv-organiserende teams. På mange måder kan skiftet fra et traditionelt til et agilt paradigme beskrives som et skift fra proces til mennesker, idet der er langt større vægt på menneskers kunnen og relationer i det agile paradigme. Tilsvarende skifter vægten fra at være på opsplitning og standardisering til samling af opgaver, fra planlægning til læring, fra omkostninger og tidsplan til skabelse af forretningsværdi og fra sporbarhed til validering. 3 Agilitet, kreativitet og innovation I dette kapitel bruges ordene kreativitet og innovation ofte med en overlappende betydning. Der er tale om to forskellige begreber, der i praksis ofte er tæt knyttede til hinanden. Kreativitet handler om anvendelse af fantasi eller originale ideer - i dette tilfælde i forbindelse med softwareudvikling. Innovation bruges tilsvarende om forandring knyttet til udvikling eller indførelse af nye metoder, teknikker eller produkter. Kreativitet ses således her som noget, der kan føre innovation med sig. I traditionel software engineering litteratur omtales kreativitet og innovation uhyre sjældent. Det er som om, man har opfattet faget som innovativt alene i kraft af enten fagets eller teknologiens relativt unge alder. I fagets barndom var der imidlertid meget fokus på automatisering, hvor præcision i løsningerne i forhold til manuelle rutiner havde prioritet. Samtidigt medvirkede den vedvarende fokus på kravsspecifikation og kontraktopfyldelse vel også til at nedprioritere interessen for at skabe nye muligheder i løbet af et software projekt. Bortset fra området Human Computer Interaction (HCI) er der skrevet forbavsende lidt om kreativitet og innovation inden for de datalogiske fagområder. En søgning på ACMs og IEEEs digitale biblioteker finder ganske få publiserede arbejder, der handler om innovation eller kreativitet i relation til softwareudvikling. I vores tidsalder, hvor teknologien er blevet moden, hvor brugerne og kunderne er kompetente, og hvor trivielle opgaver kan løses hvor i verden, det kan gøres billigst, er der en voksende fokus på værdiskabelse i softwareudvikling i den udviklede del af verden. Kreativitet og innovation kan derfor ikke længere henvises til en ubetydelig Ivan Aaen

9 birolle i softwarebranchen, men må betragtes som et væsentligt indsatsområde. Et område, hvor agile principper måske tilbyder interessante perspektiver sammenlignet med traditionel software engineering. Agil udvikling er interessant for innovativ og kreativ softwareudvikling, fordi agil udvikling frem for alt tilbyder udvikling med stor hastighed og fleksibilitet i en tæt dialog mellem kunder og brugere. Disse egenskaber er ideelle for udnyttelsen af producent/bruger-koblinger med fokus på gensidig læring og udfordring og giver således gode rammer for kreativt og innovativt arbejde. De fleste vil nok forbinde kreativitet og innovation med udvikling af nye produkter eller måske af nye arbejdsprocesser, men der kan faktisk identificeres emner inden for alle fire perspektiver på softwareudvikling, hvor kreativitet og innovation kan spille er vigtig rolle. Jeg forestiller mig derfor, at der udvikles teknikker til at arbejde med kreative og innovative ideer inden for alle 4 perspektiver nævnt i det foregående kapitel. For at understøtte udviklingen af sådanne teknikker og for at hjælpe teamet med at identificere hvilke områder, det har behov for at udvikle ideer inden for, vil jeg opstille en række generiske emner, der så skal konkretiseres af teamet ud fra den specifikke situation forud for et Innovation Game. I dette kapitel vil jeg identificere forskellige typer af software-innovation, og i det efterfølgende kapitel vil jeg skitsere måder, hvorpå agile projekter kan tilrettelægges med henblik på at øge det kreative og innovative potentiale. 3.1 Product Produkt-innovation er nok den innovationsform, de fleste overhovedet forbinder med ordet innovation. Udbud af nye eller forandrede produkter og serviceydelser er produkt-innovationer. I traditionel softwareudvikling er der en række faktorer, der hæmmer og begrænser produkt-innovation. Som tiden går i et projekt, bliver det mere og mere vanskeligt at introducere nye ideer i produktet på grund af de investeringer, der allerede er foretaget i projektets arbejdsprodukter - eksempelvis analysedokumenter, designdokumenter, testplaner og produktionskode. Disse arbejdsprodukter skal revideres, når nye ideer introduceres, og dette arbejde koster tid og penge. Specifikations-drevne projekter indebærer en præference for at indbygge innovative ideer i kravspecifikationen. Alene af den grund bliver innovation fortrinsvist henvist til begyndelsen af projektet, hvor muligheder og udfordringer er mest uhåndgribelige, og hvor alternativer kan være svære at forstå eller kommunikere. Da kravspecifikationen præcist skal afspejle kundens udtrykte ønsker, vil også dette bidrage til at begrænse den potentielle innovations-højde i projektet, idet dialogen med kunden sigter mod at afdække og definere kundens ønsker mere end mod at udfordre og udvikle disse ønsker til mere værdifulde løsninger. I lighed med det traditionelle paradigme ser også det agile paradigme kunden som kilden til de krav, projektet skal opfylde. Af den grund er det agile paradigme principielt omfattet af det samme problem, som det traditionelle, nemlig at produktinnovation primært er et anliggende for en gruppe mennesker, der er begrænsede på 2 måder: De er begrænsede i antal, fordi de alle kommer fra brugerorganisationen, og de er begrænsede i viden, fordi de primært kommer med viden fra anvendelsesområdet. Der sker derfor ikke en inddragelse af udviklernes ekspertise på det teknologiske område, der potentielt kunne lede til mere gennemgribende innovationer. Agil litteratur behandler kun sjældent emnerne kreativitet og innovation, og det tror Ivan Aaen

10 jeg er relateret til synet på kunden som kilde til krav - et syn som det traditionelle og agile paradigme har til fælles. Når det agile manifest foretrækker Working software over comprehensive documentation, så mindskes en alvorlig hæmsko for kreativitet og innovation i form af det begrænsede vindue, hvor nye ideer kan få indpas i projektet. Den anden hæmsko - den svage inddragelse af udviklernes teknologiske overblik og fantasi - påvirkes ikke. Heller ikke princippet om enkelhed løser det problem, mens principperne om hyppige leverancer af fungerende software til kunden giver et betydelige potentiale for eksperimenteren og improvisation og skaber dermed spændende muligheder for fælles ide-udvikling. Der er 2 generiske typer af produkt-innovation: Innovativ software - software, der i sig selv er nyskabende Software som del af et innovativt system - software, der indgår i innovativ systemudvikling 3.2 Project Projekt-innovation er et mere uhåndgribeligt begreb. Med projekt-innovation mener jeg dels ændringer i den kontekst, hvori produkter eller serviceydelser leveres, dels den måde hvorpå projektet ledelsesmæssigt tilrettelægges med sigte på at opnå ambitiøse svar på projektets udfordringer. Projekt-innovation handler således både om, hvordan man kan stimulere kreativitet og innovation igennem hele projektets forløb, og om hvordan man kan identificere muligheder i afsluttede projekter, der kunne give gennembrud i det nye projekt. Traditionel softwareudvikling sigter mod strukturering af projektforløbet gennem fastlæggelse af projektets aktiviteter, gennem arbejdsdeling, gennem indsamling af flest mulige informationer ved projektets begyndelse og omfattende planlægning på grundlag heraf, og ikke mindst gennem fastlæggelse af formelle rutiner for, hvordan kunde og projekt håndterer ændringsønsker undervejs i projektet, så udviklingsarbejdet kan foregå på et så velkendt og stabilt grundlag, som muligt. Kravstyring, udførlig planlægning og gennemførelse i henhold til planer er fundamentale principper i traditionel udvikling. Den slags principper bidrager som nævnt ovenfor til at begrænse produkt-innovationen, men principperne kan tilsvarende bidrage til at begrænse projekt-innovation i den forstand, at man af hensyn til tidsplaner eller aftalt kravspecifikation kun tillader opportunistiske forsøg på at drage fordele af tidligere projekters resultater i starten af det nye projekt. Agil udvikling sigter mod gradvis fremvækst af løsninger kombineret med justeringer ud fra erfaringer med det allerede udviklede. Fleksibilitet i projektets tilrettelæggelse er udtrykt i det agile manifests udsagn om Responding to change over following a plan og i principperne om hyppige leverancer af software, om dagligt samarbejde mellem kunderepræsentanter og udviklere, om motiverede individer, der nyder tillid, samt om ansigt-til-ansigt kommunikation. Inspiration fra andre områder er allerede delvist indbygget i metoder som f.eks. XP, hvor metafor-begrebet netop kan bruges til at overføre løsninger og perspektiver fra andre anvendelsesområder til det aktuelle projekt. Selv om disse principper ikke er opstået med henblik på projekt-innovation, bidrager de alle til at skabe rammer for innovativ projekt-ledelse bl.a. i form af tryghed, nærhed, fleksibilitet, fokus og samarbejde i teamet. Heller ikke agil udvikling rummer dog egentlig støtte til at identificere og anvende erfaringer fra tidligere projekter eller løsninger i det nyte projekt. Der er 2 generiske typer af projekt-innovation: Ivan Aaen

11 Ledelse af software innovation (ideer til projektets organisering og gennemførelse, så projektets udfordring besvares ambitiøst) Innovativ positionering af softwaren (kan tidligere udviklede softwareløsninger bruges kreativt og innovativt andre steder? Kan eksisterende løsninger, være svaret på problemer inden for andre områder eller brancher?) 3.3 Process Proces-innovation er nok den innovationsform, de fleste vil nævne lige efter produktinnovation. Proces-innovation vedrører ændringer i de måder, hvorpå produkter og serviceydelser tilvejebringes på. Jeg vil her alene se på proces-innovation i udviklingsorganisationen, altså på forandringer i organisationens måde at udvikle software på - forandringer der medfører effektiviseringer eller kvalitetsforbedringer. Traditionel software procesforbedring er et kendt eksempel på proces-innovation i udviklingsorganisationen. Her er der normalt tale om designede forandringer i arbejdsrutiner, der søges rullet ud som standarder blandt udviklerne i organisationen. Processerne beskrives normalt ganske udførligt i dokumenter, der er tilgængelige på virksomhedens intranet, og organisatorisk læring afspejles så ændringer i disse dokumenter. Procesbeskrivelserne suppleres normalt med et bibliotek af best practices og templates, der kan bruges til dokumentation af aktiviteterne i et aktuelt projekt. Hvor hovedstrategien i traditionel softwareforbedring således er opsamling af erfaringer, design af procesændringer af specialister, skriftlig formidling af processerne og tilegnelse af processerne med brug af dette skriftlige materiale, så er strategien ganske anderledes i agil softwareudvikling. I det agile paradigme spiller socialisering en hovedrolle i udviklingen og formidlingen af god praksis. Processer er ikke produkter, der designes og implementeres, men praksis, der udvikles af teamet, mens det løser sine primære opgaver. Af væsentlige mekanismer til udvikling og formidling af god agil praksis kan nævnes parprogrammering og fælles kode-ejerskab. God praksis, som man ønsker fastholdt skriftlig form, kan f.eks. formuleres kort i form af patterns. Det agile manifests syn på udvikling af god praksis udtrykkes klart i udsagnet Individuals and interactions over processes and tools og principperne om teknisk excellens og godt design samt princippet om refleksion over egen praksis. Der er 2 generiske typer af proces-innovation: Innovationsprocesser (identificering, vurdering og anvendelse af metoder, teknikker og værktøjer der stimulerer kreativt og innovativt arbejde) Procesinnovationer (identificering og fastholdelse af nye metoder, teknikker, værktøjer og principper, som teamet har udviklet under et projekt, læring fra successer og fiaskoer, identificering af mønstre) 3.4 People People-innovation omhandler ændringer i de mentale modeller (paradigmer) i organisationens medlemmer. Disse mentale modeller kan eksempelvis dreje sig om opfattelsen af sig selv, af udviklingsteamet eller udviklingsorganisationen, eller om opfattelsen af kunden, kundeorganisationen eller markedet. Ændringer i mentale modeller kan fjerne blokeringer eller give nye perspektiver, så man kan få øje på nye muligheder og løsninger. Bortset fra når det traditionelle paradigmer inddrager hjælpediscipliner fra andre områder - f.eks. ledelse og HR - så er der ikke i dette paradigme elementer, der retter Ivan Aaen

12 sig mod people-innovation. Undertiden initieres procesforbedring og andre former for organisationsudvikling af seancer, der skal bidrage til at gøre organisationens medlemmer mere forandringsparate, men i dagligdagen er der sjældent meget, der sigter mod at forandre perspektiver. Noget tilsvarende kan man sige om det agile paradigme, men der er dog væsentlige elementer, der naturligt fremmer forandringsparatheden i agile teams. Det agile manifests udsagn om Customer collaboration over contract negotiation har den vigtige følgevirkning, at teamet må åbne sig mod omverden - mod kundens univers - og optage en kunderepræsentant i teamet. Princippet om at processerne skal kunne fungere over lang tid og at alle involverede skal kunne holde et konstant tempo i ubegrænset tid indebærer, at teamet skal have overskud, og princippet om, at teamet er selv-organiserende medfører empowerment og personligt ansvar. Der er 2 generiske typer af people-innovation: Skift i teamets mentale modeller af kunder, brugere, markeder, domæner,... Skift i teamets eller medlemmernes mentale modeller af sig selv, af teamet, organisationen, organisatoriske netværk, Et manifest for software innovation? Jeg er ikke tilfreds med det agile manifest, da antagelsen i manifestet er, at softwareudviklere står med den samme opgave som altid. Med globalisering og outsourcing af arbejdsopgaver så står IKT-branchen med nye udfordringer. Hvor man tidligere skulle producere effektivt efter kundens ønsker, så må opgaven idag mere være at fokusere på værdiskabelse. Derfor kunne man overveje et alternativt manifest for innovativ software-udvikling: Challenge over assignments Response over solution Reflection over compliance Facilitation over structuration I dette manifest er kundens opgave ikke at stille en opgave, men at komme med en udfordring. Udviklerens opgave er ikke så meget at løse opgaven, som at svare på udfordringen med et ambitiøst svar, der nok er en mulig løsning, men også et bidrag til dialog med kunden. Kundens svar er ikke så meget om løsningen er korrekt i forhold til opgavebeskrivelsen; men om svaret er det bedst mulige. Processen er ikke på forhånd fastlagt så teamet følge en slagen vej; i stedet understøttes processen teknologisk, teknisk og metodisk med henblik på at lette improvisation og eksperimenteren. Essence, der præsenteres i kapitel 5, er baseret på disse overvejelser. Det næste kapitel præsenterer den infrastruktur, der er udgangspunktet for udviklingen af Esence. 4 SIRL - Software Innovation Research Lab 4.1 Baggrund SIRL blev etableret ved Institut for Datalogi på Aalborg Universitet i august 2006 og tilknyttet instituttets forskningsgruppe inden for informationssystemer (IS). Formålet med SIRL er at skabe infrastrukturelle rammer for gruppens forskning inden for kreativitet og innovation i systemudvikling. Dette afsnit beskriver SIRLs fysiske og systemmæssige rammer, dvs. den platform, Ivan Aaen

13 som er grundlaget for arbejdet i laboratoriet. På denne platform kan der eksperimenteres med metoder, teknikker og værktøjer til fremme af kreativ og innovativ softwareudvikling. Disse eksperimenter finder for øjeblikket sted inden for en ny metodisk ramme - Essence - der beskrives i det efterfølgende afsnit. SIRL og Essence er ikke modelleret efter kendte forbilleder, men ud fra overvejelser om, hvordan kreative rammer for softwareudvikling kunne se ud. Der findes en række faciliteter i verden, der sigter mod at fremme kreativitet og ide-udvikling generelt, og som kan bruges til mange forskellige klasser af problemer. Disse faciliteter retter sig ikke specifikt mod softwareudvikling i modsætning til SIRL og Essence. En konsekvens af, at SIRL og Essence retter sig mod softwareudvikling er, at der søges taget højde for, at ide-udvikling ikke nødvendigvis er henvist til en isoleret aktivitet i begyndelsen af et projekt. Endvidere opbygges faciliteterne i SIRL udstyrs- og indretnings-mæssigt med henblik på at understøtte et hold softwareudviklere. Andre steder i verden findes faciliteter indrettet specifikt med henblik på agil softwareudvikling. Sådanne arbejdsrum - ofte kaldet war rooms - er indrettet flere steder i industrien, men vi har ikke set nogen, der retter sig mod software innovation, eller har udstyr svarende til SIRL. 4.2 Principielle overvejelser SIRL er tænkt som et bud på funktionel indretning af fremtidens arbejdsplads for et udviklingsteam. Udgangspunktet er således, at lokalet kan understøtte alle faser i udviklingsarbejdet, og tillade, at teamet kan skifte mellem at arbejde individuelt, i par eller i hele teamet. SIRL baseres på en rumlig semantik. SIRL skal understøtte en rumopfattelse, hvor den fysiske placering af emner på rummets vægge afspejler betydningen af det enkelte emne. Perspektiver med metaforiske navne og dertil knyttet betydning forbindes derfor til prædefinerede pladser på væggene i rummet. På den måde bidrager den fysiske placering i sig selv til at reducere den oplevede kompleksitet ved at sammenkoble betydning og rumlig placering. Den rumlige semantik kan således være et tankeredskab og et kommunikationsredskab, idet den faste rumopfattelse blandt andet hjælper med at anlægge alternative perspektiver på en problemstilling og understøtter kommunikationen i gruppen gennem fælles begreber og strukturer. SIRL er således baseret på en række ideer. Rummet skal: Understøtte brainstorming og andre teknikker til kollektiv idé-generering gennem adgang til tavler og værktøjer til fastholdelse af resultater. Understøtte kreative processer gennem fysisk bevægelse og lokalisering af emner. Bogstaveligt talt sikre, at værktøjer er lige ved hånden - rummet bestykkes med computere og interaktive skærme, der kan understøtte alle aktiviteter. Det skal være muligt direkte at manipulere objekter i computerne - gerne direkte med hænderne - så de opleves som håndgribelige og konkrete. Være multiperspektivisk - rummet skal aktivt opfordre til og hjælpe med at anlægge forskellige perspektiver på en udfordring. Hjælpe med at holde perspektiverne adskilt og dog bevare overblikket og se sammenhænge på tværs af perspektiver. Være fleksibelt møbleret så rummet dynamisk kan tilpasses varierende arbejdsformer og grupperinger i teamet. Give mulighed for fælles kommunikation, hvor borde og computerskærme kan rettes mod lokalets midte, så alle uden videre kan komme i øjenkontakt Ivan Aaen

14 og dialog, og alle kan følge med i alle teamets overvejelser. Det multiperspektiviske understøttes gennem en opdeling af lokalet i fire generiske views - Fire, Earth, Water & Air. Disse views er opkaldt efter den græske filosof Empedokles teori om, at alt i denne verden er sammensat af disse fire elementer. De fire jordiske elementer udgør altså tilsammen en helhed. En lang række moderne perspektiv-systemer omfatter også fire views. I flæng kan nævnes SWOT (Strengths, Weaknesses, Opportunities, Threats), McCarthys 4P inden for marketing (Product, Pricing, Placement, Promotion), Guptas 4P inden for Six Sigma process management (Prepare, Perform, Perfect, Progress), Likers 4P inden for ledelse (Philosophy, Process, People, Problem solving), Tidd, Bessant & Pavitts 4P inden for innovation (Product, Position, Process, Paradigm) og endelig Pressmans 4P inden for software engineering (Product, Project, Process, People). SIRLs fire generiske views kan derfor rumme mange og ganske forskellige perspektiv-systemer, der måtte være relevante for kreativ og innovativ softwareudvikling. 4.3 SIRLs indretning Indretning af SIRL Laboratoriet er indrette ud fra ovennævnte principper og har følgende udstyr og software Ivan Aaen

15 4 interaktive skærme (Smart Board 660 fra Smart Technologies) 4 loftsmonterede projektorer 4 PC-er (skjulte) + 1 server Visual Studio IDE SMART Ideas multilevel concept-mapping software Whiteboards på den ene væg. 2-mands arbejdsborde kontorstole. Udviklerne bringer deres egne laptops med. Alt udstyr uden fysisk funktionalitet - altså udstyr der ikke skal betjenes - monteres skjult, så det ikke virker distraherende på teamet. Laboratoriets indretning er antydet på de følgende fotos fra et af de første forsøg på at kombinere SIRL, Essence og Scrum med en idefase ved opstarten af et Scrum sprint. Fotos fra SIRL 5 Essence - en støtte til software innovation Essence er et metodekoncept, der er under udvikling i SIRL. Konceptet har sit navn Ivan Aaen

16 efter Quintessens - det kosmiske femte element, som Aristoteles foreslog som komplement til Empedokles fire jordiske elementer. Der findes allerede et antal metoder til kreativt arbejde, men såvidt vides er Essence den første, der retter sig mod innovativ softwareudvikling baseret på agile principper. 5.1 Ideer i Essence Essence og SIRL betragtes som en slags brugergrænseflade for teamet som helhed, der giver adgang til projektets værktøjer, arbejdsprodukter og øvrige ressourcer. De fire perspektiver i SIRL udgør en helhed, hvor hvert view har identitet og formål som del af denne helhed. Essence baserer sig på en række ideer, som kun kan omtales kort i det følgende: Kombination af kreative sessioner med agil udvikling for at opnå høj udviklingshastighed og bevare stor fleksibilitet indtil sent i projektet. Integration med og udvidelse af eksisterende agile udviklingsmetoder. Essence er ikke ment som en selvstændig metode. Understøttelse af kreativitet og innovation igennem hele udviklingsprojektet. Overladelse af det kreative arbejde til udviklingsteamet - ikke til eksterne specialister i starten af et projekt. Kinæstetisk tænkning - anvendelse af fysisk placering og kropslig bevægelse som støtte til tænkning, simulering og kreativitet. Brug af roller - Challenger, Responder, Anchor og Child - som støtte til anlæggelse af flere perspektiver og især som støtte til synergier mellem kundens udfordringer og udviklerens ambitioner. Brug af views - Product, Project, Process, and People - til at holde ting adskilt. Views støtter opsplitning af problemområder så man samtidigt kan arbejde med overblik og detalje og med sammenhænge og transparens. Brug af modes - Idea, Planning, and Growing - som tilpasning af essence til de inkrementelle fremskridt i projektet. Essence skal tilpasse sig den aktuelle situation - eksempelvis hvor langt projektet er kommet, eller hvor tilfredse teamets medlemmer er med resultaterne. Essence skal være en letvægts-tilgang, der er let og sjov at bruge. Letvægts i den forstand, at den er uformel og kræver beskeden arbejdsindsats, så man ikke fristes til at springe den over på grund af tidsnød. Let at bruge i den forstand, at man ikke skal bruge lang tid på at lære at bruge Essence, og at aktiviterne i Essence skal virke naturlige for deltagerne. Sjov at bruge for at øge motivation og udbytte. For at opnå dette organiseres Essence i spil, der minder om rollespil og improvisationsteater. Disse er begge baseret på definerede roller, omgivelser og situationer, mens hændelser og ageren i det væsentlige overlades til deltagerne selv og udvikles gennem disciplinerede improvisationer. Deltagerne har én ud af fire roller, der definerer deres person. Hver rolle har et sæt idealer og værdier, der giver rollen sine rationaler. Challenger er kunde og har alle de ansvarsområder, der påhviler en on-site customer. Det særlige ved Challenger er, at projektets krav skal formuleres åbent og på en så udfordrende måde, som muligt. Responder er udvikler og bruger sin teknologiske kompetence til at udvikle ambitiøse svar på disse udfordringer. Ideen i et spil er især at bringe disse to roller i en dialog, hvor behov og ønsker fra anvendelsesområdet konfronteres med teknologiske Ivan Aaen

17 muligheder. Anchor er hverken coach eller scrum master, men har til opgave at holde teamet fordybet og opslugt af projektet med sigte på at frembringe spændende løsninger - det som Zultner fra TQM kalder for Exciting Requirements. Den sidste rolle er Child; denne rolle er midlertidig i den forstand, at enhver i teamet kan påtage sig denne rolle midlertidigt på ethvert givet tidspunkt. Child er uden ansvar og kan rejse ethvert spørgsmål eller emne, som han eller hun finder påkrævet - også selv om dette måtte være i modstrid med beslutninger, der tidligere er truffet i teamet. Child tager sit navn efter det lille barn i Kejserens Nye klæder, der siger: Men han har jo ikke noget på! og dermed afslører Kejserens dårskab. Spillets omgivelser bidrager til at skabe det univers, hvori handlingen foregår - den fælles ramme, der udgør grundlaget for at udfolde hver persons idealer og værdier. For at skabe denne fælles ramme fordeler Essence Pressmans 4P-model ud på de fire generiske views i SIRL. Pressmans 4P blev valgt på grund af den faglige nærhed mellem softare engineering og agil udvikling, og ud fra det store overlap mellem Pressmans 4P og Tidd, Bessant & Pavitts 4P inden for innovation. To af deres perspektiver - product og process - er ens for de to modeller, mens paradigme og people har betydelige fællestræk og position og projekt også overlapper en del. Med personer og omgivelser på plads vil næste trin være etablering af et dynamisk element: Den situation der er sidste brik i spillets univers - spillets udgangspunkt. Første del af situationen er et udvalgt Essence Game. Essence Games er inspireret af Luke Hohmans Innovation Games og af mange metoder beskrevet af Huczynski. Essence Games baseres på princippet om altid at sige ja - altid at acceptere og videreudvikle de tilbud som andre personer bringer ind i situationen. Videre skal Essence Games udnytte roller, views og modes i Essence. Den anden del af situationens udgangspunkt er projektets status. Projekter er i én ud af tre forskellige modes eller tilstande, der definerer hvad et Essence Game handler om: Idea, Planning eller Growing. Hver tilstand afspejler de emner, der falder naturligt at behandle kreativt på forskellige trin af et projekt. Idea er det mode, hvor forskellige strategier foreslås, og hvor koncepter og mentale billeder udvikles. Dette mode omfatter undersøgelser, eksperimenter, brainstorming, udvikling af scenarier, discovery experiments etc. Essence Games i dette mode er fortrinsvis eksplorative. Planning er hvor forslag til aktiviteter eller målsætninger udvikles og nødvendige forberedelser identificeres. Dette mode fører til beslutninger eller målsætninger om, hvad der må gøres, hvornår og af hvem. Essence Games i dette mode har særlig fokus på at skabe overblik, på kortlægning og på identifikation af opgaver. Growing er det mode, hvor ideer omsættes til virkelighed via evolution, udvælgelse, modning, udvidelse og udvikling. Essence Games i dette mode sigter primært mod at bekræfte de valgte ideer og undersøge, om der fortsat er en passende innovationshøjde i projektet og om projektets potentiale udnyttes. Jeg har ovenfor peget på et antal begrænsninger i traditionel og agil udvikling med hensyn til innovation. I det følgende vil jeg diskutere, hvordan disse begrænsninger kan imødegås i Essence. 5.2 Product Traditionel såvel som agil udvikling synes at underspille interaktionen mellem deltagere fra anvendelsesområdet og udviklingssiden som midler til at udveksle perspektiver og udvikle udfordrende ideer, der kan føre til innovative alternative løsninger. Metodisk vil Essence derfor stimulere den kreative dialog mellem især Challenger og Responder med henblik på at udvikle ambitiøse svar på udfordringerne fra anvendelsesområdet. Ivan Aaen

18 Visuelt vil Product viewet blive brugt af Responders under hele projektet til at repræsentere det produkt, der er under udvikling - kildekoden - for at gøre produktet selv og forslag til ændringer i produktet håndgribelige og konkrete i teamets diskussioner. 5.3 Project Hverken traditionel eller agil udvikling tilbyder megen støtte til at anvende erfaringer fra tidligere projekter eller løsninger som inspiration til at angribe aktuelle problemer. Tilsvarende tilbyder de også kun beskeden støtte til at stimulere og fastholde kreativitet igennem et projekt. Der er endnu ikke udviklet et omfattende svar på disse begrænsninger i Essence. En hovedstrategi i Essence vil være at fremme brugen af metaforer som instrumenter til at overføre viden og inspiration fra ét område til et andet. Metaforers potentielle styrke blev aldrig udnyttet i extreme Programming (XP) og metaforer blev endda udeladt i anden udgave af XP. Forfattere som West og Solano har kritiseret dette, og jeg deler denne kritik ud fra den opfattelse, at metaforer kan være meget værdifulde redskaber til at udvide eller ændre perspektiv i softwareudvikling og dermed styrke kreativitet og innovation. Metodisk vil Essence derfor foreslå et arkiv over afsluttede projekter og produkter, der kan tjene som grundlag for metaforer. Visuelt vil Project viewet støtte Challenger i at bevare overblikket over projektstatus og -planlægning ved at vise sprint status og backlog samt project status og backlog. 5.4 Process Hverken traditionel eller agil udvikling yder støtte til udviklingsteamets innovative og kreative arbejdsprocesser. Metodisk vil Essence derfor tilbyde et repertoire af kreative metoder, teknikker og værktøjer. Patterns vil blive brugt som et kortfattet og overskueligt format for Essence Games. Visuelt vil Process view give overblik over og adgang til dette repertoire igennem hele projektet. Process view vil også rumme værktøjer til brainstorming, innovation og kreativitet - eksempelvis ThoughtOffice and Smart Ideas. 5.5 People Traditionel og agil udvikling tilbyder heller ikke megen støtte til udvikling af nye mentale modeller for udviklingsorganisationen eller for anvendelsesområder og markeder. Et arkiv over metaforer og et repertoire af kreative metoder, teknikker og værktøjer sigter begge mod at mindske dette problem, men adgang til disse er ikke ensbetydende med, at de vil blive brugt. Metodisk vil Child rollen i Essence give enhver i teamet mulighed for - uden ansvar - at sætte spørgsmålstegn ved grundlæggende antagelser, værdier og lignende i projektet for en tid. Forstyrrelser eller andre interventioner fra eksterne konsulenter kan også finde sted i den forbindelse. Visuelt vil People view blive brugt til at vise anvendelsessiden af den software, der er under udvikling - ofte gennem eksekvering af software builds, hvor funktionaliteten i softwaren demonstreres. Igennem hele projektet kan dette view visualisere brugsscenarier f.eks. i form af video-optagelser fra bruger-organisationen, videolinks til faktiske brugere, etc. Dette view kan også tjene som access point til teamet for interessenter på andre lokationer ved brug af video-chat, Skype og lignende. Ivan Aaen

19 6 Status for Essence og SIRL januar 2008 Såvel SIRL som Essence introducerer begreber, strukturer og arbejdsformer, der såvidt jeg ved ikke er blevet kombineret tidligere. Begge er stadigt tidligt i deres udvikling, og de første eksperimenter sigter derfor mod at give indblik i deres nytte og viden om, hvordan de bedst kan anvendes. På dette stadie er det imidlertid ikke muligt at eksperimentelt at indhente tilstrækkelig information eller data, der kan understøtte egentlige konklusioner i klassisk videnskabelig forstand, men eksperimenterne kan være egnede til at hjælpe med at formulere forskningsspørgsmål, der så kan afklares på et senere tidspunkt. Af den grund er de tidlige eksperimenter med SIRL og Essence tilrettelagt som discovery experiments. Formålet med et discovery experiment er ikke at opnå den grad af kontrol og gentagelighed i forsøgene, der kan give statistisk støtte for resultaterne. Istedet bruges den slags eksperimenter til at luge mindre lovende ideer ud og sætte fokus på de mest lovende anvendelser og betingelserne for praktisk brug. Forhåbentligt vil sådanne eksperimenter give grundlag for mere systematisk afprøvning. Sammen med mine gode studerende har vi nu etableret og brugt SIRL igennem de sidste 18 måneder. Sigtet har været at udvikle SIRL og Essence skridt for skridt gennem at anvende dem til praktisk softwareudvikling. Foreløbigt har vi eksperimenteret med den fysiske opdeling i fire vægge og den logiske opdeling i fire views, samt med Essence Games. De første discovery experiments tyder på, at udnyttelsen af fysisk og logisk opsplitning har et potentiale, men at dette potentiale forudsætter, at roller og Essence Games er velkendte for deltagerne, hvis opdelingerne skal fungere som tilsigtet. Vi har også gjort erfaringer med Essence Games og fundet, at de forudsætter, at der udarbejdes en kortfattet beskrivelse af et game, et uformelt gameplay og at deltagerne har stort kendskab til deres rollers værdier og idealer. Disse forudsætninger har vist sig at være pænt store udfordringer, så der er mange opgaver, der skal løses i de kommende år. Tak til... Jeg skylder stor tak til mine kolleger, Jens henrik Hosbond, Peter Axel Nielsen og Jeremy Rose for inspiration og tålmodighed i vores diskussioner. Også mine studerende i SIRL, Morten Andersen, Søren Andreassen, Lasse Bæk og Philip Bredahl Thomsen ( ) og Jeppe V. Boelsmand, Rasmus Jensen, Jan Leckscheidt og Morten Saxov ( ) fortjener stor tak. Deres hjælp til at etablere SIRL og forberede og indgå i eksperimenter har været helt uundværlig. En særlig tak til Søren Hansen, grundlægger af Kreativitetslaboratoriet ved Aalborg Universitet, for at påvise potentialet i improvisationsteater. Links Agile arbejdsrum: xp123.com/xplor/room-gallery Det agile manifest: agilemanifesto.org/ Martin Fowler artikler: Ivan Aaen

20 Sirl: Wikipedia om Agile Software Development: en.wikipedia.org/wiki/agile_software_development Udvalgt litteratur Abran, A. & Moore, J. W. (Eds.). (2004). Guide to the Software Engineering Body of Knowledge SWEBOK, 2004 Edition. Washington: IEEE Computer Society. Alberts, D. S. & Hayes, R. E. (2002). Code of best practice for experimentation (CCRP publication series Information age transformation series). Washington, D.C: DoD Command and Control Research Program. Alberts, D. S. & Hayes, R. E. (2005). Campaigns of experimentation : pathways to innovation and transformation (Information age transformation series). Washington, D.C: CCRP Publication Series. Beck, K. (2000). Extreme Programming Explained: Embrace change. Reading, MA: Addison-Wesley. Beck, K. & Andres, C. (2005). Extreme programming explained : embrace change (2nd ed.). Boston, MA: Addison-Wesley. CMMI Product Team. (2002a). CMMI for Software Engineering, Version 1.1, Continuous Representation (CMMI-SW, V1.1, Continuous). CMMI Product Team. (2002b). CMMI for Software Engineering, Version 1.1, Staged Representation (CMMI-SW, V1.1, Staged). Cockburn, A. (2005). Crystal clear : a human-powered methodology for small teams (Agile software development series). Boston: Addison-Wesley. Coplien, J. O. & Harrison, N. (2005). Organizational patterns of agile software development. Upper Saddle River, NJ: Pearson Prentice Hall. Fowler, M. (2003). Design - Who needs an architect? IEEE Software, 20(5), Fowler, M. (1997). Analysis patterns : reusable object models. Menlo Park, Calif: Addison Wesley. Fowler, M. (1999). Refactoring : improving the design of existing code (Addison-Wesley object technology series). Reading, MA: Addison-Wesley. Gamma, E. (1995). Design patterns : elements of reusable object-oriented software (Addison-Wesley professional computing series). Reading, Mass: Addison-Wesley. Hohmann, L. (2006). Innovation Games: Creating Breakthrough Products Through Collaborative Play. Addison-Wesley Professional. Huczynski, A. (2001). Encyclopedia of Development Methods (3rd ed.). Aldershot, UK: Gower. Larman, C. (2004). Agile and iterative development : a manager's guide. Boston: Addison-Wesley. Mugridge, R. & Cunningham, W. (2005). Fit for developing software : framework for integrated tests. Upper Saddle River, N.J: Prentice Hall Professional Technical Reference. Poppendieck, M. & Poppendieck, T. (2003). Lean software development : an agile toolkit (Agile software development series). Boston: Addison-Wesley. Pressman, R. S. (2005). Software engineering: a practitioner's approach (6th ed., international ed ed.). Boston, Mass. ; London: McGraw-Hill Higher Education. Ivan Aaen