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