I dette indlæg vil jeg skrive lidt om hvad Agil Projektledelse er. Herunder det agile manifest og dets fire værdier, samt de 12 agile principper bag det manifest. Du vil kunne bruge dette indlæg til at tjekke, om du virkelig arbejder agilt, og om dine projekter lever op til alle principperne.
Det bliver altså en smule mere teoretisk end mange af mine andre indlæg, men jeg synes, det giver god mening, at du forstår dette grundlag for agil projektledelse. Nedenfor kan du se en rigtig god video med en række projektlederes erfaringer med agile.
Baggrunden for agile projektledelse
I midt-90’erne var en hektisk tid for udviklere, dot-com industrien var i fuld fart, og det virkede som om der kom en ny revolutionerende tech startup hver eneste dag, og der kunne potentielt komme en ny konkurrent, der ville udkonkurrere din virksomheds produkt allerede i morgen.
Der var derfor et konstant pres på projektledere for at komme i luften med projekterne så hurtigt som muligt for at sikre sig, at projektet ikke er forældet, allerede før det er lanceret.
IT‐projekter var et relativt nyt fænomen for de fleste. Disse IT‐projekter krævede et helt andet tempo, end man var vant til. Projektlederne opdagede, at Waterfall‐modellen ikke kunne følge med længere, der kom hele tiden en ny teknologi, som kunne være en del af projektet, men der var ikke nogen måde at nå at inkorporere det i tide med de traditionelle metoder.
Så en gruppe projektledere mødtes for at dele erfaringerne fra denne periode i 2001, hvor de sammen. de efterkommende måneder fik dannet grundlaget for en ny måde at drive projekter på; det agile manifest og de 12 agile principper.
Manifest for agil softwareudvikling
Herunder kan du læse det agile manifest:
Vi afdækker bedre måder at udvikle software på ved at gøre det og ved at hjælpe andre med at gøre det.
Gennem dette arbejde har vi lært at værdsætte:
Individer og samarbejde frem for processer og værktøjer
Velfungerende software frem for omfattende dokumentation
Samarbejde med kunden frem for kontraktforhandling
Håndtering af forandringer frem for fastholdelse af en plan
Der er værdi i punkterne til højre, men vi værdsætter punkterne til venstre højere.
Kilde: https://agilemanifesto.org/iso/dk/manifesto.html
Det er ikke, fordi det er et specielt langt manifest, men det er helt ind til benet. Og det står i skarp kontrast til de traditionelle metoder.
De traditionelle projektledelsesmetoder understreger faste planer, ingen eller få ændringer undervejs og et behov for at dokumentere alle aspekter af projektet og slutproduktet.
Det agile manifest, og agil projektledelse, ændrer dermed fuldstændig fokusset for projekterne til personer, samarbejde, fleksibilitet og fuldt fokus på at lave noget, der er så let at bruge, at der ikke er nogen krav til dokumentation.
Herunder kan du læse lidt mere om hvert af værdierne i det agile manifest.
Individer og samarbejde frem for processer og værktøjer
Når du tillader alle personer at komme med deres unikke perspektiv til projektet, så vil du opdage, hvor hurtigt folk kan løse selv de mest komplekse problemer.
Hvis du kan få en flok af individer fra forskellige baggrunde til at blive enige om en løsning, så kan du næsten med sikkerhed regne med, at den løsning er bedre, end hvis du, eller en anden, blot havde dikteret den.
Så en af de store fordele ved agile projektledelse er netop, at der ikke er meget, som er foruddefineret, men at det hele formes i samarbejde, og løsningerne har flere aspekter i sig end blot et enkelt.
Herunder har jeg lavet en tabel, der viser fordele og ulemper ved individer og samarbejde frem for processer og værktøjer.
| Fordele | Ulemper |
| Kommunikation og samarbejde er hurtigere og mere effektivt. | Projektlederen kan ikke diktere projektets processor, og hvordan det skal drives. |
| Projektgruppen har flere muligheder til at være kreative og finde bedre løsninger på problemerne. | Processerne er uklare, og der kan være mange forskellige processorer i projektet. |
| Projektgruppen kan tilpasse projektet processer, hvilket kan øge effektiviteten af projektgruppen. | Der er ikke meget dokumentation på projektet. |
| Projektgruppen føler et større ejerskab af projektet, og dedikere derfor også mere fokus til projektet, og sætter en ære i slutproduktet. | Der er ikke samme konkrete projektplan som på Waterfall projekter, som er særligt nyttige til at måle projektets fremgang. |
| Projektgruppen kan også ende med at have en større arbejdsglæde under de mere frie rammer. | |
| Det er lettere at implementere nye idéer, nye krav og nye tankegange omkring projektet. |
Velfungerende software frem for omfattende dokumentation
Projektgruppens fokus bør være på at lave det bedste slutprodukt som overhoved muligt. De bør ikke skulle bruge en masse tid på at dokumentere deres fremgang eller dokumentere alle aspekter af projektet i detaljer.
Den vigtigste dokumentation, du kan kræve af projektgruppen i agil projektledelse, er en test af slutproduktet, som viser alle kravene var mødt, eller at den møder det, der hedder “Definition of done”.
Så alle opgaver, som distraherer projektgruppen fra at lave det ideelle slutprodukt, skal gerne undgås så vidt muligt, da det underminere hele den agile tankegang.
Apple er kendt for at lave deres software så nemt, at brugerne slet ikke behøver at læse noget dokumentation for at bruge det, selvom det er noget meget omfattende software, det leverer.
Herunder er der en liste af dokumenter, som bruges i traditionelle projekter, og hvorvidt de indgår i agil projektledelse.
| Dokument | Bør du have dette dokument? | Dokumentets omfang |
| Gennemarbejdet projektplan, som er 100% retvisende, og som er baseret på en større foranalyse. | Nej. Start-til-slut projektplaner, som er detaljeret helt ned til de individuelle opgaver, bør ikke laves i agile projekter. | Men du skal bestemt have en overfladisk projektplan, hvor du estimerer projektets fremgang, opdelt i MVP’er og med et estimat af, hvor mange sprints hver MVP vil tage. |
| Kravspecifikation | Ja. Alle projekter skal have en kravspecifikation. | Den skal være lige udførlig, uanset om projektet drives Agilt eller ej. |
| Projektets målsætninger | Ja. Alle projekter skal have en detaljeret dokumentation for projektets målsætninger. | Den skal være lige udførlig, uanset om projektet drives Agilt eller ej. |
| Kommunikationsplan | Nej. Agile projekter har ikke samme behov for en kommunikationsplan som traditionelle metoder har. | Der holdes typisk færre statusmøder i agile projekter, derfor er der også mindre behov for en kommunikationsplan. |
Samarbejde med kunden frem for kontraktforhandling
Historisk, med traditionelle projektledelses metoder, har kunden og leverandøren kun samarbejdet når:
- Projektet var i udbud, og kontrakten skulle laves.
- Statusmøder undervejs i projektet
- Hver gang scope ændrede sig undervejs i projektet, og en kontrakt skulle genforhandles.
- Og til sidst i slutningen af projektet, når det skulle overleveres og lanceres.
Dette “samarbejde” har ikke lagt op til, at leverandøren skulle komme med for mange gode idéer til, hvordan man kunne gøre projektet bedre end det kunden efterspurgte.
Men grundlæggerne af den agil projektledelse forstod, at et tæt samarbejde mellem kunden og leverandøren altid ender med at give bedre, mindre fejlfulde og mere brugbare slutprodukter. Derfor vil du opleve, at der er meget mere samarbejde mellem kunder og leverandører i agil projektledelse.
Håndtering af forandringer frem for fastholdelse af en plan
Ændring er et værdifuldt værktøj til at skabe fantastiske produkter. En projektgruppe, der hurtigt kan reagere på ændringer og markedet, er i stand til at udvikle relevante og nyttige slutprodukter, som folk elsker at bruge.
Desværre forsøger traditionelle projektledelsesmetoder at kæmpe imod forandringer og ser forandringer undervejs i projektet som noget negativt.
Strenge forandringshåndterings procedurer og budgetstrukturer, der ikke kan imødekomme nye projektkrav, gør ændringer vanskelige. Traditionelle projekter følger derfor ofte blindt efter en plan og mangler muligheder for at skabe mere værdifulde slutprodukter.
Ovenfor kan du se forholdet mellem tid, mulighed for ændring og omkostningerne ved ændring på et traditionelt projekt. Når tiden – og viden om dit produkt – øges, falder evnen til at foretage ændringer og koster mere.
I modsætning hertil er agil projektledelse systematisk tilgængelige. Fleksibiliteten ved agil projektledelse øger projektets stabilitet, fordi ændringer i et agilt projekt er forudsigelige og håndterbare.
Når nye muligheder udspiller sig, tilføjer projektgruppen disse muligheder i det igangværende arbejde. Enhver ny mulighed bliver igangsat for at give yderligere værdi i stedet for at se det som en hindring at undgå, hvilket giver projektgruppen en større mulighed for succes.
Principperne bag manifestet for agil softwareudvikling
I månederne efter offentliggørelsen af det agile manifest fortsatte grundlæggerne med at støtte de projektledere, der foretog overgangen til den agile metode. Det gjorde de ved at udvide manifestets fire værdier med 12 agile principper.
Disse principper kan bruges til at tjekke, om dit projekt bliver kørt som et agilt projekt:
- Vores højeste prioritet er at stille kunden tilfreds gennem tidlige og løbende afleveringer af værdifuld software
- Vi imødekommer ændringer i krav, også selvom de fremkommer sent i udviklingen. De agile processer sikrer, at ændringer er til kundens fordel.
- Løbende levering af velfungerende software, jo hyppigere dets bedre.
- Forretningsrepræsentanter og udviklere skal samarbejde dagligt gennem hele projektet.
- Opbyg projekterne omkring motiverede personer. Giv dem de rette omgivelser og den nødvendige støtte, og stol på at de kan klare opgaven.
- Den mest effektive kommunikationsform er samtale ansigt til ansigt.
- Fungerende software er den primære måde at måle fremdrift på.
- Agile processer fremmer bæredygtig udvikling. Systemejere, udviklere og brugere bør til enhver tid kunne opretholde et fast udviklingstempo.
- Fokus på teknisk ekspertise og godt design fremmer den agile udvikling.
- Enkelhed, defineret som kunsten at maksimere mængden af ikke udført arbejde, er essentiel.
- De bedste arkitekturer, krav og designs stammer fra selvorganiserende teams.
- Med jævne mellemrum reflekterer gruppen over, hvordan den kan blive mere effektiv, og tilpasser sin adfærd derefter.
Hvis du nogensinde er i tvivl om en bestemt proces, praksis, værktøj eller tilgang, overholder det agile manifest eller de 12 principper, kan du bruge følgende liste over spørgsmål til at finde ud af det:
- Understøtter det, du gør lige nu, en tidlig og kontinuerlig levering af et værdifuldt slutprodukt?
- Er jeres proces, åben for forandring, og drager den fordel af de forandringer?
- Fører jeres proces til, og understøtter den levering af et nyttigt slutprodukt?
- Arbejder både du og leverandøren tæt sammen under hele projektet? Og er begge parter med til at komme frem til løsninger på problemerne?
- Kommunikerer du ansigt til ansigt mere end via telefon og e-mail?
- Måler du fremskridtene med den mængde værdi, som vi har af slutproduktet?
- Kan I opretholde dette tempo på ubestemt tid?
- Maksimerer du mængden af arbejde, der ikke er udført – nemlig at gøre så lidt som der er nødvendigt for at opfylde projektets mål?
Hvis du svarede “ja” på alle disse spørgsmål, så ja, så arbejder du agilt med dine projekter. Hvis du svarede “nej” på nogen af disse spørgsmål, hvad kan du så gøre for at ændre dette svar til “ja”?
