Hvad er agil udvikling?

Agil udvikling er en projektledelsesmetodik, der vægter individer og interaktioner højere end processer og værktøjer. Det fokuserer på hurtigt at skabe fungerende software, hyppig samarbejde med kunder og let tilpasning til ændringer. Denne metode er særligt gavnlig for komplekse projekter eller projekter med usikre krav. Den agile proces kan opdeles i tre hovedfaser: forberedelse, sprintplanlægning og sprint. Agil udvikling er vigtig, da det sikrer, at udviklingsteams fuldfører projekter til tiden og inden for budgettet, forbedrer kommunikationen mellem udviklingsteamet og produktlederen og reducerer risici forbundet med komplekse projekter.

Uddannelse og træning

Alle medarbejdere bør trænes i agile metoder som f.eks. agil projektledelse, Scrum og Kanban. Det samme gælder for samarbejdspartnere fra forretningen.

Især er det vigtigt at centrale rollehavere som f.eks. projektledere, Scrum Masters og Product Owners bliver grundigt uddannet. Efter kursus vil sidemandsoplæring fra en agil coach øge træfsikkerheden og hastigheden af transformeringen.

Der også vigtigt at uddanne styregruppe og linjeledere i agil ledelse, så de forstår den agile tilgang samt kan understøtte deres medarbejdere.

Kultur

“Kultur drypper nedad.” Det er vigtigt, at ledelsen går i front for at skabe en kultur, hvor samarbejde og deling af viden er velkommen og opmuntret, da agile metoder er baseret på samarbejde og kommunikation.

Agile metoder fokuserer på at opfylde kundens behov og levere værdi hurtigt. Det er vigtigt at skabe en kultur, hvor kundefokusering er en prioritet.

Agile processer og agil udvikling

Start med at vurdere, hvor agile metoder skal indføres. Der vil sandsynligvis være tale om en sameksistens af flere forskellige agile rammeværk som f.eks. agile projekter til projektarbejde, Scrum til løbende produktudvikling og Kanban til at håndtere fejlrettelser.

Herefter kan I implementere agile processer i pilotprojekter og/eller -teams. Udvid derefter til flere projekter og teams. Der vil således være en overgang, hvor nogle teams arbejder agilt, mens andre stadig arbejder efter den traditionelle hierarkiske tilgang.

Tværfunktionelle teams

Opret tværfunktionelle teams, hvor medlemmer med forskellige færdigheder og kompetencer arbejder sammen på tværs af afdelinger for at opnå et fælles mål. Især i projekter er diversiteten vigtig.

Mål og monitorering

Det er vigtigt løbende at måle succesen – f.eks. i form af trivsel og fremdrift – af de agile projekter og justere processerne efter behov. Fokus på løbende forbedring bør være en del af afdelingens kultur.

Husk, at overgangen til Agile metoder ikke sker natten over, men med tålmodighed og engagement kan jeres afdeling gradvist blive mere agil og effektiv mens medarbejderne trives.”

Hvem taber mest ved overgangen til en agil måde at arbejde på?

Overgangen til en agil måde at arbejde på kan betyde en større forandring i måden, som en virksomhed driver og leverer sine produkter eller services på. Mens Agile metoder har mange fordele, kan der også være udfordringer og tab involveret i overgangen til Agile metoder. Herunder er nogle af de mulige tab, som kan forekomme ved overgangen til en agil måde at arbejde på.

Ledelsesmæssige tab

Overgangen til Agile metoder kræver ofte en ændring i den måde, som ledere driver og styrer projekter og teams på. Hvis ledere ikke er villige til at ændre deres tilgang og opgive en del af deres magt og kontrol, kan overgangen til Agile metoder mislykkes.

Tab af kontrol

Agile metoder kræver en større grad af autonomi og beslutningskraft på alle niveauer af organisationen. Hvis medarbejdere ikke kan håndtere denne nye grad af ansvar og frihed, kan projektet og organisationen lide tab.

Kulturelle tab

Overgangen til en agil måde at arbejde på kan være en udfordring for virksomhedens kultur. Hvis virksomhedens kultur ikke understøtter samarbejde, innovation og eksperimentering, kan overgangen til Agile metoder ikke lykkes.

Teknologiske tab

Agile metoder kræver ofte, at teams såvel som ”byggere” og repræsentanter for behovssiden (f.eks. forretningen) arbejder tæt sammen for at løse problemer og udvikle produkter samt services hurtigt. Hvis virksomhedens teknologiske infrastruktur ikke er tilstrækkelig fleksibel til at understøtte denne måde at arbejde på, kan det være et tab.

Tab af investering

Overgangen til Agile metoder kræver ofte en investering i uddannelse, træning og teknologi. Hvis organisationen ikke har de nødvendige ressourcer til at foretage denne investering, kan overgangen til Agile metoder ikke lykkes fuldt ud.

Det er vigtigt at huske, at mens der kan være nogle tab involveret i overgangen til Agile metoder, kan fordelene – som f.eks. at skabe fantastiske resultater med personale, der stortrives – ved en agil tilgang til arbejdet langt overstige disse udfordringer.”

Projektorganisationen – DSDMs roller og ansvarsområder

Helt fra starten i 1994 var DSDMs tilgang designet til at matche den stagegate-baserede tilgang PRINCE2. Det kommer bl.a. til udtryk i rollebesætningen. PRINCE2 og DSDM følger samme struktur med tre roller og en projektleder. Scrum har ingen af delene, og derfor er det en gåde for os, hvem der i et Scrum-setup skal tage sig af de opgaver, som en styregruppe og en projektleder tager sig af. Vores kunder har behov for, at der er klare roller og ansvar – også på disse områder. DSDM giver nogle meget anvendelige svar.

For at skabe en løsning i et projekt så effektivt og godt som muligt, er det afgørende, at samarbejdet mellem projektdeltagerne går som smurt. Derfor har DSDM udviklet forskellige roller til agile projekter, så både forretningens interesser, tekniske interesser, ledelsesmæssige interesser og proces-relaterede interesser for projektet repræsenteres. I agile projekter er det desuden meningen, at alle projektdeltagere arbejder tæt sammen for at opretholde god kommunikation uden misforståelser. Det er vigtigt for det gode resultat, at alle teams i projektet er overvejende selvstyrende og tager ansvar for deres beslutninger og handlinger. Indbyrdes på teamet bør man respektere hinandens viden og erfaringer, samt have mod til at udfordre arbejdsgangene med formål om hele tiden at forbedre arbejdsprocessen.

DSDM Team Model

I forbindelse med DSDMs forskellige roller i et projekt findes The DSDM Team Model, som demonstrerer strukturen og rollerne i et projekt. Farverne symboliserer hvilke interesser, den gældende gruppe repræsenterer.

• De orange roller repræsenterer forretningens interesser og besiddes ofte af folk fra selve forretningen eller kunden, der skal bruge den færdige løsning.
• De grønne roller repræsenterer de tekniske interesser og besiddes af dem, der er med til at udvikle løsningen
• De blå roller repræsenterer de ledelsesmæssige interesser og besiddes af bl.a. projektledere og Team Leaders.
• De grå roller repræsenterer de proces-relaterede interesser og besiddes af DSDM coaches og workshop-facilitatorer.

