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