Fra vandfald til agil projektmodel
Fra vandfald til agil projektmodel Eksamensopgave ITU IT-projektledelse og softwareprodukter Forår 2010 Vejleder: Claus Seeberg Friis Noah, Kenneth, Finn og Helle Side 2 af 31 - Fra vandfald til agil projektmodel Indholdsfortegnelse 1. Indledning .....................................................................................................................................3 2. Problemformulering......................................................................................................................4 3. Introduktion til DSB-IT og NBT ..................................................................................................4 4. Empiri ...........................................................................................................................................5 4.1 Sammenfatning af interviews.....................................................................................................5 5. Omstilling i forhold til Organisation ............................................................................................6 5.1 Grundlæggende egenskaber .......................................................................................................7 5.2 Om kunden der skal afgive magt................................................................................................8 5.3 Om tillid mellem organisation og team......................................................................................9 6. Udfordringer internt i teamet ......................................................................................................10 6.1 Samarbejde ...............................................................................................................................10 6.2 Projektleder skal turde give teamet frihed og magt..................................................................11 6.3 Kvalifikationer for gruppens medlemmer ................................................................................12 7. Forandringsledelse......................................................................................................................13 7.1 Opsummering i forhold til forandringsledelse .........................................................................15 8. Samlet vurdering af omstillingen................................................................................................16 9. Konklusion..................................................................................................................................17 Bibliografi ..........................................................................................................................................18 Bilag 1: Spørgsmål til interview ........................................................................................................19 Bilag 2: Interview med Carsten Solvang ...........................................................................................23 Bilag 3: Interview med Peter Wammen.............................................................................................29 Bilag 4: Identificerede udfordringer ..................................................................................................31 Side 3 af 31 - Fra vandfald til agil projektmodel 1. Indledning Agile metoder til systemudvikling, som eksempelvis Scrum, vinder indpas i stadig flere virksomheder og teams. For mange har det været en god ide at køre efter agile processer, mens andre har fået mindre udbytte af potentialet i disse metoder. I denne opgave belyser vi problemet med at omstille et udviklingsteam til agil systemudvikling. Der er flere relevante problemstillinger i denne forbindelse. For eksempel skal selve teamet omstille sig til at arbejde efter de ændrede principper, og desuden skal resten af organisationen foretage visse justeringer for, at en sådan omstilling skal lykkes. Opgaven vil tage udgangspunkt i litteraturen samt to interviews med henholdsvis en projektleder og en forretningsansvarlig i DSB. Projektlederen har ansvaret for teamet, der varetager udviklingen af DSBs NetButik (http://www.dsb.dk/netbutik) - vi vil i det følgende benævne dette team 'NBT'. NBT valgte i 2001 at omstille udviklingen til agil og kører nu fuldstændigt efter agile principper. Opgavens struktur er som følger: Først gives en kort introduktion til DSB-IT og NBT. Herefter beskrives tilrettelæggelsen af interviews. Målet med disse interviews er, at få belyst hvilke udfordringer, der har været ved at omstille NBT til at benytte en agil projektmodel, samt at vurderer om omstillingen kan betragtes som en succes. På baggrund af disse interviews identificeres centrale udfordringer i omstillingen, som belyses ved hjælp af relevant litteratur. Vi vil i den forbindelse opstille særligt vigtige forhold, når man skal skifte et team fra vandfaldsbaseret udvikling til agil. Til slut laves en vurdering af, hvorvidt omstillingen kan siges at være en gavnlig forandring for DSB. Vi er opmærksomme på, at interviewet med projektlederen er et partsindlæg, da han selv har været bannerfører i omstillingen til agil systemudvikling. Der findes givetvis også modstandere af en sådan omstilling i organisationen, men vi har i denne opgave ikke fundet tid og plads til at kunne medtage interviews med en sådan - det er heller ikke sikkert, at det er så ligetil at finde en. Side 4 af 31 - Fra vandfald til agil projektmodel 2. Problemformulering Vi vil i opgaven belyse spørgsmålet: hvilke udfordringer og fordele giver det at omstille et udviklerteam fra en vandfaldsbaseret til en agil projektmodel? Dette spørgsmål søges besvaret både indadtil i forhold til teamet selv, og udadtil i forhold til organisationen. For det konkrete eksempel vil vi endvidere vurdere, om omstillingen har været positiv for DSB. 3. Introduktion til DSB-IT og NBT DSBs IT afdeling har ca. 300 ansatte, som arbejder med mange forskellige typer af IT-systemer, lige fra togsystemer og ERP-systemer til websider. Organisationen er opdelt som flere små afdelinger, der hver har ansvaret for et forretningsområde eller en organisatorisk funktion. Overordnet fungerer DSB-IT som en stor matrixorganisation, hvor de enkelte IT-medarbejdere ”flyder” fra projekt til projekt og en medarbejder behøver derfor ikke at arbejde på projekter tilknyttet den afdeling, hvor han er ansat. En medarbejder kan ligeledes arbejde på flere projekter af gangen. Den overordnede resurseallokering af medarbejdere i DSB-IT styres centralt. Ansvaret for denne opgave ligger hos afdelingen med ansvaret for projektledelse, hvor alle projektlederne ligeledes er ansat. Afdelingen vi i denne rapport har fokus på hedder ”Digitale kanaler og CRM” og udviklingsteamet tilknyttet denne afdeling bliver i daglig tale kaldt Netbutik-teamet (NBT). NBT består af 16 medarbejdere; en projektleder, en analytiker, to driftsansvarlige, otte udviklere, samt fire testere. Der er ligeledes tilknyttet en ekstern konsulent med ansvar for dokumentation og automatiseret test, samt procesoptimeringer i relation hertil. Ancienniteten i teamet varierer mellem et til ti år. NBTs primære ansvarsområde er udvikling og drift af ’Netbutikken’, som er den webapplikation hvorigennem DSB sælger billetter på internettet. Netbutikken er et projekt på lige fod med andre projekter i organisationen, men med den særlige omstændighed, at der ikke er planlagt en afslutning for projektet. I NBT bliver udviklingen drevet efter agile principper, der er meget inspireret af Side 5 af 31 - Fra vandfald til agil projektmodel SCRUM. Teamet kører iterationer med en varighed på 2 uger, og kravene til projektet ændrer sig løbende. Det er målsætningen, at der i forbindelse med hver iterations afslutning idriftsættes funktionel kode, hvilket lykkes i 80 - 90 % af iterationerne. Der er pt. ca. 20 udviklingsteams i DSB-IT og i hovedparten af disse teams drives udviklingen efter vandfaldsprincipper. Det agile NBT skal altså eksistere i en organisation, der primært er gearet til at udviklingsteams drives efter vandfaldsprincipper. 4. Empiri For at få belyst hvilke udfordringer, der har været ved at omstille NBT fra en vandfaldsbaseret til agil projektmodel, har vi valgt at gennemføre interviews med følgende personer: Carsten Selvang – Carsten har været projektleder på projektet Netbutikken siden projektstart i 2001 og har ligeledes været forgangsmand for implementering af agile processer i DSB-IT. Carsten må derved antages at have relevant viden både om de udfordringer, der findes internt i et team, som omstilles fra vandfaldsbaseret til agil udvikling, men også om de udfordringer, man som projektleder stilles overfor i forhold til resten af organisationen. Peter Wammen – Forretningsmæssig ansvarlig for Netbutikken. Interviewet med Peter vil bidrage med forretningsenhedens (kundens) syn på om, NBT omstilling fra vandfaldsbaseret til agil projektmodel har været en succes. Vi har formuleret en række relevante spørgsmål med udgangspunkt i opgavens problemstilling og litteratur om emnet. Vi refererer til udformningen og motivationen bag spørgsmålene i bilag 1 ”Udledning af spørgsmål”. 4.1 Sammenfatning af interviews Interviewene er gennemført i april 2010 og er fyldigt refereret i bilag 2 ”Interview med Carsten Selvang” og bilag 3 ”Interview med Peter Wammen”. I dette afsnit vil vi kort sammenfatte de vigtigste pointer og udvælge tre hovedemner, som vi arbejder videre med i resten af opgaven. Side 6 af 31 - Fra vandfald til agil projektmodel I bilag 4 ”Identificerede udfordringer”, har vi sammenstillet de problemer, som interviewene har blotlagt. Vi har valgt at behandle følgende tre hovedområder, som problematiseres med de tilhørende punkter fra bilag 4. Omstilling i forhold til organisationen Kunden skal turde stille opgaver ”agilt” (opgaver skal være mere overordnet beskrevet) Tillid mellem forretning og udviklingsteam skal opbygges, da forretning mister en del af kontrollen over det endelige resultat. Udfordringer internt i teamet Udviklerne skal arbejde sammen som et team og lære at samarbejde med hinanden. Der skal fremelskes kultur i teamet, hvor der er okay at lave fejl (fejl må ikke skjules) Projektleder skal turde og give teamet frihed og magt (projektleder er nu coach) Forandringsledelse Projektleder skal have fokus på forandringsprocesser I de følgende afsnit, vil vi behandle disse tre hovedområder ved at sammenholde relevant litteratur med den viden interviewene bragte for dagen. 5. Omstilling i forhold til Organisation Under interviewet kom der pointer frem, der handler om teamet, som omstiller sig til agil udvikling, og dets rolle i forhold til resten af organisationen. Disse vil blive behandlet i nærværende afsnit. Vi vil især lægge vægt på de problemer, der kom frem og belyse hvordan litteraturen omtaler disse. Side 7 af 31 - Fra vandfald til agil projektmodel 5.1 Grundlæggende egenskaber I artiklen 'Agile Suitability Filters' af Mike Griffiths (Griffiths 2007) fremføres det, at der er visse projekter, der simpelthen ikke egner sig til agil udvikling, og at det er en god ide at kontrollere disse ting inden, man kaster sig ud i at skifte al sin udvikling til agil. Det er også en vigtig pointe ved den artikel, at det i praksis ikke er et binært valg: det er ofte hensigtsmæssigt at tage de dele af agile og vandfaldsbaserede metoder til sig og bruge dem i et givent projekt, såfremt det passer bedst ind i projektet og i den organisation, det er en del af (Griffiths punkt 1, "Slider"). Griffiths refererer til et ’radar chart’, der er omtalt i Boehm og Turners bog (Boehm og Turner 2003). Pointen med denne figur er, at der i hvert fald er fem faktorer, der skal overvejes, når man beslutter, hvorvidt man vil køre sit projekt hovedsageligt efter agile metoder eller efter vandfald. De er listet her: Holdets sammensætning: hvor mange folk på projektet er nybegyndere i forhold til antallet af erfarne folk? Tesen er, at jo mere erfarne folk, der er i teamet, jo mere sandsynligt er det, at agilt er passende for projektet. Projektets dynamik: hvor sandsynligt er det, at projektets specifikationer ændrer sig i projektets løbetid? Det er i sagens natur bedst at være agilt indstillet, hvis det er sandsynligt at krav løbende ændrer sig. Organisationens kultur: hvordan er organisationen indstillet på, at ting løbende kan ændre sig? Hvis der er tale om en rigid organisation, hvor hierarkiet er meget stramt, er det mindre sandsynligt, at agil udvikling vil føre noget godt med sig. Holdets størrelse: Hvis der er 5-10 på holdet, har de agile metoder bedre chancer, end hvis der er 500-1000 personer på projektet. Projektets betydning: Hvis der er tale om et projekt, hvor en rumfærge risikerer at styrte ned med 100 astronauter på landsdækkende TV, skal man tænke sig om en ekstra gang inden man slipper tøjlerne og går over til agil udvikling. I forhold til disse kriterier kan følgende bemærkes om NBT. Det er en anelse stort i forhold til det, Side 8 af 31 - Fra vandfald til agil projektmodel der anbefales i artiklen. På den anden side, er det ikke et projekt, hvor folk omkommer, hvis produktet er ude af drift i en kortere periode - dermed ikke sagt, at Netbutikken ikke er en væsentlig del af salgs-delen af DSB. Desuden skal det bemærkes at kunde og udviklingsafdeling, i denne sammenhæng, er indenfor samme organisation, så det kommer næppe til retslige tvister, hvis aftaler ikke overholdes. Som nævnt i introduktionen til NBT, kommer der ofte ændringer i krav til projektet og dette er i tråd med agile metoder. Fowler har endvidere nogle pointer, der skal overvejes, inden man begynder at overgå til agile metoder - se (Fowler 2000), afsnittet 'Should You go Agile'. De fleste er sammenfaldende med ovenstående, men han lægger desuden meget vægt på, at man skal involvere en person med erfaring - på den måde sparer man prisen for mange dyrekøbte erfaringer, som man ikke kan læse sig til. Dette er naturligvis sund fornuft i enhver stor omstilling i en virksomhed, og det fremgår af interviewet, at NBT netop hyrede konsulenter udefra for at imødegå nogle af disse problemer. 5.2 Om kunden der skal afgive magt I interviewet med projektlederen kom det frem, at kunden (DSB-IT) følte at de mistede indflydelse, idet de skulle frigive en masse timer uden helt præcist at vide, hvad de ville få tilbage for det. Vi vil her gennemgå, hvad Martin Fowler siger om denne problemstilling i hans artikel (Fowler 2000), og især i afsnittet om 'The Adaptive Customer'. Det er vigtigt at forstå, at kundens kontrol med projektet faktisk forstærkes med agil udvikling, i det omfang kunden selv lægger vægt i projektet. En del af pointen med agil udvikling er netop, at kunden efter hver iteration kan overvåge fremskridt og har indflydelse på hvilken vej, projektet skal køre videre. Andre vigtige pointer, forretningen skal indse er, at man hurtigere kan komme i produktion med beta-udgaver og tilpasse forretningen til softwaren. Det vigtigste er måske, at forretningen får et meget bedre billede af, hvad status i virkeligheden er på projektet: når man kører efter en på forhånd fastlagt plan, opstår det problem, at fremskridt bliver målt mod denne plan, og så gør folk meget for at skjule virkeligheden, og man opdager først sent, at der er problemer. I interviewet med forretningsansvarlige kommer det også frem, at han opnået denne indsigt og ser dermed fordele i at arbejde agilt. Side 9 af 31 - Fra vandfald til agil projektmodel Fowler har også en anden vigtig pointe i sit afsnit om krav-specifikationer. Det er vigtigt at indse at alt i software-udvikling afhænger af de krav, der stilles. Hvis man ikke har faste krav, kan man ikke udvikle efter en vandfaldsbaseret metode, hvor alt er planlagt fra starten af. Men på den anden side er det en glimrende pointe, at det faktisk er en stor fordel, at arbejde på en måde der tillader, at man kan komme med ændringer sent i projektet. Det er i sagens natur om ikke umuligt så i hvert fald besværligt for forretningsfolk på kundesiden at vide helt fra starten, hvad de i virkeligheden forventer af det software, de køber. Desuden sker det ofte, at virkeligheden/forretnings-konteksten ændrer sig, og dermed er det fordelagtigt at kunne ændre på kravene: de krav man stiller nu, kan sagtens ændre sig på grund af ændringer i lovgivning, konkurrencesituation eller andet. Dette argument er også fremført i kursets lærebog (Cadle og Yeates 2008), p. 79). I interviewet med Peter Wammen afspejles denne indsigt i, at teamet nu arbejder mere med såkaldte ”løsningsrum”, som betyder at en specifikation ikke behøver at være 100 % klar fra starten af et projekt. 5.3 Om tillid mellem organisation og team I interviewet kom det endvidere frem, at kunden følte, at de mistede en del kontrol ved overgangen til agil udvikling, da de ikke vidste præcist, hvad de fik leveret ved afslutningen af et projekt. Her vil vi belyse, hvad litteraturen siger om denne problemstilling. Det er en vigtig pointe og udfordring ved overgangen til agil udvikling, at der rent faktisk er ledere, der vil komme til at skulle udøve deres indflydelse på en anden måde end hidtil. Det er vigtigt for overgangen, at disse folk fra starten har indset, at det er en god ide at gå over til agil, ellers er der en stor risiko for at det ender i fiasko. Deemer har i en af sine cases illustreret, hvad der kan ske med et team, hvis en leder på et relativt højt niveau forfalder til de hierarkier, der fandtes inden overgangen til agil (Deemer 2009): i historien forfalder teamet til en slags 'worst of both worlds'-situation: der er ingen reel styring med teamet, da projektlederen forventer, at de arbejder agilt, men samtidig er folkene i teamet blevet så desillusionerede, at de forventer styring oppefra, før de foretager sig noget. Det er en situation, der er fatal for overgangen, og som skal undgås. Det må være op til topledelsen at gennemtrumfe og overbevise om, at overgangen skal finde sted. For at hjælpe med dette kan man eventuelt bruge de argumenter, der er fremført i denne opgave. Det er givetvis værd at lave undersøgelser af den interne modstand i organisationen inden man starter. Under alle omstændigheder er det ikke til at komme udenom, at det altid vil møde Side 10 af 31 - Fra vandfald til agil projektmodel modstand, fordi der er nogen folk, der vil sidde tilbage med en følelse af at have mistet indflydelse. Man kan endda tage det så langt, at man er opmærksom på denne modsætning i fremtidig rekruttering. Hvis man skriver eksplicit i jobannoncer, at man kører agilt, og måske endda understøtter rekrutteringsprocessen med personlighedstests, kan man komme nærmere en situation, hvor alle har den åbenhed overfor forandringer, der er en forudsætning for at agile processer blive en succes. Dette afslutter sammenfatningen af de organisatoriske udfordringer, der kan forekomme ved omstillingen af et team fra traditionel, vandfaldsbaseret udvikling til agil. I det næste afsnit vil vi se nærmere på de problemstillinger, der kan forekomme internt i et team, der skal implementere en sådan forandring. 6. Udfordringer internt i teamet NBT benytter ”Scrum” som projektmodel hvor selvstyrende grupper, er et af de vigtigste principper (Beck, et al. 2001). Selvstyrende grupper er karakteriseret ved, at et mindre antal medarbejdere - fx 5-10 - indgår i et snævert samarbejde om at tilrettelægge og udføre arbejdsprocesserne. Gruppen er som helhed ansvarlig for at opnå et på forhånd fastsat resultat. Gruppen fastlægger selv arbejdstidens anvendelse og afgør selv, om den skal have en leder og i givet fald hvem. Det normale er også, at gruppen selv afgør, hvem der skal være medlem af gruppen (Apropos u.d.). 6.1 Samarbejde Under interviewet med projektlederen fremgik det, at der ligger en stor udfordring i samarbejdet internt i teamet. I artiklen ’Selvstyrende Faldgruber’ (Busch-Jensen u.d.) fremgår det, at der er mange problemstillinger, der spiller ind. I en selvstyrende gruppe som selv har ansvaret for arbejdet, vil gruppens medlemmer som regel føle en større forpligtelse til at få opgaverne til at lykkes. Som medlem af gruppen står man ikke til ansvar over for en arbejdsleder, men over for sine arbejdskammerater. Ønsket om at være en god og loyal kollega kan betyde, at den enkelte påtager sig mere arbejde end forsvarligt er. Dette kan ende med at skabe en stress-situation. De mekanismer, der regulerer en selvstyrende gruppes indre liv, er grundlæggende de samme som i almindelighed kendes fra såkaldte uformelle grupper, dvs. gruppenormer, gruppepres, uformelt lederskab, psykologisk dominans, status og i værste fald hakkeorden, jantelov og mobning. Det Side 11 af 31 - Fra vandfald til agil projektmodel naturlige i en selvstyrende gruppe er at søge fuldstændig enighed - konsensus. Ofte er der faktisk ikke tid til at nå frem til ægte konsensus, hvilket aflejrer en vis portion modvilje og frustration; uenigheden er i virkeligheden ikke blevet løst. Der vil altid dukke situationer op, hvor det ville give et tåbeligt resultat at følge reglen i stedet for at bruge sin faglige dømmekraft. Derfor kan man iagttage den mekanisme, at hver gang der har været problemer med en regels overholdelse, giver man sig efterfølgende til at indføre en ny mere detaljeret regel for at forebygge fremtidige konflikter. Derved skabes en stadig vækst i mængden af forskrifter, som med tiden bliver mere og mere detaljerede. Det paradoksale resultat bliver, at den indflydelse på arbejdsopgaver og -vilkår, som den enkelte opnår via kollektivet, betales med en forringet grad af selvstændighed i det individuelle arbejde. Med til signalementet af den destruktivt fungerende selvstyrende gruppe hører endelig også, at det kan være særdeles svært for nye medlemmer at komme ind i gruppen. Ofte vil den nyankomne forsøges placeret i bunden af hierarkiet, og vil være nødt til at kæmpe hårdt, hvis hun vil skaffe sig en bedre position. Projektlederen i NBT peger selv på et svar på udfordringerne: ”Der skal fremelskes en kultur i teamet, hvor der er okay at lave fejl (fejl må ikke skjules)”. Kulturen skal udbygges og vedligeholdes så generelle værdier, normer og roller for teamets arbejde og funktion er klare. Der skal fokuseres på teamets faglige kompetencer frem for regelrytteri og administration. Hertil hører at teamets medlemmer bør uddannes løbende for at lære og tilegne sig kompetencer til deltagelse i et agilt selvstyrende team. 6.2 Projektleder skal turde give teamet frihed og magt Projektlederen nævner, at det er vigtigt at fordelingen af ansvar og opgaver mellem teamet og projektlederen ændres i forhold til traditionel fordeling. Ser man på erfaringerne fra artiklen ’Selvstyrende Faldgruber’ (Busch-Jensen u.d.) er det tydeligt, at det er meget vigtigt at håndtere denne omfordeling korrekt. I selvstyrende grupper kan der udvikle sig en kultur af konfliktundvigelse hånd i hånd med ledelsesresistens, dvs. en stærk uvilje til at nogen udefra skal blande sig i gruppens indre anliggender. Selvstyrende grupper, som er mindre godt fungerende, vil ofte hævde et ligheds-/retfærdighedsprincip: Der skal være ens vilkår for alle, der skal ikke være nogen, der slipper lettere end andre. Det sker, at det dominante flertal i en selvstyrende gruppe Side 12 af 31 - Fra vandfald til agil projektmodel beslutter, at der - f.eks. i forhold til en eller flere brugere/klienter - skal handles på en måde, der er i strid med arbejdsgiverens krav eller givne regler for arbejdets udførelse, det være sig arbejdsmiljøloven, den sociale servicelov eller andet. Der kan opstå millimeterretfærdighed i forhold til kolleger, som af den ene eller den anden årsag ikke har den samme kvalitative eller kvantitative arbejdskapacitet som resten af gruppen. Mange selvstyrende grupper er derfor ikke særligt gode til at tage hensyn til de lidt svagere kolleger, og det gør det ikke bedre, hvis gruppen som helhed er udsat for et overvældende arbejdspres. Når der i en selvstyrende gruppe udvikler sig normer, som er klart uønskværdige, fordi det medfører, at kvaliteten af arbejdet rent faktisk lider skade, kan dette meget vel gå for sig i en længere periode, uden at ledelsen bliver bekendt med det, jfr. det tidligere nævnte om ledelsesresistens. Det er tillige nærmest uundgåeligt, at de uløste uenigheder og konflikter, der måtte være i gruppen, foranlediger mængder af skyllerumssnak og sladder i krogene, hvilket kan stjæle ganske meget tid og opmærksomhed fra det egentlige arbejde. Det er meget vigtigt for NBT at gøre sig klart de vanskeligheder, der ligger i den nye omfordeling af opgaver og ansvar. Der skal frem for alt være helt klare grænseflader mellem de omgivende organisatoriske enheder og teamet. I forholdet mellem DSB-IT, NBT og driften er der klare beskrivelser af roller og ansvar. Projektlederen får mere en rolle som coach internt i teamet, hvor han skal være proaktiv og hele tiden forsøge at hindre, at de nævnte faldgrupper opstår og udvikle sig internt i teamet. Et vigtigt redskab i denne forbindelse er kendskab/fokus på forandringsledelse, som behandles i et senere afsnit. 6.3 Kvalifikationer for gruppens medlemmer Projektlederen tilkendegiver i interviewet, at teammedlemmer med bestemte personlige karakteristika er bedre egnede til at arbejde i et agilt team. Ligeledes nævnes, at der er nogle personer, der er stoppet da de ikke kunne affinde sig med at arbejde under disse rammer og former. Det er helt klart, at skal de nævnte faldgruber undgås, kræver det, at alle gruppens medlemmer besidder visse særlige kvalifikationer. At være med til at få en selvstyrende gruppe til at fungere godt kræver, at man er i besiddelse af overblik, fleksibilitet, gode kommunikationsfærdigheder og menneskelig indlevelsesevne, at man mestrer den svære kunst at være uenige uden at blive uvenner, og at man har en naturlig sans for konstruktiv og saglig konflikthåndtering (Busch-Jensen u.d.). En selvstyrende gruppe sammensat af personer med disse kvalifikationer kan skabe ganske Side 13 af 31 - Fra vandfald til agil projektmodel imponerende resultater med hensyn til kvalitetsarbejde, produktivitet og høj arbejdsmoral (BuschJensen u.d.). Det må antages, at hovedparten af medarbejderne på IT-udviklingsprojekter har en længerevarende uddannelse bag sig, og dermed har visse forventninger til, at de i deres arbejdsliv kan udfolde deres kreativitet og selv tage ansvar. Idet agile metoder netop lægger op til at alle medarbejdere, også de 'menige' medlemmer af projektgruppen, skal tage mere ansvar og udfolde kreativiteten, kan det meget vel være at den generelle medarbejdertilfredshed udbygges i et agilt team. Hvilket kan værre med til at højne kvaliteten, både fordi medarbejderne er mere motiverede i hverdagen, men også fordi de overordnet set, må antages at blive længere på arbejdspladsen. Fowler illustrerer denne pointe med afsnittet om 'plug compatible units' i sin artikel (Fowler 2000). Tilbage bliver spørgsmålet om, hvad skal man stille op med de medarbejdere, som ikke kan leve op til disse kvalifikationskrav, men som måske er fagligt og teknisk meget kvalificerede. 7. Forandringsledelse Det er den interviewede projektleders holdning, at det er vigtigt ved overgangen at have fokus på forandringsprocesser, dog havde han ikke kendskab til teorierne på daværende tidspunkt, men han arbejdede i stedet primært med ærlighed for at skabe tillid i teamet. I det følgende vil vi først skitsere, hvad vi i opgaven forstår ved forandringsledelse og dernæst give forslag til, hvilke værktøjer og ledelsesstrategier DSBs projektleder med fordel kunne have lænet sig op ad ved overgangen fra vandfald til agilt arbejdsmiljø. Kendskabet til disse værktøjer og strategier kunne have gjort overgangen endnu mere succesfuld og tryg, da kendskabet til forandringsledelse giver nogle brugbare og konkrete referencerammer for projektlederen og dermed indirekte også for medarbejderne. ”[..] forandringsledelse er en måde at bygge bro mellem den forventede og ønskelige omstilling og tryghedsfølelsen blandt dine medarbejdere” (Lederweb, 2008). I opgaven forstås forandringsledelse at bestå af brugbare værktøjer, som projektlederen kan gribe fat i, hvis denne er i tvivl om, hvordan han skal håndtere forandringen. Endvidere vurderes en projektleders succesfulde håndtering af en ændring at hænge sammen med involvering af medarbejdere på alle stadier i projektet, således at de engagerer sig i projektet ( (Cadle & Yeates, 2008), p. 331). Side 14 af 31 - Fra vandfald til agil projektmodel Forandringsledelse er en løbende proces og det er projektlederens rolle at forberede medarbejderne på ændringen. Først og fremmest er det vigtigt at fortælle medarbejderne om ændringen i god tid (Lederweb, 2009). Det er også vigtigt, at ændringen sker gradvist, så medarbejderne ikke bombarderes med ændringer, men derimod gives tid til at forholde sig til nyt ansvar, processer og arbejdsmiljø ( (Cadle & Yeates, 2008), p. 332). Dernæst er det vigtigt, at forklare formålet med forandringerne så medarbejderen forstår nødvendigheden af ændringen og får de positive aspekter ved omvæltningen forklaret grundigt (Lederweb, 2009). Ligeledes er det vigtigt, at medarbejderne har mulighed for at udtrykke utilfredshed, frustration, diskutere, samt at få svar på det spørgsmål, som er helt centralt i alle typer forandringer: Hvad betyder det for mig? (Lederweb, 2008). Det er projektlederens rolle at være godt forberedt og give tilfredsstillende svar på spørgsmålene, så medarbejderne genvinder trygheden (Lederweb, 2008). Undersøgelser påpeger at ved en ændring er 60 % af medarbejderne typisk neutrale og afventende, 20 % er ændringssultne og glæder sig til forandringerne og 20 % holder af at fastholde hverdagens rutiner og er derfor skeptiske over for forandringsprocessen (Lederweb, 2007). Det betyder, at projektlederen skal have fokus på at sikre, at de 60 % neutrale ikke lader sig rive med af de medarbejdere, der yder modstand (Lederweb, 2007). Herved er det vigtigt, at projektlederen selv er åben overfor forandringen og lytter til evt. forslag fra medarbejderne. Det er altså meget vigtigt, ved en ændring i en virksomhed, at give medarbejderne plads til at ytre sig om deres bekymringer og frustrationer ved ændringen og herigennem at få renset luften en gang for alle, så alle igen kan se fremad og arbejde videre i den nye hverdag i et fornyet lys. Derudover er det lettere at få en ændring igennem, hvis projektlederen også formår at få skabt deltagelse og engagement blandt medarbejderne, så de er med på ideen og har lysten til at se mulighederne ved ændringen frem problemerne (Lederweb, 2009). Det er ligeledes gavnligt, som projektleder, at huske på, at medarbejderne ofte trækker på tidligere erfaringer, hvilket kan forklare evt. uforståelig modstand (Lederweb, 2009). Er det tilfældet, er det vigtigt at få snakket om virksomhedens ”ændringsfortid/mønster” med medarbejderne for at komme modstand mod den nye ændring i forkøbet og lære af gamle fejltagelser. En af de vigtigste elementer i forbindelse med at lede en forandring er projektlederens kommunikation med de forskellige interessenter, der bliver påvirket af forandringerne eller har interesse heri. Her er ’AABBCC’ modellen (Cadle & Yeates, 2008) p. 343 et godt værktøj, der kan bruges af projektlederen til at strukturere og målrette kommunikationen til de forskellige Side 15 af 31 - Fra vandfald til agil projektmodel interessenter. Interessenter til et forandringsprojekt vil nemlig have forskellige behov for information og det er derfor vigtigt at projektlederen segmenterer dem ud fra deres informationsbehov og målretter kommunikationen til hvert enkelt segment. Til at segmentere interessenter kan følgende to matricer anvendes "Mapping stakeholders power and interests" (Cadle & Yeates, 2008) p. 300 og "The change competence/commitment matrix" (Cadle & Yeates, 2008) p. 343. Matricen "Mapping stakeholders power and interests" vurderer interessenterne i forhold til magt og interesse, mens matricen "The change competence/commitment matrix" vurderer interessenterne i forhold til kompetence og engagement. Når projektlederen har segmenteret interessenterne bruges AABBCC modellen til at udforme en kommunikationsstrategi. Herved skaber projektlederen størst mulig support og accept af forandringsprocessen. I forhold til NBTs forandringsproces kan følgende interessenter nævnes. Vi har klassificeret dem i forhold til de nævnte matricer. DSB-ITs ledelse Medarbejdere NBT "Mapping stakeholders "The change competence/commitment power and interests" matrix" Low interest, high power(A) High competence, low commitment i Medium power, high interest Low competence, high commitment (B/D) Forretningsenheden High power, high interest i DSB High competence, high commitment (B) 7.1 Opsummering i forhold til forandringsledelse DSBs projektleder kunne med fordel have forberedt medarbejderne og andre interessenter på ændringerne i god tid ved at gøre brug af en kommunikationsstrategi og med udgangspunkt i denne at forklare medarbejderne formålet med ændringerne. Medarbejderne skal samtidig have mulighed for at snakke de nye ændringer igennem. Det betyder, at i så fald, at projektlederen havde fulgt ovenstående retningslinjer, så kunne evt. modstand være kommet bedre i forkøbet. Medarbejderne og projektlederen ville sandsynligvis have følt sig mere tryg ved overgangen til det nye arbejdsmiljø, da de havde haft konkrete referencerammer at støtte sig til. Side 16 af 31 - Fra vandfald til agil projektmodel 8. Samlet vurdering af omstillingen Vi har tidligere set på udfordringer ved omstillingen, som NBT har gennemgået. I nærværende afsnit vil vi vurdere, om forandringen af NBT har været indsatsen værd og en positiv forandring for DSB. En klar indikation af, at forandringen har været positivt er, at Peter Wammen (den forretningsansvarlige) tilkendegiver, at produkterne, som NBT leverer, har en højere værdi. Dette skyldes at der nu arbejdes med ”løsningsrum”, hvor forretningen og NBT i tæt samarbejde definerer produkter/løsningernes endelige udformning. Dvs. den agile projektmodel bidrager til en bedre udnyttelse af den forretningsmæssige og tekniske viden, der samlet set eksisterer i udviklingsteamet og forretningsenheden. Både projektlederen og den forretningsansvarlige mener, at teamets effektivitet er steget væsentligt. Det fremgår endvidere af interviewene, at behovene for forretningen ændres hurtigt. Det er derfor af stor værdi, at forretningen kan prioritere udviklingsopgaverne med kortere tidshorisont end tidligere muligt. Endelig må det forhold, at der i organisationen nu er fokus på at udbrede de agile processer, indikere, at NBT som ”foregangsteam” for implementering af agile processer med organisationens øjne har været en succes. Samlet set mener vi, at omstillingen har været en succes for DSB. Som i alle andre forandringsprocesser har forandringen medført stress, nedsat effektivt, utryghed og frustrationer i en periode. NBT har dog formået hurtigt at komme ude på den anden side med øget effektivitet, et tættere og mere konstruktivt samarbejde mellem forretningen og udviklingsteamet. Hvilket resulterer i produkter med en højere forretningsmæssig værdi, samt et team med en højere” team spirit”. Side 17 af 31 - Fra vandfald til agil projektmodel 9. Konklusion Omstillingen fra vandfaldsbaseret til agil udvikling giver en række udfordringer. Af de primære kan nævnes: kunden skal indstille sig på at samarbejdet med udviklingsafdelingen skal foregå på en anden måde end hidtil. Samtidig skal kunden planlægge og prioritere opgaver hyppigere og med en kortere tidshorisont end hidtil. Inden for teamet er det vigtigt at lære at samarbejde og at der vil udvikles en anderledes kultur. Man skal endvidere holde sig for øje, at der vil forekomme en omstillingsperiode, hvor teamets medlemmer skal lære den nye fordeling af roller og ansvar, hvilket afstedkommer lavere effektivitet. Man skal endvidere være opmærksom på at arbejde effektivt i en selvstyrende gruppe kræver særlige personlige kvalifikationer. I forbindelse med selve omstillingen er det vigtigt at have fokus på forandringsledelse, herunder udarbejdelse af en effektiv kommunikationsstrategi, der målrettes de enkelte interessenter. Det er vores klare opfattelse, at omstillingen af NBT fra en vandfaldsbaseret til agil projektmodel har været en positiv forandring for DSB. Side 18 af 31 - Fra vandfald til agil projektmodel Bibliografi Apropos. (u.d.). Apropos Kommunikation. Hentet fra http://www.aprokom.dk/cm232/ Beck, K., Beedle, M., van Bennekum, A., Cockburn, A., Cuningham, W., Fowler, M., et al. (2001). Principles behind the Agile Manifesto. Hentet fra agilemanifesto.org: http://agilemanifesto.org/principles.html Boehm, B., & Turner, R. (2003). Balancing Agility and Discipline: A Guide for the Perplexed. Boston, MA, USA: Addison-Wesley Longman Publishing Co., Inc. Busch-Jensen, N. (u.d.). mag-net.dk. Hentede 2010 fra http://www.mag-net.dk/faldgrup.htm Cadle, J., & Yeates, D. (2008). Project Management for Information Systems (5th edition udg.). England: Pearson/Prentice Hall. Deemer, P. (December 2009). Manager 2.0: The role of the Manager in Scrum. Hentet fra Scrum Alliance: http://www.scrumalliance.org/articles/148-manager--the-role-of-the-manager-in-scrum Fowler, M. (Juli 2000). The New Methodology. Hentet fra martinfowler.com: http://martinfowler.com/articles/newMethodology.html Griffiths, M. (2007). Agile Suitability Filters. Hentet fra leadinganswers.com: http://leadinganswers.typepad.com/leading_answers/files/agile_suitability_filters.pdf Lederweb. (3. December 2008). Forandringskommunikation. Hentet fra Væksthus for ledelse: http://www.lederweb.dk/Strategi/Forandringsledelse/Artikel/80177/Lederwebs-guide-tilforandringsledelse Lederweb. (4. juni 2008). Lederwebs guide til forandringsledelse - hvad, hvorfor og hvordan? Hentet fra lederweb.dk: http://www.lederweb.dk/Strategi/Forandringsledelse/Artikel/80069/Forandringskommunikation Lederweb. (3. juni 2009). Lyt til brokkehovederne. Hentet fra lederweb.dk: http://www.lederweb.dk/Strategi/Forandringsledelse/Artikel/80254/Lyt-til-brokkehovederne Lederweb. (29. august 2007). Sats på de ændringssultne. Hentet fra lederweb.dk: http://www.lederweb.dk/Strategi/Forandringsledelse/Artikel/79908/Sats-pa-de-andringssultne Side 19 af 31 - Fra vandfald til agil projektmodel Bilag 1: Spørgsmål til interview Med udgang i udvalgte artikler og teori, opstilles en række spørgsmål til projektlederen.. Endvidere stilles nogle mere generelle spørgsmål til hhv. projektlederen og repræsentanten for forretningsenheden, for at forsøge at belyse om der har været en effekt af at omstille teamet til agile rammer for udvikling. Spørgsmål til Projektlederen Omstilling fra vandfald til Agile (Teamet) Overordnet skal organisationen acceptere en “adaptiv” tilgang til systemudviklingen Det betyder at accept af at krav til løsninger ændres hele tiden og accept af at bruge en iterativ model for at imødegå skiftende krav, jf. ‘The New Methodology.’, Fowler, Martin. Den traditionelle rolle for en leder, i en virksomhed, er baseret på en model kendt som ”kommando og kontrol”. Scrum er baseret på et anderledes princip: Selvstyrende grupper, jf. ‘The New Methodology.’, Fowler, Martin. I den simple betydning er Scrum lederen mindre kontrollerende, men mere en mentor, ”guru” for teamet, som hjælper til at teamet lærer, vokser og bliver effektive, jf. ‘Manager 2.0: The role of the Manager in Scrum.’, Deemer, Pete. Følgende Spørgsmål stilles: I hvilke dele af organisationen er der henholdsvis opbakning/modstand til implementering af Agile processer? Hvilke udfordringer har generelt været de største i forbindelse med at omstille NBT til at køre Agilt? Hvilke udfordringer er størst for henholdsvis udviklere, testere og projektledere i forbindelse med at omstille sig til at arbejde Agilt? Hvad er de vigtigste erfaringer du har gjort dig som projektleder ved at omdanne et team fra at arbejde efter vandfaldsprincipper til at arbejde agilt? Hvad er det bedste råd du kan give til en projektleder der skal til at omstille et udviklingsteam til at køre agilt? Omstilling fra vandfald til Agile (Risici) Side 20 af 31 - Fra vandfald til agil projektmodel Det næste skridt af selvorganisering sker gennem “sprintet”, når teamet samarbejder tæt for at beslutte hvem der udfører de enkelte opgaver og sikrer at alt arbejder færdiggøres, jf. ‘Manager 2.0: The role of the Manager in Scrum.’, Deemer, Pete. Problemer opstår når organisationen taler om den selvstyrende grupper, men glemmer dette når ting bliver vanskelige, jf. ‘Manager 2.0: The role of the Manager in Scrum.’, Deemer, Pete. Der tages udgangspunkt i en risiko analyse, jf. Cadle, James, og Donald Yeates, kapitel 15, side 262, hvor følgende risici er interessante i denne kontekst: • • • • Ingen tilslutning til projektet Modstand mod forandring Ledelse og brugere ikke enige Udviklere mangler nøgle kompetencer Følgende Spørgsmål stilles: Hvor lang tid gik der fra du implementerede de første agile tiltag til teamet arbejdede mindst lige så effektivt som de gjorde, da de arbejdede efter vandfaldsprocesser? (indlæringskurve) Vurderer du at teamet er mere effektivt nu end før, og kan du sætte procent på? Oplevede du at teamet til at begynde med havde problemer ved at tage det ansvar på sig, som agile processer forudsætter? Og hvad gjorde du evt. for at få det til at lykkedes? Hvilke fremtidige udfordringer ser du i forhold til at videreudvikle de agile processer i NBT? (eventuelt gå videre til de spørgsmål, der handler om Kanban). Mener du at teammedlemmer med bestemte personlige karakteristika er bedre egnede til at arbejde i et Agilt team? Hvilke karakteristika er gode? Hvad har du som projektleder rent forståelses/koncept selv måtte arbejde mest under omstillingen til at køre agilt? Omstilling fra vandfald til Agile (Kunden / System ejer ”DSB-IT”) Kunden (System ejer) skal acceptere og forstå den adaptive process. Det betyder at viden om forretningen/krav/beslutninger skal være til rådighed når som helst og at accept af at succes ikke måles ift. en plan med opfyldelse af tid og omkostninger, jf. ‘The New Methodology.’, Fowler, Martin. Hvis der eksisterer en fundamental tro på effektiviteten af “Kommando og Kontrol” i topledelsen og en stor afhængighed af “trusler” og “afstraffelse” som ledelsesværktøj, vil det blive meget svært at lave en transformation til den nye måde at tænke på Side 21 af 31 - Fra vandfald til agil projektmodel , jf. ‘Manager 2.0: The role of the Manager in Scrum.’, Deemer, Pete. Følgende Spørgsmål stilles: Har der været udfordringer i forhold til forretningsenheden med at forstå fordelene ved at køre agilt? Har der været udfordringer i forhold til at få andre afdelinger i DBS til at følge NBT’s takt? (F.eks., forretningsmæssige afklaringer og leverancer) Hvad gøres der i DSB for at udbrede de agile processer i resten af organisationen? Omstilling fra vandfald til Agile (Ledelse) Organisatoriske krav: Accept af at udviklere og andre personer involveret IKKE er ressourcer med roller, men dygtige mennesker med kvalifikationer, som ikke bare kan udskiftes med andre. Ledelsen af processen skal være menneskeorienteret og kræver ”commitment” af alle involverede. Accept af at ”delegatory management” er påkrævet til fordel for traditional “measurement-based management” , jf. ‘The New Methodology.’, Fowler, Martin. ”Scrum” er baseret på et anderledes koncept: Det selvstyrende team. Forskellen er tydelig, allerede fra det første trin som teamet tager. I ”Scrum” beslutter teamet hvor meget arbejder der accepteres i et ”Sprint”,jf. ‘Manager 2.0: The role of the Manager in Scrum.’, Deemer, Pete. Erfaringer viser at når teamet selv beslutter meget arbejde der kan accepters, og at dette er realistisk, så vil teamets focus og motivation øges hvilket giver bedre resultater, jf. ‘Manager 2.0: The role of the Manager in Scrum.’, Deemer, Pete. En af de største udfordringer i overgangen til selvstyrende grupper er at teamet ikke vil begynde at organisere internet i teamet, før alle udenfor teamet er stoppet med at lave ”micromanaging”, jf. ‘Manager 2.0: The role of the Manager in Scrum.’, Deemer, Pete. Følgende Spørgsmål stilles: Har NBT-teamet fået mere indflydelse på hvordan opgaver løses efter skiftet til at køre agilt? Har der været eksempler på konflikter med andre dele af organisationen, der bunder i at NBTteamet arbejder agilt og de ikke gjorde? Er der opbakning fra andre del af organisationen til at resurserne i et agilt team helst skal være 100% allokerede? Side 22 af 31 - Fra vandfald til agil projektmodel Forandringsledelse Vi vil gerne belyse om der er anvendt forandringsteori i forbindelse med den løbende proces som en overgang til den agile organisering og arbejdsmetodik, jf. Cadle, James, og Donald Yeates, kapitel 20, ”Managing Change” Har du brugt teorier vedr. forandringsledelse ifm. Omstillingen af teamet til at køre agilt? Har du generelt måttet arbejde med teammedlemmernes motivation under de procesmæssige forandringer? Generelt Hvad er de største fordele og ulemper ved at køre agilt? Side 23 af 31 - Fra vandfald til agil projektmodel Bilag 2: Interview med Carsten Solvang Omstilling fra vandfald til Agile (Teamet) Hvilke udfordringer har generelt været de største i forbindelse med at omstille NBT til at køre Agilt? 2001: Kodebasen skal være agil for at man kan køre agilt (koden skal være løst koblet, så det bliver muligt at tilføje ændringer i mindre bidder. Processer for kvalitetssikring er en forudsætning for at kunne køre agilt. Dette er en svær opgave og kræver at man implementerer unit test. Pointen er at man kun skal bruge energi på at teste den mere ekstreme brug af systemet i stedet for at bruge energi på regressionstest som det bruges meget energi på i dag. Den overordnede ide med at kvalitetssikre er at sikre at man ikke skubber teknisk gæld foran sig. Man vil nemlig have en tendens til at skrive dårlig kode hvis det ofte opstår tidspunkter hvor man har kort tid til at idriftsætte (apile processe betyder jo at det hele tiden idriftsættes) I 2001 indførte eksterne konsulenter unit test, user story, releaseprocedurer (RFC, idriftsættelses dokumenter) Organisationen er i dag mere parat til at implementere agile processer fordi der er styr på processerne vedr. RFC, ITEL...osv. Hvilke udfordringer er størst for henholdsvis udviklere, testere og projektledere i forbindelse med at omstille sig til at arbejde Agilt? Udviklere: Det er svært for udv. at forstå hvordan opgaver skal nedbrydes til US. Og de har ligeledes udfordringer ved at sætte task på opgaverne og estimere dem. Skal lære at forstå at de ikke bliver holdt op på deres estimater. Arbejde sammen som et team og lære at samarbejde med hinanden. Carsten (CSV) forsøgte med ledelses metoder at skabe en god stemning i gruppen. Testere: Skal lære at være en integreret del af udviklingsteamet. De skal have fokus på den nuværende leverance og mindre fokus på regressionstest (da regressionstesten er ved at bliver automatiseret). Side 24 af 31 - Fra vandfald til agil projektmodel De skal kunne teste alle US i så god tid, at alle US kan nå at blive testet inden kodestop for den pågældende iteration. Testforløbet efter kodestop skal udelukkende være en brugertest, samt test af de mere ekstreme anvendelser af systemet og loadtest. Projektleder: Lede mennesker gennem forandringsproces er det sværeste. Man skal være meget vedholdende. Forstå hvordan man bryder opgaven ned i små US, der hver især skaber værdi for slutbrugeren. Projektledere er normalt vant til at opdele opgaven i backend, frontend...osv. Har svært ved at give teamet fri og give teamet magt (turde stole på at teamet kan nå det de har comitted sig til). Det er meget svært for projektlederen at skifte ledelsesstil til at være coach (nu skal teamet styre sig selv). Sikre at testmiljøer og andre forudsætninger kører tilfredsstillende til at teamet kan comitte sig. Der er meget svært at få kunden til at stille kravene agilt (agere agilt) og derfor er det svært at få teamet til at agere agilt. (at kunden stiller opgaver agilt, betyder at opgaver defineres mere overordnet og som hovedregel beskrives i US. Ved meget tekniske opgaver kan der dog være behov for at udarbejde en del teknisk dokumentation før US kan skrives. Det betyder ligeledes at kunden skal involvere sig meget mere i projekter og være parat til med kort varsel, at kunne tage forretningsmæssige beslutninger og afklaringer). Hvad er de vigtigste erfaringer du har gjort dig som projektleder ved at omdanne et team fra at arbejde efter vandfaldsprincipper til at arbejde agilt? Teamet bliver mere positivt af at køre Agilt og der skabes mere teamspirit. De er glade for at have fået mere ansvar og indflydelse. Der er generelt flere personer der egner sig til at køre agilt end vandfald (rent personlighedsmæssigt). Hvad er det bedste råd du kan give til en projektleder der skal til at omstille et udviklingsteam til at køre agilt? Man skal erkende at det er en forandringsproces. Man bør bruge ledelsesteori vedr. forandringsledelse for at holde motivationen i teamet oppe. Skal vide at det tager tid og man skal opstille delmål, så man skaber små sucesser på vejen mod det overordnede mål. Man skal ud og sælge konceptet til ledelsen og forretningen i organisationen. Side 25 af 31 - Fra vandfald til agil projektmodel Man kan bruge buzzworded "SCRUM" til at sælge det agile udviklingskoncept til organisationen. (Det har Carsten gjort i DSB). Hvor lang tid gik der fra du implementerede de første agile tiltag til teamet arbejdede mindst lige så effektivt som de gjorde, da de arbejde efter vandfaldsprocesser? (indlæringskurve) Ca. 6 mdr. - 1 år, fordi kodebasen skulle skrives om til at være mere løst koblet. Lige så snart man har forstået at opdele en udviklingsopgave i US og kan levere i korte iterationer og prioritere dem løbende, så har man et team der skaber mere værdi ved at køre agilt end ved at køre vandflad. Vurderer du at teamet er mere effektivt nu end før, og kan du sætte procent på? Et meget usikkert estimat vil være 25 - 50 % mere effektivt. (fordi der skabes mindre fejl og tilbageløb). På de sucessive kalkulationsark kan man se at der ved agil udvilling er 15 % flere kodetimer i forhold til de administrative timer (agilt: Kode udgør 60 - 70 % vandfald: 45 - 55 %). Der skabes mere forretningsmæssig værdi fordi man hele tiden laver det der er mest relevant for forretningen. Oplevede du at teamet til at begynde med havde problemer ved at tage det ansvar på sig, som agile processer forudsætter? Og hvad gjorde du evt. for at få det til at lykkedes? Ja, det kræver en del ledelse for at få teamet til at tage ansvar. Hvilke fremtidige udfordringer ser du i forhold til at videreudvikle de agile processer i NBT? (eventuelt gå videre til de spørgsmål, der handler om Kanban). Implementere LEAN og KANBAN. Målet er at få fjernet der sidste spild (mindre fejl, mere jævnt flow, samt løbende og oftere idriftsættelser). Omstilling fra vandfald til Agile (DSB-IT) Har der været udfordringer i forhold til forretningsenheden med at forstå fordelene ved at køre agilt? Ja, de følte at de miste kontrol fordi de skulle frigive en masse timer uden at vide hvad de helt præcist fik leveret. Der er skræmmende for forretningen ikke præcist at vide hvad de før leveret i enden. Det skal skabes tillid mellem teamet og forretningen. Side 26 af 31 - Fra vandfald til agil projektmodel Har der været udfordringer i forhold til at få andre afdelinger i DBS til at følge NBT’s takt? (F.eks., forretningsmæssige afklaringer og leverancer) Der har været problemer med idriftsættelser, da organisationen ikke var vandt til at teams idriftsatte så ofte som det er nødvendig ifm. agil udvikling. Måtte selv udarbejde idriftsættelsesdokumenter (inden ITLE procedurer blev implementeret) De andre udviklingsafdelinger skulle lære at Netbutikken hele tiden idriftsatte og dermed ændrede koden (de skulle vide hvad vi idriftsatte, derfor udarbejdede vi idriftsættelses dokumentation) Hvad gøres der i DSB for at udbrede de agile processer i resten af organisationen? Fra 2009 og frem har der været meget fokus på at udbrede de agile processer. Der har været afholdt et stort møde på Ingelas niveau, hvor det blev vedtager at der skulle udarbejdes en agil handlingsplan. De er nu igang med at lave denne plan. Projektlederene at ved at snuse lidt til hvad agile processer er og Carsten coacher nogle af dem. I hvilke dele af organisationen er der henholdsvis opbakning/modstand til implementering af Agile processer? Andre dele af organisationen har udvist modstand for at NBT implementerede agile processer. Modstand fra afdelingsniveau i DSB IT (Udviklingschefen ønskede at fastholde traditionelle estimater som indeholdt krav. spec.). Det er blevet bedre, men der er stadig modstand Systemafdelingen (DSB iT) (en afdeling der ikke eksisterer mere) gjorde alt for at modarbejde agile tiltag. De krævede at man skulle booke resurser til konkrete opgaver ud i fremtiden og ellers forsvandt resurserne. Derfor var NBT teamet i en periode nede på kun at have 2 - 3 mand. Problemet er nu blevet løst, ved at man kan allokere resurser i store blokke og så hen ad vejen ligge konkrete opgaver ind i denne blok. Modstanden fra forretningen har været af varierende styrke og lige nu er der stor opbakning fra forretningen. Det har klart hjulpet at forretningen deltager meget i teamets arbejde og derfor forstår vores processer. Forretningen er nu en hjælpende hånd og støtter implementering af agile processer. Har NBT-teamet fået mere indflydelse på hvordan opgaver løses efter skiftet til at køre agilt? Der kan ikke svare ordentligt på dette spørgsmål. (Teamet er begyndt at tage mere ansvar på det seneste). Side 27 af 31 - Fra vandfald til agil projektmodel Har der været eksempler på konflikter med andre dele af organisationen, der bunder i at NBTteamet arbejder agilt og de ikke gjorde? Nej, der har ikke været de store konflikter. NBT har forsøgt at tilpasse sig, så der ikke er opstået konflikter. Er der opbakning fra andre del af organisationen til at resurserne i et agilt team helst skal være 100% allokerede? Der er en accept, men ved ik om der er opbagning. NBT er et højt prioriteret projekt og derfor er det nemmere at få resurserne booket 100 %. Generelt Hvad er de største fordele og ulemper ved at køre agilt? Efter kort til har man udviklet funktionalitet som kunden kan prøve og test og derfor agere i forhold til. På baggrund heraf får forretningen en bedre forståelse for opgaven og kan bedre få ideer til hvad der skal komme i fremtiden. Kort afstand fra ide til brugbar kode (kode er hurtigt ude og skabe værdi for forretningen). Der bliver bundet færre penge i udviklingsopgaverne inden de er ude og skabe værdi. Det er et minus at forretningen skal ligge mere energi i udviklingsprocessen. (Men det skal forstås sådan, at det mere er et problem ved traditionel udviklings metoder at forretningen ikke deltager nok og derfor resulterer dette ofte i projekter der ikke opfylder kundernes behov når de er færdige). Det kan være et problem, at kommunikere hvad forretningen vil få leveret og hvornår de får det leveret. Forandringsledelse Har du brugt teorier vedr. forandringsledelse ifm. Omstillingen af teamet til at køre agilt? Ja, jeg har formentlig brugt forandringsledelses teorier, men det har været uden at kende til dem. Jeg arbejdede derfor primært med ærlighed for at skabe tillid i teamet. Har du generelt måttet arbejde med teammedlemmernes motivation under de procesmæssige forandringer? Ja, det skal der arbejdes med. Så man skal være tålmodig og give folk tid til at forstå forandringerne. Har teammedlemmer forladt projektteamet fordi de ikke kunne/ønskede, at omstille sig til at køre Agilt? Hvad gjorde du for at forhindre dette? Ja, vi har mistet nogle udviklere fordi de ikke kan lide at der skiftes retning hver 2 uge. Det kræver en høj forandringsparathed af udviklerne. Side 28 af 31 - Fra vandfald til agil projektmodel Nogle udviklere synes at agil udvikling er meget kontrollerende fordi man hele tiden skal vise hvad man har kodet til teamet. De skal lære at det er okay at fejl kommer frem i lyset. Det skal være accepteret at leve fejl. Personlige egenskaber Mener du at teammedlemmer med bestemte personlige karakteristika er bedre egnede til at arbejde i et Agilt team? Hvilke karakteristika er gode? Lyst til samarbejde i et team Ønske at tage ansvar for arbejde Forandringsparathed Erfarne udviklere er vigtigt at have. Der skal som minimum være nogle udviklere med erfaring i teamet (man kan ikke have et team, der udelukkende består af nye udviklere) Man skal have tillid til sine teammedlemmer og vise at man stoler på sine teammedlemmer. Være åben og kommunikerende Hvad har du som projektleder rent forståelses/koncept selv måtte arbejde mest under omstillingen til at køre agilt? Det har været svært at videreformidle, at man nu skal levere koden i "tynde skiver" (det var ikke svært at forstå konceptet). Det var selve implementeringen af det der var svær. Det var ligeledes svært at finde ud af for man skulle starte med at ændre processerne? Hvis man ikke har erfaring med agil udvikling som projektleder er en god ting at få eksperter udefra til at hjælpe med at opstarte teamet til at køre agilt. Hvis man starter et helt nye team op med grønne udviklere og også selv som projektleder er nye inden for agil udvikling, så bør man helt sikkert have en konsulent til at hjælpe. Under alle omstændigheder er det en god ide for projektlederen at blive coachet under forløbet med at implementere de agile processer. Side 29 af 31 - Fra vandfald til agil projektmodel Bilag 3: Interview med Peter Wammen Mener du et NBT er blevet mere effektivt efter at de er begyndt at arbejde agilt? De projektteams der arbejder agilt har væsentligt mere effektive. Hvilke udfordringer har der været for forretningen ifm. At NBT er begyndt at arbejde agilt? Det er svært at kunne fasthold deadlines fordi man ikke har afklaret alle detaljer på forhånd. Derfor vil der under projektforløbet både komme forretningsmæssige ændringer af specifikationer samt ændringer forårsaget af tekniske udfordringer. Man kan ligeledes have en tendens til at estimere for lavt, da alle detaljer ikke har været diskuteret før projektstart. Der er et forøget arbejdspres fordi forretningen hele tiden skal stå til rådighed for at kunne afklare detaljer. Hvordan har omstillingen fra vandfald til agil helt konkret påvirket dine arbejdsopgaver? En specifikation behøver ikke at være 100% færdig fra start og derfor arbejder vi nu mere med løsningsrum hvor delopgaverne bliver specificeret gennem projektforløbet. Synes det er en stor fordel fordi man kan udnytte den samlede viden i både udviklingsteamet og forretningen og dermed ender vi op med et bedre slutprodukt end vi ellers ville have gjort. Føler du at du har mistet indflydelse på det endelige resultat af et projekt i forbindelse med at NBT er begyndt at arbejde agilt? Nej, jeg har stadig indflydelse på detaljerne. Er det en fordel/ulempe for forretningen, at projekter ikke er fuldstændig specificeret ved projektstart? Kan godt lide at der er et tættere samarbejde med IT, så forretningen nu bruger IT som sparringspartner på projekter. Det er en god erkendelse at hverken forretning eller IT er altvidende og derfor ikke kan specificere et projekt fuldstændigt på forhånd. Han kan derfor bedre lide at arbejde med løsningsrum og så i et samarbejde med IT afklare detaljerne i projekterne løbende gennem et projektforløb. Har det stor værdi for forretningen, at man hele tiden har mulighed for at ændre prioriteringen af opgaver? Ja, fordi omverdenen og specielt konkurrencesituationen gøre at mange beslutninger bliver ændret. Side 30 af 31 - Fra vandfald til agil projektmodel F.eks. planlægges udvikling kun 2 uger i forvejen og selv inden for disse 2 uger har vi ind imellem ændringer fordi der opstår nye behov i projektets omverden (dvs. beslutninger i organisationen). Side 31 af 31 - Fra vandfald til agil projektmodel Bilag 4: Identificerede udfordringer Udfordringer ved skiftet fra vandfald til agil Koden skal være løst koblet så ændringer til koden kan tilføjes inkrementelt. Processer for kvalitetsstyring og automatiserede test. Udviklere har svært ved at nedbryde opgaver til user stories og efterfølgende skrive tasks til user stories. Udviklerne skal arbejde sammen som et team og lære at samarbejde med hinanden. Testere skal have fokus på den nuværende leverance og mindre fokus på regressionstest Projektleder skal have fokus på forandringsprocesser Projektleder skal turde give teamet frihed og magt (projektleder er nu coach) Kunde skal turde stille opgaver ”agilt” (opgaver skal være mere overordnet beskrevet) Tillid mellem forretning og udviklingsteam skal opbygges, da forretning mister en del af kontrollen over det endelige resultat. Organisation skal geares til hyppige idriftsættelser Der skal fremelskes kultur i teamet hvor der et okay og lave fejl (fejl må ikke skjules) Det gode ved at gøre Agilt Teamet er mere positivt og har fået mere teamspirit (pga. mere ansvar og indflydelse) 25 – 50 % (usikkert subjektiv vurdering fra projektleder) Mindre fejl og tilbageløb i udviklingsproces. Der skabes mere forretningsmæssig værdi fordi backlog hele tiden prioriteres Forretningen kan løbende afprøve/teste den nye kode og heraf blive klogere på hvad der skal ændres og liges korrigere i deres oprindelige ”ønskeliste” til funktionaliteter. Kort forløb fra ide til færdig kode (færre resurser bundet i udviklingsforløbet) Tættere samarbejde mellem forretning og udviklingsteam
© Copyright 2024