Når en rolle, såsom ved Business Analyst, har to farver i sig betyder det, at rollen repræsenterer to forskellige interesser og fx har fokus på både forretningens og de tekniske interesser.

Det er Business Sponsor, Business Visionary, Technical Coordinator, Project Manager og Business Analyst, der tilsammen styrer og koordinerer projektet. Business Sponsoren udvikler den overordnede strategiske vej og styrer projektets budget. Business Visionaryen og Technical Coordinatoren repræsenterer hhv. de forretningsmæssige og tekniske visioner for projektet. Til sidst er Project Manageren ansvarlig for at få projektet gennemført inden for de tids- og budgetmæssige grænser. Business Analysten fokuserer som sagt både på forretningens- og de tekniske interesser og kan derfor tage del i begge områders beslutninger.

Det er vigtigt, at alle projektroller fører en ledelsesstil, der ikke er kontrollerende, men giver plads til Solution Development Teamet, så de så selvstændigt som muligt kan udvikle den bedst mulige løsning.

Roller i Solution Development Teamet

Et Solution Development Team består af en Business Ambassador, Solution Developer, Solution Tester, Business Analyst og en Team Leader. Sammen skaber de fem roller en løsning, og de er alle ansvarlige for at køre projektet, så det passer til forretningens eller kundens behov. Et projekt kan sagtens bestå af flere Solution Development Teams, som hver indeholder de fem forskellige roller. Hver person i et Solution Development team er selv ansvarlig for at udfylde sin rolle og forventes at være selvkørende i forhold til at løse de opgaver, som rollen indebærer.

Support roller

Business Advisors, Technical Advisors, Workshop Facilitator og DSDM Coach går alle sammen ind under kategorien ”Supporting Roles”, hvilket betyder, at de står klar til at guide og assistere undervejs i projektet. Alt efter behov kan der være flere Business- og Technical Advisors. Disse roller kan ikke tage beslutningerne i forbindelse med projektet, da beslutningstagningen er forbeholdt Solution Development Teamet. Til gengæld kan de rådgive projektdeltagerne med deres ekspertise inden for de to fagområder.

Hvor meget skal de forskellige roller inddrages i projektet?

Det kan være forskelligt for rollerne, hvor meget og hvornår de inddrages i projektet.

Rollerne under Project Level er især vigtige at have med under High-Level Planningen for at sikre, at løsningen får den forventede kvalitet og passer til Business Casen. Som regel er det ikke nødvendigt, at Project Level-rollerne involveres i den daglige projektgang, da den drives af projektets Solution Development Teams. Rollerne i alle Solution Development Teams inddrages aktivt undervejs i projektet, i processen hvor løsningen helt praktisk udvikles. Alle rollerne skal deltage i de daglige Stand-up møder for at opretholde den fælles viden omkring projektet og for at sørge for, at alle leverer som lovet. Den daglige kommunikation er også vigtig, for at skabe gennemsigtighed og ærlighed mellem deltagerne i projektet.

Rollefordelingen

DSDMs roller kan både indtages af én person pr. rolle, eller flere personer kan indtage den samme rolle. Omvendt kan én person også påtage sig flere roller. Hvis flere indtager den samme rolle, er det endnu vigtigere med rig kommunikation folkene imellem, så der hele tiden er enighed om beslutningerne i forhold til projektets retning og udviklingen af løsningen.

Business Sponsor

En Business Sponsor er ansvarlig for Business Casen og projektets budget. Vedkommende skal sikre, at processen for projektet forløber så effektivt som muligt. Han eller hun bør være engageret og støttende hele projektet igennem og være med til at sørge for, at de resterende roller i projektet udfyldes tilfredsstillende.

Business Visionary

Den, der indtager rollen som Business Visionary, står for at udvikle forretningsvisionen for projektet. Denne rolle bør kun besættes af én person for at sikre, at projektet har en fuldstændig entydig vision, så der ikke opstår forvirring blandt projektdeltagerne. En Business Visionary bør være i stand til at se Business Sponsorens behov og kommunikere disse videre til alle teams i projektet. Business Visionaryen er involveret i hele projektets forløb og skal undervejs lede alle teams den rigtige strategiske vej, så løsningen matcher Business Casen. Når projektet er slut, er det Business Visionaryen, der er ansvarlig for at realisere mulighederne i den færdigudviklede løsning.

Technical Coordinator

En Technical Coordinator er den person, som har autoriteten, når det kommer til projektets tekniske forhold. Derfor har vedkommende ansvaret for, at den tekniske del af projektet er sammenhængende og lever op til de tekniske standarder, der er sat for den færdige løsning. En Technical Coordinator har samme rolle i det tekniske perspektiv, som Business Visionaryen har i det forretningsmæssige perspektiv.

Project Manager

Project Managerens rolle er, at styre det daglige projektarbejde, hvor den færdige løsning udvikles. Det gør vedkommende ud fra den agile ledelsesmetode, hvor der ledes overordnet på et High-level niveau. Det betyder, at en Project Manager skal overlade den detaljerede planlægning af løsningen, og hvordan den skal laves, til Solution Development Teamet. En Project Manager i agil forstand er dermed i højere grad støttende end kontrollerende over for projektdeltagerne. I arbejdet med at sørge for, at projektet forløber som det skal, er det vigtigt som Project Manager at sikre rig kommunikation, samarbejde og motivation blandt projektdeltagerne.

Business Analyst

Denne rolle fokuserer på at styrke forholdet mellem projektets tekniske og forretningsmæssige interesser. Derfor støtter Business Analysten både de forskellige projektroller og er samtidig helt integreret med Solution Development Teamet. Det er vigtigt, at Business Analysten ikke overtager styringen i Project Development Teamet, men nøjes med at støtte dem og opretholde kommunikationen i mellem dem.

Team Leader

En Team Leader anses som Solution Development Teamets leder, der skal sikre, at teamet leverer de aftalte produkter. Team Leaderen planlægger sammen med sit team i detaljer, hvordan hvert produkt under løsningen skal laves. Der er også Team Leaderen, der står for at arrangere de daglige Stand-up møder og sørge for, at alle teammedlemmer deltager. 

Business Ambassador

Det er i denne rolle man finder repræsentanten for forretningens behov og autoriteteten til at fortælle, hvad forretningen ønsker. Særligt i Foundation fasen er Business Ambassadoren fremtrædende, fordi det er her, hvor de forskellige opgaver i projektet skal prioriteres. Når der er enighed omkring de overordnede krav til projektet, er det en Business Ambassador, der laver en detaljeret plan over kravene til projektet inden for tidsrammen. Undervejs i projektet er det også Business Ambassadoren, der er forretningens beslutningstager og tager beslutningerne på forretningens vegne. Det er derfor vigtigt, at der i forretningen er respekt omkring og tiltro til den, der udvælges til at være Business Ambassador.

Solution Developer

Solution Developeren er den, der i samarbejde med Solution Development Teamet udvikler en løsning, der matcher forretningens behov og ønsker. Denne person skal have masser af input fra den, der fungerer som Technical Coordinator og har særlig ekspertise inden for området.

Solution Tester

Solution Testeren er en person, som Solution Development Teamet har valgt til løbende at teste produkterne, der udvikles. Personen er integreret i teamet og skal teste, om produkterne lever op til de forventede standarder for projektet. 

Business Advisor

En Business Advisor fungerer som en ekspert inden for det forretningsmæssige område og repræsenterer en typisk bruger af den færdige løsning. Vedkommende kan bidrage med gode råd om fx lovgivningsmæssige forhold, som der skal tages hensyn til i projektet.

Technical Advisor

Technical Advisor udfylder samme rolle som en Business Advisor, men fungerer i stedet som ekspert inden for det tekniske område. Vedkommende rådgiver derfor om, hvilke tekniske justeringer der med fordel kan laves i projektet, og hvad der skal tages hensyn til under udviklingen af løsningen.

Workshop Facilitator

Som navnet indikerer, er en Workshop Facilitator en person, som står for at afholde og styre workshops i projektet. Det er også den person, der forbereder workshoppen og kommunikationen i forbindelse med den. Workshop Facilitatoren bør samtidigt sørge for, at alle deltagerne deltager aktivt i workshoppen og får det ønskede udbytte ud af workshoppen.

DSDM Coach (Agil coach)

DSDM Coachen, også kaldet en agil coach, kan være afgørende for projektets succes, især hvis projektdeltagerne har begrænset erfaring med at bruge den agile projektmetode. En (DSDM) Agil Coach hjælper teammedlemmerne med at gennemføre projektet med den agile tilgang og få mest muligt ud af fordelene ved den agile metode. Fordi den Agile (DSDM) Coach både har stor teoretisk og praktisk viden om den agile metode, er vedkommende også i stand til at se, hvornår det er bedst at holde sig til teorien, og hvornår det er bedst at afvige fra teorien, så der skabes det bedste resultat for forretningen. Du kan læse mere om den agile coach her (link).

Projekttrekanten

Hvad er en projekttrekant?

Projekttrekanten er et værktøj, som organisationen kan bruge i projekter til at beslutte sig for, hvordan man vil reagere på uforudsete udfordringer.

Selvom det kaldes for projekttrekanten, indgår der faktisk fire elementer i modellen. De tre sider i trekanten består af variablerne tid, penge og omfang. Disse tre udgør tilsammen projektets kvalitet, som står i midten af trekanten.

I praksis vil det betyde, at man kan reagere på fire forskellige måder, hvis der dukker uventede udfordringer op undervejs i et projekt:

1. Udsætte deadlinen for projektet og dermed gå på kompromis med variablen tid.
2. Tilføre flere ressourcer til projektet, fx i form af folk, og gå på kompromis med budgettet.
3. Fjerne opgaver i projektet, hvilket betyder, at man skærer i projektets omfang.
4. Levere et produkt, der ikke er ligeså godt som planlagt og gå på kompromis med kvaliteten.

Følgende eksempel vil demonstrere dilemmaet om, hvilket variable man bør justere på, hvis der opstår uforudsete udfordringer i projektet.

Fem mand har fået til opgave at grave en to meter bred og 50 meter lang grøft samt en tilhørende brønd. De går ud fra, at jorden, de skal grave i, er muldjord, men da de kommer i gang med at grave, finder de ud af, at en stor del af jorden består af meget hård lerjord. Da denne uforudsete udfordring opstår, kan de derfor vælge at reagere på følgende måder:

1. De kan udsætte deadlinen og bruge to uger på at blive færdige i stedet for en uge.
2. De kan få fem mand mere til at hjælpe med at grave og dermed fordoble ressourcerne og budgettet for projektet.
3. De kan skære i projektets omfang og lade være med at grave den tilhørende brønd.
4. De kan nøjes med at grave grøften, så den kun bliver en meter bred, med større risiko for at vejen ved siden af bliver oversvømmet.

Inden de fem mand går i gang med at grave, bør der derfor være aftalt, på hvilke af de fire måder, der skal reageres, hvis udfordringer såsom hård lerjord opstår undervejs.

Hvordan bruges projekt-trekanten?

Projekttrekanten bruges allerede i planlægningen af projektet, før det skydes i gang. Meget tidligt i projektet bør styregruppen og projektledelsen blive enige om, hvordan man reagerer på uforudsete arbejdsopgaver. Da det er meget normalt, hvis ikke uundgåeligt, at der under projekter opstår bump på vejen, er det vigtigt at have på plads, hvordan man i sådanne situationer vil handle. På den måde sikres det, at projektledelsen og projektet gør præcis, som styregruppen ønsker det.

Ved eksemplet med grøften er det derfor vigtigt, at styregruppen fortæller projektledelsen og de fem mand præcis, hvad de ønsker, de skal gøre ved udfordrende situationer. Så undgås det, at projektledelsen fx sætter ti mand på projektet i stedet for fem, selvom styregruppen hellere ville have droppet brønden.

DSDM’s måde at bruge projekt trekanten på

I praksis er det muligt at justere på både tiden, prisen, omfanget og kvaliteten af projektet. Følges DSDM’s agile tilgang til projekttrekanten, ser det dog lidt anderledes ud, hvis man skal bruge projekttrekanten.

DSDM’s tilgang til projekter generelt tillader nemlig ikke, at hverken tiden eller budgettet for projektet overskrides samtidig med, at kvaliteten af det færdige produkt ikke må forringes. Det efterlader variablen omfang som det eneste, der kan justeres undervejs i projektet.

I eksemplet med grøften der skal graves, vil det betyde, at de bør fraprioritere den del af projektet, som giver mindst værdi for den færdige løsning og derfor bør droppe at grave brønden.

Fordelen ved at bruge projekttrekanten

Hos Plan A Projects har vi indtil nu på alle projekter oplevet en overoptimisme hos kundeorganisationen, hvor de tror, at de kan få flere opgaver med i projektet, end hvad der viser sig at være realistisk inden for den tildelte tid og mængde ressourcer til projektet. Fordelen ved projekttrekanten er derfor, at man på den måde tidligt får skabt et realistisk billede af projektets omfang. Kunden får altså identificeret den mest værdiskabende del af løsningen, som er mulig at levere inden for projektets rammer.

Når vi i starten af et projekt rådgiver folk til at prioritere opgaverne i projektet, fordi der er risiko for, at alle opgaver ikke når at blive udført inden for projektets rammer, er vi ikke altid lige populære. Men når projekterne leveres til tiden eller før, er der klar enighed hos kunden om, hvilken gevinst der er ved at bruge denne fremgangsmåde!

Det er selvfølgelig altid kunden, der bestemmer, hvordan opgaverne i projektet skal prioriteres, for at sikre den størst mulige værdiskabelse for kundens endelige løsning.

Hvis man ikke prioriterer opgaverne på forhånd, opstår risikoen for, at det bliver op til tilfældighederne hvilke opgaver, der kommer med, og hvilke der fravælges i projektet. Det gør værdiskabelsen for den færdige løsning mindre, samtidig med at mundvigene hos projektdeltagere, projektledelse og styregruppe sidder lavere.

Vi synes derfor, det altid er en god idé, at bruge projekttrekanten i sin planlægning af et fremtidigt agilt projekt.

Rigtig god fornøjelse med projektplanlægningen.

Det agile Danmark kører på tre hjul

Hvordan argumenterer du, hvis din organisation er blevet oversvømmet af et agilt rammeværk, der ikke fungerer til alt det, I har brug for? Her får du et overblik over det agile metodelandskab og viden om, hvilke agile rammeværk, der er designet til hvad.

Hvilke agile rammeværk er designet til hvad?

I forskellige sammenhænge har vi mødt folk på den agile scene, der opfattede Scrum som værende det samme som agile. På det seneste har vi mødt folk, der udtrykker sig som om, at SAFe tilsvarer agile. I det hele taget oplever vi, at selv meget erfarne og kompetente folk i branchen såvel som på direktionsgangene ikke har et overblik over, hvilke agile rammeværk, der er designet til hvad.

Der er derfor et behov for at skabe dette overblik, der er drevet af kundebehov mere end noget andet.

One size does not fit all

Tømreren har en hammer til at løse nogle opgaver, en tommestok til andre og en skruetrækker til en tredje gruppe opgaver. Værktøjerne sameksisterer i tømrerens virksomhed. Det bør de agile rammeværk også gøre i jeres. Jeres virksomhed har forskellige typer opgaver og de bør løses med de bedst egnede rammeværk.

Det er let og fristende at få det indtryk, at et enkelt rammeværk kan stort set alt. Vi har dog endnu ikke set the Silver Bullet.

Tag udgangspunkt i jeres behov

Plan A matrix tager udgangspunkt i de mest centrale forhold, som jeres agile rammeværk skal fungere i: Tidshorisont og værdiskabelse. Begge dele har stor indflydelse på valg af governancemodel. I vil let kunne finde frem til, hvilke agile rammeværk, der er relevante for jeres organisation.

Hvis vi starter med X-aksen i modellen ovenfor, så har den til højre en rullende tidshorisont og et fokus på at tilpasse sig markedet. Det kan f.eks. være tilfældet for en avis, hvis hjemmeside løbende skal tilpasses til markedsbetingelser, der ændrer sig hele tiden. Derfor er planlægningshorisonten relativt kort, når det kommer til at kortlægge afhængigheder, til at specificere leverancerne, til at estimere og tildele leverancer til sprints. En væsentlig risiko er her ikke at ramme markedets behov – f.eks. med et svigtende salg til følge.

I X-aksens venstre ende er der en deadline. Det kan f.eks. være gældende ved en systemimplementering, et melodi grand prix eller implementeringen af en lovtekst. Fokus er her på at levereindholdet af en kontrakt eller en aftale med et mere eller mindre præcist aftalt scope, der, frem til deadline, konvergerer mod den løsning, som giver størst forretningsværdi. Derfor går planlægningshorisonten frem til deadline. En risiko til venstre kan være overløb på tid og/eller økonomi.

Y-aksen skelner mellem ”store” agile initiativer for oven og ”små” agile initiativer for neden.

Plan A Matrix – Et overblik over agile rammeværk

I nederste kvadrant til højre angiver Plan A Matrix, at Scrum er velegnet til f.eks. videreudvikling af avisens hjemmeside. Det er en mindre løsning, der hele tiden skal tilpasse sig markedet og som ikke har en slutdato.

I samme kvadrant er Kanban. Det er en meget velegnet tilgang til at håndtere samlebåndslignende arbejdsgange som f.eks. hos Toyota, hvor Kanban har været anvendt længe. I nogle sammenhænge vil Kanban også kunne gøre sig gældende i store initiativer.

I større sammenhænge kan man nævne de softwareløsninger, der findes hos f.eks. SAP, Microsoft, banker, pensionskasser m.fl. Her er der måske 3000 personer, der sammen står for en given løsning. Behovet for markedstilpasning og horisonten har de til fælles med Scrumteamet hos avisen, men de er markant flere personer. Derfor har de brug for en overbygning, der sikrer, at alle ”løber samme vej”. Her er rammeværkerne i øverste kvadrant til højre  gode bud.

I agil sammenhæng er ”Think Big, Start Small and Learn Fast” en udbredt tilgang for at sikre, at man reelt arbejder i den rigtige retning. Hvad er ”small” så? Alt er relativt, så hvis man er 51 personer, så er minimumskravet fra SAFe på 50 en stor mundfuld. Hvis man derimod er 3000 personer, så er 50 ”small”. Minimum for Scrum@Scale og LeSS er to teams.

I nederste venstre kvadrant er der tale om mindre initiativer, der skal levere et mere eller mindre præcist aftalt scope på et givet tidspunkt. Dette er agile projekter designet til. Agile Business Consortium (det tidligere DSDM Consortium), leverer et rammeværk til dette. Agile Business Consortium er verdens ældste agile organisation og globalt førende inden for agil projektledelse med 110.000+ certificeringer.

Projekter findes jo i meget varierende størrelser, så agile projekter kan også forekomme i venstresidens øverste kvadrant. I endnu større initiativer kan agil programledelse blive relevant. Agil porteføljeledelse kan omfatte alle typer agile initiativer. Agile Business Consortium leverer også rammeværk til disse.

Hvordan kan du bruge Plan A Matrix?

Hvis jeres virksomhed ønsker at anvende agile rammeværk – eller at revurdere, hvilke agile rammeværk, I allerede bruger – så gennemgå Plan A Matrix med jeres øverste ledelse. Det vil hurtigt stå klart, hvilke agile rammeværk, I med fordel kan bruge til hvad. Som det gælder for tømreren, så vil den bedste situation for jer formentligt være at have flere rammeværk i brug ad gangen.

Et andet perspektiv på ”Start small” kan være, at I starter med Scrum i én del af organisationen og agil projektledelse i en anden. Efter et stykke tid vil I have opsamlet tilpas megen erfaring til at kunne vurdere, om I ønsker at sætte større agile initiativer i søen på venstre og/eller højresiden i Plan A Matrix. I er velkomne til at bruge og distribuere Plan A Matrix i sin nuværende form med reference til www.planaprojects.com – se muligheder og betingelser her.

Fakta om Plan A Matrix

Værkets titel: “Plan A Matrix – Mapping Agile Frameworks”

Kreditér værk til: ”Lasse Borris Sørensen”

Kreditér værk til URL: ”www.planaprojects.com/da/Plan-A-Matrix-Mapping-Agile-Frameworks/”

URL til kilden for værket: ”www.planaprojects.com/da/Plan-A-Matrix-Mapping-Agile-Frameworks/”

Ønsker du flere tilladelser: Skriv til info@planaprojects.com.

Plan A Matrix – Mapping Agile Frameworks by Lasse Borris Sørensen er licenseret under en Creative Commons Navngivelse-IngenBearbejdelse 4.0 International Licens.
Baseret på et værk ved www.planaprojects.com/da/Plan-A-Matrix-Mapping-Agile-Frameworks/.
Tilladelser udenfor rammerne af denne licens kan findes på www.planaprojects.com/da/Plan-A-Matrix-Mapping-Agile-Frameworks/

Hvad er en agil coach?

En agil coach er en, som træder til og hjælper, når deltagerne i et projekt har begrænset viden og erfaring inden for den agile projektmetode (Agile methodology) eller ønsker sparring med en ekspert på området. Vedkommendes rolle er at hjælpe projektdeltagerne med at få så meget ud af metoden som muligt, inden for den kontekst og de rammer som passer til organisationen i det store hele.

Når man er agil coach, er man specialist inden for sit fagområde, som er agil projektledelse. Agile coaches har samtidig masser af erfaring både teoretisk og praktisk og netop kombinationen af det gør, at de har rigtig meget relevant at dele ud af, når de tilkobles et nyt projekt. Det skal samtidig være en person, som kan facilitere og styre et møde eller en workshop, hvilket betyder, at vedkommende skal have gennemslagskraft i projektlokalet og være vedholdende over for projektdeltagerne.
Det er desuden en stor fordel og en god egenskab, hvis man har let ved at skabe relationer med andre folk, fordi det giver et bedre udgangspunkt for nemt at blive tilkoblet som ekstern konsulent på et projekt. Den agile coach fungerer også som en ledelsesmæssig sparringspartner, som kundens ledere kan sparre med i udfordrende situationer og ved planlægning af, hvad der fremadrettet skal ske med projektet.

Hvad er fordelene ved en agil coach?

Vælger man at få en agil coach på sit projekt, er man garanteret en ekstrem høj grad af vedholdenhed ved metodeimplementeringen. Vedkommende kan tillade sig udelukkende at fokusere på, at metoden implementeres rigtigt og bedst muligt, og de formår konstant at holde overblikket over tilgangen til agile metoder. Noget andet, som en agil coach er god til, er, at vedkommende kan finde ud af at tilpasse teorien om agil projektmetode særligt til kundens specifikke situation. Han/hun kan holde balancen mellem teori og metode og er skarp på, hvornår man kan tillade sig at afvige en smule fra teorien, og hvornår det er særligt vigtigt at holde fast i den. Det er helt forskelligt fra team til team, hvilke situationer der skal tages hensyn til, og hvad der skal holdes fast i, og netop her kan den agile coach vurdere, hvad der er brug for at gøre. Fordi den agile coach er i stand til at tilpasse teorien til den gældende situation, kommer der hurtigst mulig fremdrift i projektet.

Når man går fra én metode til den agile metode, kommer man ved hjælp fra en agil coach hurtigt i gang med at bruge metoden rigtigt og helhjertet. På den måde kommer man til at bruge sin tid rigtigt i projektet og kommer derfor til at spare både tid og penge ved at bruge den rette og mest effektive metode. Selvom det koster penge at få en agil coach på sit projekt, kan vedkommende i sidste ende hjælpe én med at spare op til 30 % på projektet. Det kan altså ses som en investering, der giver stort Return on Investment på den lange bane. På især store og komplekse projekter er det en investering, der i mange tilfælde udgør et minimalt indhak i budgettet.

Hvad kan en agil coach, som andre ikke kan?

Et af de steder, hvor en agil coach især skiller sig ud fra resten af projektgruppen er, at personen kan skabe træfsikkerhed, når det kommer til metodeimplementering. Netop pga. sin store teoretiske og praktiske viden, kan vedkommende forklare projektteamet præcis, hvad der er rigtigt at gøre og ikke mindst argumentere for, hvorfor det er rigtigt at gøre. Evnen til at ”oversætte” metoden og gøre den forståelig og relevant for projektdeltagerne er altså en helt central del af rollen som agil coach. Derudover er denne person ekspert i og skabt til at fungere som projektets antenne, der støtter og hjælper projektgruppen og altid står klar til at sparre med projektlederen. På den måde kommer projektet hurtigere ud over stepperne og hurtigere i mål!

I hvilke situationer er der brug for en agil coach?

Først og fremmest er det oplagt at bruge en agil coach, hvis man skal skifte fra én projektmetode til den agile projektmetode. På den måde sørges der for, at projektmetoden implementeres 100 %, og at det sker så hurtigt som muligt. Der vil være brug for den agile coach i hele forløbet, lige indtil organisationen er trænet i de agile metoder og er klar til at køre den videre selv uden hjælp.

En anden situation hvor det er godt at have en agil coach er, hvis det hele brænder på i projektet, og man ikke kan redde det ved at gøre det, man plejer at gøre. Her kan den agile coach komme ind som et friskt indspark, der hjælper organisationen på rette kurs igen. Når man skal gennemføre en forandring i organisationen, er det generelt en god ide at hive en agil coach ind som ekstern konsulent, fordi medarbejderne kan rette kritik o.l. mod vedkommende i stedet for de interne ledere, så der ikke opstår en anspændt stemning i organisationen undervejs og efterfølgende. De interne ledere kan altså beholde deres ”good cob” rolle, mens den agile coach kan indtage rollen som ”bad cob”, hvis det bliver nødvendigt. Hos Plan A Projects ser vi det som en af vores fornemmeste opgaver. Og tro det eller ej, vi er vilde med at udføre det.

Hvor længe har man brug for en agil coach?

Det kan variere meget fra projekt til projekt og fra team til team, hvor længe det er nødvendigt at have den agile coach tilknyttet projektet. Der er stor forskel på, hvor svære opgaverne i projektet er – eksempelvis skal der ikke bruges særlig lang tid på at få stand up-møder til at fungere, mens High Level Planning eller et sprint-skifte kan tage længere tid.

Svaret er derfor, at der ikke længere er brug for en agil coach på det tidspunkt, hvor projektdeltagerne reelt selv kan køre den agile metode videre uden hjælp (ikke når de tror de selv kan!).

Hvordan finder du en agil coach til dit projekt?

I Plan A Projects har vi kun super skarpe agile coaches ansat, og vi har stor erfaring i at gøre det, vi gør. Hvis du er på jagt efter en agil coach til dit projekt, så har vi ganske sandsynligt løsningen til dig. Processen starter med et uforpligtende møde, hvor vi bliver guidet gennem projektets omfang, organisation, mål og budget. Med den viden kan vi coache dig til at vælge den bedste løsning til lige netop dit projekt. Det er intet krav at være superbruger i den agile verden – vi kan lære jer, hvad der skal til.

Har du spørgsmål eller brug for en agil coach, så kontakt os i dag, så vi kan hjælpe jer på rette vej og vise, hvor fedt det kan være, at være en del af et team, der oplever god energi og stor fremdrift hele projektet igennem.

Læs om agile projekter der succesfuldt har haft en agil coach tilknyttet projektet for at sikre, at de når i mål til tiden og inden for budget samtidig med at være 100% metodetro.

Agil ledelse – Projektledelse til tiden

Agil ledelse er en faciliterende måde at lede på. Det betyder, at der ved agil ledelse er fokus på at holde fast i retningen (strategien) og rammerne for en virksomhed eller et projekt.

En projektleder i et agilt projekt bør være en faciliterende leder. Projektlederens rolle er derfor at styre projektarbejdets daglige gang på et high-level plan. Det vil sige, at projektlederen skal styre selve processen for projektet, men overlade al den detaljerede planlægning af de tilhørende opgaver til projektteamet. Vedkommende skal støtte projektteamet og styre det i den rigtige retning, men uden at være kontrollerende over for projektdeltagerne.

En leder, der driver agil ledelse, er i høj grad optaget af at sikre rig kommunikation, motivation og samarbejde i projektteamet. Denne ledelsesstil er med til at skabe transparens i projektet, så den enkelte projektdeltager kan se, hvor langt de andre projektdeltagere er, og hvilke arbejdsopgaver de er i gang med. Dermed får teamdeltagerne større ejerskab over deres opgaver, fordi de ved præcis, hvad de har ansvar for, og ikke mindst hvad de bidrager til i sidste ende. Netop fordi projektdeltagerne får større ejerskabsfølelse over deres arbejdsopgaver, og fordi det står klart for alle, hvem der er ansvarlig for hvad, vil mange projektdeltagere automatisk blive mere produktive. Det øger effektiviteten i projektet, og agil ledelse bidrager til, at det i sidste ende kan blive afsluttet til tiden eller endda før tid.

Projektlederen ved agil ledelse er som sagt ansvarlig for at styre rammerne for et projekt. Den del af rollen har nogle rent praktiske opgaver indbygget i sig. Det er blandt andet at skabe co-location, så projektdeltagerne fysisk befinder sig det samme sted og sørge for, at projektdeltagerne har så mange fælles arbejdsdage som muligt. Det er ligeledes den agile projektleders rolle at motivere alle projektdeltagerne til at møde op til workshops undervejs i projektet – og desuden deltage aktivt i dem, når de er der.

Ønsker du at drive agil ledelse, er det derfor vigtigt at have fokus på rammerne og målet for projektet, dog uden at bestemme hvordan projektgrupperne vælger at løse opgaverne i det. På den måde giver agil ledelse gladere projektdeltagere og bedre resultater i sidste ende.

Projektmodellen

Hvad er jeres behov?

At arbejde agilt er noget, der hele tiden kommer mere i fokus, fordi flere begynder at finde ud af, hvor gode resultater det skaber. Alligevel kan det føles svært for nogle, at ændre alle deres vandfaldsprojekter til agile projekter fra den ene dag til den anden. Derfor kan Plan A Projects hjælpe jer med at gennemføre agile projekter side om side med vandfaldsprojekter, ved at lave et agilt spor i jeres eksisterende (stage gate) projektmodel.

Når vi har tilpasset modellen sammen, kan vi prøve den af på et pilotprojekt for at finde ud af, hvordan vi tilpasser det agile spor til jeres projektmodel. Under hele forløbet er det fuldstændigt op til jer, hvor meget vi skal inddrages i processen. Vi tilpasser vores bidrag alt efter, hvad jeres behov er, og hvor meget sparring samt støtte I har brug for og har lyst til at få.

Der kan være stor spændvidde i de forslag til ændringer, vi giver til projekter. Forslagene kan berøre alt fra det fysiske arbejdsmiljø til strategiske overvejelser i virksomheden.

Plan A Projects kan også hjælpe jer, hvis I undervejs i et projekt får brug for hjælp og sparring. Det kan både være i situationer, hvor projektmodellen er god, men ikke udføres godt, eller hvor det er selve projektmodellen, der trænger til justeringer. At få ekstern hjælp til sine projekter har den fordel, at hjælperen bidrager til projektet som en uvildig part, der som en neutral spiller kan rådgive alle deltagere i projektet uden at tage parti for nogen.

Selvom agile projekter primært er udbredt i IT-branchen, betyder det ikke, at det er den eneste branche, som de kan fungere i. Vores metode er designet til at fungere i alle brancher og kan implementeres i projekter af alle størrelser – også de helt store, komplekse projekter.

Plan A Projects var agil coach på de to første store agile SAP-projekter i Danmark

På det første projekt var Plan A Projects ansvarlig for implementeringen af den agile projektmetode i en stor projektorganisation hos en af Danmarks største virksomheder, der ikke havde agil erfaring uden for projektlederkredsen. I løbet af dette projekt fik Plan A Projects også rollen som Scrum Master på et af de syv teams. Hele projektet gik succesfuldt live en uge før planlagt. I det andet SAP-projekt hos samme kunde, hvor Plan A Projects også var agil coach, blev projektet også leveret en uge før planlagt. Dette vil vi også meget gerne hjælpe dig med at opnå i dit projekt.

Mange store virksomheder har kendskab til agile projekter og tilhørende projektmetoder og bruger måske Scrum i mindre projekter, men har endnu ikke afprøvet den agile tilgang på store projekter. Skal man starte et stort projekt op, med mange involverede og over en længere periode, kan det virke uoverskueligt at oplære alle i metoden og sætte dem ind i en ny projektmodel. Men ønsker man bedre resultater, hurtigere – også på den lange bane – kan dette metodefokus godt svare sig.

Vi sætter en ære i at gøre den agile projektmetode vedkommende og forståelig for alle parter, således at metoden bliver brugt. Det er altså Plan A Projects, der sørger for, at projektlederens ambition om at udføre projektet agilt, bliver til virkelighed.

Skal I til at starte et agilt projekt, eller oplever I gentagne gange, at store projekter bliver for dyre og forsinkede?

Så skulle I overveje at involvere Plan A Projects i planlægningen, etableringen og eksekveringen af jeres næste projekt.

Projekter leveret til tiden – eller før!

Vi har implementeret vores projektmetode i godt 30 tilpassede versioner af projektmodeller hos vores kunder og hjulpet kundernes projektledere til at skabe meget flotte resultater.

Med en enkelt undtagelse, er samtlige projekter karakteriseret af at være meget komplekse.

På trods af, at projekterne spænder bredt over omfang fra 500 timer til 65.000 timer og projektbudgetter fra få hundrede tusinde kroner til 1,6 milliard kr., så har INGEN projekter overskredet deres deadline.

To projekter er leveret til tiden og resten er leveret fra en til fire uger før planlagt eller er fortsat i gang. Det er kunderne glade for, og vi stolte over.

Den agile projektmetode – en effektiv projektmetode med solid erfaring!

Hos Plan A Projects får projektledelsen sparring og støtte til at få implementeret den agile projektmetode i deres projektmodel, som er en stærk metode, der sikrer resultaterne i jeres projekt. Vi kalder det fokus på ledelse i projektledelse.

Vi tilbyder kendte og afprøvede metoder som agil projektledelse (DSDM), PRINCE2 og positiv psykologi i en unik kombination, der sikrer kvalitet i projektet.

Den agile projektmetode sikrer, at projektet leverer til tiden, virksomheden sparer tid og penge og skaber projekter, som folk gerne vil være med på. Dette skaber i sidste ende de ønskede resultater. Vi arbejder tæt sammen med projektledelsen. Vi sikrer implementeringen og rammesætningen af metoden i den eksisterende projektmodel, mens projektlederen fokuser på at lede projektet.

Resultater – også på den lange bane

Vi giver med udgangspunkt i DSDM i høj grad overblik og indflydelse til alle medarbejdere i projektet. Ved hjælp af faciliterede workshops får medarbejderne dyb indsigt i samt stor indflydelse på projektet og rig mulighed for at styrke projektet med deres faglige indsigt. Dette er både med til at styrke arbejdsglæden for den enkelte medarbejder og med til at øge kvaliteten af projektet og dermed også af slutproduktet. Ikke mindst i de lange projekter spiller dette en stor rolle.

Stage Gate modellen

Hvad er en stage gate model, og hvordan gavner den projektet?

En stage gate model er en model, der deler projekters livscyklusser op i mindre og mere overskuelige faser. Indholdet i hver fase er forskelligt, og har dermed forskellige fokusområder og opgaver forbundet med sig.

En stage gate model er ikke kun gavnlig at bruge i forbindelse med vandfaldsprojekter, men er også oplagt at bruge til agile projekter. I planlægningen af et projekt, vælges der enten at køre projektet som vandfald eller i et agilt spor, og herefter kan stage gate modellen tilrettes efter det givne valg. Uanset hvilken projektmetode man vælger, vil stage gate modellen stort set forblive den samme. Det er de samme faser projektet går igennem og de samme leverancer i hver fase. Ved den agile projektmetode er der dog flere typer af projektroller.

DSDMs stage gate model består af 6 faser, som her vil blive forklaret:

1. For-projektfasen/idéfasen

I denne fase sikres det, at projektet er sat rigtigt op, og at kravene samt forventningerne til projektet er på plads.

2. Gennemførlighedsfasen

Denne fase er primært til for at afstemme, om projektet er gennemførligt i forhold til både de tekniske og budgetmæssige krav, der er stillet til det. I fasen vurderes det, om det er muligt at køre projektet og om det kræver eventuelle ændringer.

3. Krav- og specifikationsfasen

Her er det meningen, at der skal skabes en grundlæggende forståelse for det forretningsmæssige rationale bag projektet, samt hvordan udviklingen og leveringen af løsningen skal se ud.

4. Byggefasen

I stage gate modellens fjerde fase begyndes der på at udvikle en løsning til projektet. Her laver Solution Development Teams blandt andet iterativ udvikling og prioriterer i mellem de opgaver, der er forbundet med projektet.

5. Implementeringsfasen

I denne fase skal tiltagene fra byggefasen gøres til operationel praksis. Efter implementeringsfasen er det meningen, at der enten foreligger en færdig løsning eller en delmængde af den færdige løsning.

6. Projektafslutningsfasen

Denne fase er til for at eftertjekke, hvor godt løsningen til projektet møder de forretningsmæssige krav, der er blevet stillet til projektet i starten.

Hvordan brugen af stage gate modellen kan gavne et projekt, er et overset spørgsmål. Selvom modellen er simpel og mange af faserne virker ligetil, er der stadig stor fordel i at bruge modellen. Stage gate modellen giver rigtig god anledning til at fokusere på de leverancer, som netop den enkelte fase, man er i, skal munde ud i. Modellen giver kort sagt overskuelighed og mulighed for fokus på hver delleverance – begge ting noget, der giver et bedre slutresultat for projektet.

Hvor henne i stage gate modellen kan Plan A Projects hjælpe?

Hvis I ønsker hjælp til at køre jeres projekt agilt, kan I på forskellige måder få hjælp fra Plan A Projects. Den ene måde vi kan hjælpe på, er ved at træde til under stage gate modellens tredje og fjerde fase. De første to faser forløber som de plejer, hvorefter Plan A Projects træder til. Krav- og specifikationsfasen og byggefasen vil dermed komme til at se meget anderledes ud, hvis I er vant til at køre vandfaldsprojekter. De efterfølgende to faser vil derefter forløbe, som de plejer.

Plan A Projects kan også hjælpe jer med projektet på andre måder. Hvis I allerede har en stage gate model, kan vi hjælpe jer med at etablere et agilt spor i denne. Det vil blive gjort på en måde, der er så nænsom som mulig, så der ikke er nogle omveje for projektet.

Det agile manifest

Her kan du læse om det agile manifest og hvilke tanker, der ligger bag den agile metode. Det agile manifest er udarbejdet med formålet om at fungere som en guide for styringen af agile projekter. Det agile manifest er kortfattet og har simple budskaber, hvilket gør det nemt at huske og have med sig i baghovedet på agile projekter.

To projekter er leveret til tiden og resten er leveret fra en til fire uger før planlagt eller er fortsat igang. Det er kunderne glade for, og vi stolte over.

Der er værdi i punkterne til venstre, men vi værdsætter punkterne til højre.

Hvad er agile metoder?

Agile metoder er en projektstyringsfilosofi baseret på det agile manifest, som fokuserer på samarbejde, fleksibilitet og hurtig levering af værdi. Manifestets principper prioriterer individuelle interaktioner frem for processer og værktøjer, fungerende software frem for omfattende dokumentation, kundesamarbejde frem for kontraktforhandlinger og håndtering af forandringer frem for fastholdelse af en plan. Agile metoder som Scrum og Kanban styrker projektets dynamik og kontinuerlige forbedring ved at reagere på ændringer og ny viden gennem iterativ udvikling. Dette fokus på kommunikation og samarbejde mellem teammedlemmer og kunder sikrer høj kvalitet og tilfredsstiller virksomhedens behov, hvilket gør agile metoder til et effektivt værktøj for projektledelse.

Individer og samspil frem for processer og værktøjer

I et agilt projekt vil teamet og teammedlemmerne til hver en tid spille den væsentligste rolle for projektet og dets succes. Hos hvert teammedlem forventes det, at vedkommende er samarbejdende og kan fungere sammen med alle de andre på projektet. Derudover lægges der stor vægt på, at teammedlemmerne er klar til at udfylde deres rolle i projektet og bruger deres viden og erfaring til at skabe det bedst mulige projektresultat, som matcher kundens behov. Selvom processer og værktøjer spiller en vigtig rolle i alle projekter, er der slet ikke samme fokus på dem i et agilt projekt. Agile processer bør være til for at støtte og guide projektdeltagerne, frem for at diktere hvad de skal gøre, og hvordan det skal gøres. Det antages, at teammedlemmerne er de bedste og mest egnede til at vurdere, hvad der skal gøres, og hvordan det bedst muligt gøres.

Fungerende software frem for omfattende dokumentation

Denne del af det agile manifest har til formål at bryde med den traditionelle opfattelse om, at stabilitet og sikkerhed kommer af dokumentationsdrevne processer. Ved den agile metode er der en forestilling om, at det er spild af tid at specificere planerne ned til mindste detalje for at få opgaverne godkendt af interessenterne, før arbejdet kan gå i gang. Ifølge den agile projektmetode er der derimod behov for high-level planning i starten, for at sætte rammerne for projektet. Meningen med at bruge iterationer i et agilt projekt er, at der efter hver iteration leveres et stykke funktionsdueligt software. Dermed bliver der efter hver iteration leveret en del af det færdige produkt, som i sig selv skaber kvalitet og kan tages i brug, før det endelige produkt er færdigt. Fungerende software prioriteres over omfattende dokumentation, fordi denne indstilling til projektet giver mest værdi for kunden og bedre arbejdsdynamik for projektdeltagerne.

Samarbejde med kunden frem for kontraktforhandling

Bag den agile projektmetode ligger en idé om, at teammedlemmerne gennem tæt samarbejde finder den bedste måde at løse opgaverne i projektet på. Derfor understøtter det agile manifest samarbejde – både når det gælder teammedlemmerne indbyrdes, men også når det gælder kunden. En kontrakt mellem leverandør og kunde kan være alt fra et formelt dokument, der er underskrevet af begge parter, til en uformel verbal aftale. Fælles for alle kontrakter er, at de i højere grad skal fungere som guidelines for projektet, fremfor at være detaljerede. Derfor vil det i det agile manifest altid være vigtigere at have et velfungerende og tæt samarbejde med kunden, fremfor at bruge uanede mængder af tid og energi på at forhandle om en specifik kontrakt.

Håndtering af forandringer frem for fastholdelse af en plan

I agile projekter laves der ofte planer. Hvert enkelt sprint planlægges, og planen er med til at gøre det nemt for teammedlemmerne at træffe hurtige beslutninger undervejs i projektet. En vigtig pointe ved planer i agile projekter er dog, at de ikke bliver overdominerende faktorer, der frem for alt andet skal følges til punkt og prikke. Det vigtige ved agile projekter er at skabe værdi, hvilket medfører, at der skal være plads til ændringer undervejs, som kan forbedre slutresultatet. I processen inden projektet, hvor det planlægges og tilrettelægges, hvordan projektet kommer til at se ud, er det altså vigtigere at bide sig fast i idéerne og værdierne ved projektet frem for selve planen. Når man begynder på et projekt, er den plan, der laves, baseret på en begrænset viden og antagelse om, hvordan projektet på bedst mulig vis vil forløbe. At der kommer forandringer undervejs i projektet, er derfor helt naturligt, fordi den agile metode anerkender, at man bliver klogere undervejs i processen. Jo længere man når igennem projektet, jo mere viden og praktisk erfaring får man, hvilket kan bruges til at gøre det resterende projektforløb endnu bedre. Agile projekter tilrettelægges derfor på en måde, der gør det muligt at inkludere ny viden undervejs og skifte retning for produktet, hvis det giver en mere optimal løsning.

Agile metoder og principper – Agile On Time

Agile metoder, herunder scrum og Kanban, har til formål at prioritere arbejdsopgaverne i agil projektledelse, så der skabes størst mulig værdi for dem, som løsningen laves til. Derfor lægger den agile metode ikke op til at have en fuldstændig fastlagt plan, ligesom ved andre projektmetoder, fordi det bør være muligt at prioritere mellem opgaverne undervejs, for at skabe størst mulig værdi for kunden. Løbende evalueres projektets proces og resultater, og herudfra prioriteres opgaverne i den rækkefølge, der giver bedst mening. Ved agile metoder tages der dermed højde for, at man ikke kan forudse projektets forløb fra start til slut, men at man bliver klogere på projektet undervejs i takt med eventuelle ændringer og ny viden.

Den agile metode baserer sig på en fremgangsmåde, der tager udgangspunkt i DSDM’s otte agile principper:

Fokusér på virksomhedens behov med agile metoder

I et projekt bør der altid fokuseres på at levere netop dét, som virksomheden har brug for at få leveret, og enhver beslutning i projektet bør afspejle dette. Det er i den forbindelse vigtigt at huske, at et projekt er et middel til at nå et mål og ikke er et mål i sig selv.

Levér til tiden

At levere en løsning til tiden er meget vigtigt for et projekt og det er tit den allerstørste succesfaktor. En løsning, der leveres for sent, kan ofte ødelægge meningen med projektet og kan blandt andet forringe markedsfordele og give problemer ift. lovning. Ved de projekter, hvor tidsfaktoren ikke er det vigtigste, er overholdelse af aftalt deadline dog stadig en god måde at demonstrere kontrol over projektet på overfor kunden.

Samarbejd

Samarbejde er med til at skabe en fælles forståelse og viden samt øget arbejdshastighed i de agile teams. Det gør, at teammedlemmerne sammen skaber resultater, der både er bedre og skabes på kortere tid, end hvis de hver især skulle løse en opgave alene.

Teams med høj grad af samarbejde, engagement og masser af team-spirit vil derfor til hver en tid performe bedre, end de teams der ikke får samarbejdet og har dårlig kommunikation.

Gå aldrig på kompromis med kvaliteten

Når man bruger den agile metode, aftales det altid på forhånd mellem leverandør og kunde, hvordan kvaliteten på det færdige produkt skal være. Kvaliteten bør være tilstrækkelig høj til, at løsningen efterfølgende vil kunne anvendes effektivt. Alle projektets opgaver bør derfor bestræbe sig på at opnå præcis den aftalte kvalitet og hverken mere eller mindre.

Byg trinvist fra et solidt fundament

Noget der virkelig adskiller agile metoder fra andre projektmetoder, er måden, hvorpå projektet planlægges. Ved den agile metode foreslås det, at man starter med at forstå projektets omfang og udarbejde et forslag til en løsning, men med en lavere detaljeringsgrad end ved andre projektmetoder. Med udgangspunkt i dette solide fundament, leveres løsningen trinvist i en rækkefølge, der prioriterer de opgaver, som skaber mest værdi for kunden. Den fremgangsmåde er både den mest fordelagtige for kunden og er desuden med til at øge tilliden til kunden.

Udvikl løsningen iterativt

Agile metoder bruger en kombination mellem iterativ udvikling, hyppige demonstrationer og grundig evaluering for at få regelmæssig feedback. Hvis man anerkender, at forandring er en del af processen mod løsningen, bliver det lettere for alle teams at udvikle en løsning, der er nøjagtig, som kunden gerne vil have den. Det er sjældent, at alle løsninger bliver lavet perfekt første gang, og derfor er konceptet med iterationer vigtigt for den agile metode. Denne arbejdstilgang giver mening, fordi projekter og deres omverden konstant ændrer sig.

Kommunikér løbende og klart

Mangel på eller dårlig kommunikation ses ofte som den største grund til, at projekter går i vasken. Agile metoder er tilrettelagt præcis på en måde, der understøtter vigtigheden af kommunikation og skaber bedre kommunikation teams i mellem. Kommunikationen forbedres blandt andet gennem Stand Up-møder, workshops og ved klart af afstemme, hvilke roller og ansvar alle projektdeltagerne har hver især.

Demonstrér styring

For at kunne demonstrere styring i et projekt er det nødvendigt virkelig at have styring over projektet. Det kan teamet opnå ved at lave en plan over hvilket arbejde, der skal laves for at kunne udvikle løsningen. Denne plan laves gennem en projektnedbrydning, hvorefter der laves en Dependency Wall for at holde overblikket og styringen over projektet. Ved at gøre det demonstrerer man ikke kun styring, men skaber også gennemsigtighed i projektet, hvilket gavner både kunden og selve processen for projektet.