Det agile manifest forklaret, og hvordan du anvender det

Hvad er det agile manifest?

Det agile manifest er en skriftlig erklæring, der indeholder fire værdier og 12 principper, som har til formål at forbedre arbejdsmetoder inden for softwareudvikling.

Manifestet er mere filosofisk end foreskrivende og var tænkt til at kunne tilpasses forskellige teamstørrelser, mål og forhold.

Det agile manifests fire værdier

Det officielle agile manifest består af disse fire værdier:

1. Individer og interaktioner frem for processer og værktøjer
2. Fungerende software frem for omfattende dokumentation
3. Samarbejde med kunden frem for kontraktforhandling
4. Reaktion på forandringer frem for at følge en plan

Det er interessant at bemærke, at forfatterne fulgte værdierne op med denne præciserende erklæring: "Det vil sige, at selv om der er værdi i punkterne til højre, værdsætter vi punkterne til venstre højere."

Dette understreger idéen om, at det agile manifest ikke handler om at følge en bestemt proces eller bruge et specifikt agilt værktøj. Det handler om at tilegne sig en bestemt tankegang.

Det agile manifests tolv principper

Ud over de fire værdier oplister det agile manifest 12 understøttende principper, der forklarer, hvordan værdierne skal fortolkes og anvendes i agile projekter.

1. Sæt kunden først

Den højeste prioritet er at tilfredsstille kunden gennem tidlig og kontinuerlig levering af værdifuld software.

2. Tag imod forandringer

Byd ændrede krav velkommen, selv sent i udviklingen. Agile processer udnytter forandringer til kundens konkurrencemæssige fordel.

3. Lever hyppigt

Lever fungerende software hyppigt, fra et par uger til et par måneder, med en præference for den kortere tidsskala.

4. Samarbejd på tværs af teams

Forretningsfolk og udviklere skal arbejde sammen dagligt gennem hele projektet.

5. Udvikl talent

Byg projekter op omkring motiverede individer. Giv dem de rammer og den støtte, de har brug for, og stol på, at de får arbejdet gjort.

6. Tal sammen

Den mest effektive metode til at formidle information til og internt i et udviklingsteam er en samtale ansigt til ansigt.

7. Mål det, der betyder noget

Fungerende software er det primære mål for fremskridt.

8. Tilpas arbejdstempoet for at undgå udbrændthed

Agile processer fremmer bæredygtig udvikling. Sponsorer, udviklere og brugere bør kunne opretholde et konstant tempo på ubestemt tid.

Stay Ahead of What Deserves Your Attention

Get timely perspective on the shifts, decisions, and trade-offs shaping your role, plus practical resources you can put to work.

Get Free Access

Have an account? Log In

9. Fokuser på kvalitet, så går arbejdet hurtigere

Vedvarende fokus på teknisk ekspertise og godt design øger agiliteten.

10. Omfavn enkelhed

Enkelhed–kunsten at maksimere mængden af arbejde, der ikke udføres–er afgørende.

11. Lad være med at detailstyre

De bedste arkitekturer, krav og designs opstår i selvorganiserende teams.

12. Reflektér og tilpas

Med jævne mellemrum reflekterer teamet over, hvordan det kan blive mere effektivt, og finjusterer og tilpasser derefter sin adfærd.

Historien, forfatterne og oprindelsen til Det Agile Manifest

I teknologiverdenen diskuteres Det Agile Manifest med samme ærbødighed og respektløshed som enhver hellig tekst, der er blevet overleveret gennem tiden.

I februar 2001 samledes 17 softwareprofessionelle, der kaldte sig selv "The Agile Alliance", i den amerikanske delstat Utah for at udvikle det, de kaldte et "Manifest for agil softwareudvikling". Dokumentet, der fremhæver fire værdier og 12 principper, er nu kendt som Det Agile Manifest.

Forfatterne til Det Agile Manifest omtales ofte som The Agile Alliance og omfattede repræsentanter for forskellige udviklingsprocesser, herunder ekstrem programmering, Scrum og Crystal. 

Et hurtigt kig på manifestets officielle websted viser forfatterne i en sammenhæng, der kan lede tankerne hen på et hemmeligt selskab eller et møde mellem grundlæggere. Det var tydeligt, at deres hensigt var at skabe noget, der ville sætte et varigt aftryk på branchen. Det har det bestemt gjort.

Selvom de personer, der mødtes i Utah, ikke var pionerer inden for agile principper generelt, fastlagde de de værdier, der i nogen tid havde været under udvikling i baggrunden af softwareudviklingsverdenen.

I dag har den agile metode bredt sig til næsten alle brancher.

Forfatterne omfattede:

• Kent Beck
• Mike Beedle
• Arie van Bennekum
• Alistair Cockburn
• Ward Cunningham
• Martin Fowler
• James Grenning
• Jim Highsmith
• Andrew Hunt
• Ron Jeffries
• Jon Kern
• Brian Marick
• Robert C. Martin
• Steve Mellor
• Ken Schwaber
• Jeff Sutherland
• Dave Thomas

Hvorfor Det Agile Manifest (stadig) er vigtigt

Det Agile Manifest er stadig relevant på grund af dets fokus på menneskecentrerede arbejdsmetoder og dets mulighed for fleksibilitet.

Hurtige teknologiske forandringer medfører ofte ændrede projektkrav. Det Agile Manifest gør det muligt for projektledere at prioritere tilpasningsevne og samarbejde ved at skabe et responsivt og modstandsdygtigt projektmiljø, der samtidig kan levere arbejde, innovere og skifte retning efter behov.

Det fremmer også en kundecentreret tankegang ved at værdsætte fungerende løsninger højere end omfattende dokumentation. Det giver projektledere mulighed for at indsamle feedback tidligt og løbende videreudvikle deres arbejde, så projektet i højere grad stemmer overens med brugernes behov. Denne iterative og kundedrevne tilgang øger sandsynligheden for et vellykket projekt og tilfredsheden.

Sådan anvender du Det Agile Manifest

Lad os se lidt nærmere på hver af de fire værdier i Det Agile Manifest. Ved at gennemgå kerneværdierne undersøger vi også de 12 principper, der bygger videre på hver af dem.

Værdi nr. 1: Individer og interaktioner frem for processer og værktøjer

Agiles kerne handler om mennesker. Agile understreger, at et team arbejder sammen, samarbejder tæt og træffer beslutninger selvstændigt. Agile handler ikke om at fortælle et team, hvad det skal gøre eller bygge. 

I agile projekter skal kommunikationen flyde frit og være løbende, ikke være fastlagt og planlagt. At arbejde i lukkede siloer er ikke det, agile handler om.

Vurdér teamets kommunikation

Spørg dig selv: Har du og dit team samtaler ansigt til ansigt? Eller er I afhængige af e-mails, dokumenter og bestemte meget populære beskedværktøjer (uden at nævne nogen ved navn her)? 

Selv hvis I arbejder på afstand, kan en samtale ansigt til ansigt få tingene til at ske hurtigere. Især når et team er ved at blive dannet, fremmer synkron kommunikation tillid og åbenhed og hjælper med at opbygge relationer.

Vær mindre kontrolfikseret

Vi har alle gjort os skyldige i dette en gang imellem. Men tillid er afgørende for agile arbejdsmetoder. Leder du efter noget, du kan implementere med det samme? MIKROADMINISTRÉ IKKE (ja, jeg mente at råbe det).

Det er fristende at gå helt ned i detaljerne omkring opgaverne, uddele dem til teamet og derefter følge dem, indtil de når den fastsatte deadline (eller ikke gør), så du har kontrol over det hele. Men hvis du virkelig vil styrke dit team, skal du træde lidt tilbage og lade dem tage ejerskab over deres arbejde!

Styrk et selvorganiserende team

Det handler ikke om at lede – det handler om at være leder og facilitator. Et selvorganiserende team betyder, at teamet selv vælger, hvordan arbejdet bedst udføres. De bør beslutte, hvordan arbejdsefterslæbet kan omdannes til kode, der kan udgives. Men gå ikke til den modsatte yderlighed og undlad al hjælp eller vejledning – teamet har stadig brug for en vision, motivation og hjælp til at løse blokeringer.

Hvordan kommer du så væk fra at uddele opgaver og i stedet afgør, hvordan du kan facilitere arbejdet?

Stress ikke over processen eller værktøjet

Jeg ved det, jeg ved det – der bliver hele tiden talt om projektstyringsværktøjer og agil projektstyringssoftware i den agile PM-verden.

Men her er sagen: Din kunde er ligeglad med din interne agile arbejdsproces. Det bør de også være.

Agilitet handler om at anlægge en kundecentreret tilgang og gøre dit team i stand til at levere bedre og mere værdifuldt arbejde. Mere om den kundecentrerede tilgang senere!

Fjern siloer

Siloer hæmmer samarbejdet og svækker derfor de agile værdier. 

Overvej disse tips for at komme væk fra siloer:

• Placér teamet samme sted: Ja, denne igen. Det er fantastisk, hvis dine designere kan sidde tæt på hinanden og tale om design, men er det ikke bedre, hvis de taler med udviklerne om at bygge dette fantastiske produkt? Jeg ved, at det kan være svært at implementere i en større organisation eller i fjernarbejdsmiljøer, men selv det at mødes i en fælles Slack-kanal eller have planlagte samarbejdssessioner, hvor folk kan udføre fordybelsesarbejde samtidig og på afstand, kan holde dit team bedre forbundet.
• Modvirk overdragelser mellem afdelinger: Den mere trinvise, vandfaldslignende tilgang, hvor hver afdeling arbejder i etaper (UX, derefter design, derefter udvikling, derefter QA), kan ofte medføre kommunikationsbrist og øge spildet i et projekt. Overvej at få dit team til at arbejde sammen om funktioner i stedet for at overdrage arbejdet ned gennem en kæde. Selv hvis I arbejder i sprints, men med et indledende designsprint, bør du involvere dine udviklere i designsprintet – det er trods alt dem, der skal bygge dette!

Værdi nr. 2: Fungerende software frem for omfattende dokumentation

Husk, at manifestet ikke siger, at dokumentation skal afskaffes – det værdsætter blot punkterne til venstre højere end dem til højre. Det betyder, at dokumentation stadig findes. Scrum har for eksempel brugerhistorier, der fortæller en udvikler, hvordan vedkommende kommer i gang med opbygningen.

Men hvad kan du gøre for at bevæge dig væk fra den omfattende, tidskrævende dokumentation og hurtigt komme i gang med noget håndgribeligt?

Strømlin den dokumentation, du bruger

Identificér eventuelle problemer eller blokeringer i din proces. Bruger du for meget dokumentation? Bruger du en evighed på at udarbejde det perfekte kravdokument, bruger du lang tid på en funktionel afgrænsning og løber derefter tør for tid til at bygge produktet? Reducér unødvendig dokumentation ved at:

• Fokusere på design- og udviklingsopgaver, der indgår i selve produktet, frem for et skriftligt dokument, som i sidste ende ikke vil blive brugt
• Afholde workshops tidligt for at definere krav og næste skridt i stedet for at udarbejde lange dokumenter. Dokumentér og del resultaterne med fotos og korte noter.

Kom hurtigt i gang med opbygningen

At skrive lange kravdokumenter er én måde at kortlægge virksomhedens, kundens og slutbrugerens behov på. Men i sidste ende er det langt mere nyttigt at se noget fungere, opføre sig og reagere.

Overvej nogle af følgende måder at skubbe dit projekt hurtigt fremad på:

• Komprimér den indledende afdækning eller afgrænsning til en kortere tidsramme: Ved at begrænse den tid, du bruger på at definere og afklare ting, kan du hurtigere nå frem til noget, som designerne og udviklerne kan arbejde med. Du kan fremskynde processen ved hjælp af disse spørgsmål til afdækningssessionen.
• Afhold workshops: Workshops med teamet samler interessenterne, så beslutninger kan træffes hurtigere.
• Ændr din projektplan: Har du lagt afgrænsning, derefter design og derefter udvikling i forlængelse af hinanden? Overvej at fremrykke udviklingen og få designere og udviklere til at producere noget sammen tidligere.

Brug prototypemetoder frem for flade designs

I stedet for at se fremskridt som et definitionsdokument eller et fladt design, som blot er et afkrydsningsfelt, klienten skal godkende, kan du vise dem noget, der bliver en del af det færdige produkt.

Brug hurtig prototyping for at få noget til at fungere og være anvendeligt – og endnu vigtigere noget, du kan teste med kunder. Indsamling af feedback på en prototype bliver en nyttig måde at følge fremskridt på i stedet for at være afhængig af en leverance, der ikke har den fordel, at den er en del af det endelige produkt.

Du kan oprette prototyper med forskellige detaljeringsgrader:

• Lav detaljeringsgrad: Klikbare designs. Det er, når du hurtigt har brug for at lave en skitse, der kan testes med kunder, og hvor fokus i højere grad er på udseende, fornemmelse og enkle interaktioner.
• Mellem detaljeringsgrad: Brug af bevægelse eller animation.
• Høj detaljeringsgrad: Fungerende HTML. Bruges til komplekse interaktioner, men kan videreføres til kode, der er klar til udgivelse.

Prototyper med høj detaljeringsgrad ligger tættere på “fungerende software” end de andre typer, men det kan tage længere tid at producere dem. Prototyper med lav eller mellem detaljeringsgrad giver udviklerne bedre vejledning end flade designs.

Lever hurtigt noget til slutbrugeren eller kunden

Dette er vigtigt.

Ved hyppige udgivelser af fungerende software kan kunden engagere sig i alle nye funktioner, der er blevet udgivet. I stedet for at vente til slutningen af projektet på en stor lancering, er det afgørende at levere værdi til kunden tidligere for at skabe et bedre produkt.

Hvordan kan du opnå hyppigere leverancer i din organisation?

• Gennemgå din projektplan eller din projektkøreplan: Har du planlagt at færdiggøre udviklingen og derefter lancere ved projektets afslutning? Arbejd i stedet sammen med dit team om at opdele arbejdet i funktioner eller arbejdsdele, der kan udgives uafhængigt undervejs.
• Fokuser på blokeringer: En central del af din rolle er at hjælpe teamet med at fjerne blokeringer, når der opstår problemer. Hvordan kan du hjælpe dem med at levere mere effektivt? Er der arbejdsmetoder, der forsinker udgivelserne? En sprintretrospektiv med dit team kan afdække muligheder for procesforbedringer.
• Automatiser: Hvis din organisation bruger mange kræfter på udgivelser, skal du automatisere processer, hvor det er muligt. Automatiserede tests og implementering kan for eksempel spare manuelt arbejde og reducere den indsats, der kræves for en udgivelse. Tal med dit agile udviklingsteam om de processer, de bruger, og mulighederne for automatisering.

Værdi nr. 3: Kundesamarbejde frem for kontraktforhandling

I stedet for at udarbejde en ekstremt specifik kontrakt i begyndelsen af et projekt, der beskriver præcise leverancer, omfang, budget og tidsplaner, skal du holde din agile kontrakt så overordnet som muligt. Træf beslutninger undervejs i projektet ved at samarbejde tæt med dine kunder og interessenter.

Agile handler ikke om at bruge masser af tid på at definere krav på forhånd. Det handler om at komme i gang med et projekt og lære undervejs baseret på kundetest og feedback fra fungerende software.

Anvend en kundecentreret tilgang

Jeg elsker dette citat fra en artikel af Neil Killick:

“En agil tænker spørger hele tiden: ‘Hvad er den enkleste/hurtigste måde at skabe værdi for kunden på?’ Stiller du det spørgsmål hver dag? Hvis ikke, er det dit første skridt.”

Det er ikke kun designere og udviklere, der bør tænke sådan – det bør projektledere også. Vi er også ansvarlige for at levere det bedst mulige produkt eller den bedst mulige service til en kunde. Din kunde, brugeren af dit produkt eller din service, bør være i centrum for alt, hvad du gør.

Sæt slutkunden i centrum for planen

I stedet for at planlægge ud fra leverancer og estimater skal du planlægge ud fra værdifulde resultater for kunden. Hvad ønsker vi, at kunden skal gøre, og hvorfor? Hvordan måler vi, om det virker?

Gentænk samtalen, så den fokuserer på, hvilken værdi vi har leveret til kunden, frem for hvor mange arbejdsopgaver vi har leveret.

Inddrag din klient tæt

I stedet for at holde et ugentligt statusmøde og derefter levere til din klient og interessenter ved slutningen af en bestemt periode skal du arbejde på at involvere din klient i projektet på daglig basis.

Hvis du arbejder mere efter en Scrum-proces, skal du gøre kunden til produktejer. Produktejeren er ansvarlig for at samle forretningsmæssige, tekniske og kundemæssige krav. Det er afgørende at få kundens opbakning og samarbejde tidligt i processen og løbende for at undgå forsinkelser. Det skaber i sidste ende et bedre produkt eller en bedre service for slutkunden.

Inddrag en kunde, der er på afstand

Hvis din kunde ikke har tid til at bidrage til projektet eller af andre grunde ikke er engageret, skal du sørge for, at en person på teamet repræsenterer kunden. Det er afgørende, at nogen tager hensyn til kundens og virksomhedens behov.

Selv hvis kunden ikke er involveret fra dag til dag, skal du sørge for at kommunikere med dem regelmæssigt og som minimum inddrage dem i alle diskussioner om agil planlægning og prioritering. Arbejd sammen med dem for at demonstrere fordelene ved deres involvering.

Udarbejd en produktkøreplan

Overvej at bruge en produktkøreplan til at kortlægge dit produkts udvikling. En produktkøreplan kommunikerer planen for produktet og visualiserer de funktioner, der er planlagt til levering. En køreplan er ikke fastlagt ved projektets begyndelse; den udvikler sig derimod over tid for at afspejle ændringer i prioriteringen.

Sørg for, at du taler med dine slutbrugere eller kunder

Jeg kan ikke understrege det nok – du skal forsøge at teste dit produkt med slutbrugere og kunder tidligt og ofte. 

Test giver så mange fordele:

• Du kan sikre, at dit produkt opfylder kundernes behov, dvs. er produktet værdifuldt for kunden og dermed for virksomheden? Det hjælper dig med at vurdere, om der er et produkt-marked-match.
• Du kan indarbejde kundefeedback i din design- og udviklingsproces, hvilket resulterer i et bedre slutprodukt.
• Du kan opnå indsigt, som kan bruges i det fremtidige arbejde.

• Det ofte nævnte problem med kundetest er budgettet – det kan være dyrt. Her er nogle måder at teste på, uanset projektets budget:

Guerillatest: Jeg elsker denne metode, fordi den er billig og nem. Tilbyd at købe en rigtig (eller virtuel) kop kaffe til folk, hvis de vil svare på nogle spørgsmål om dine designs eller din prototype. Det er sværere at specificere, hvem der svarer på dine spørgsmål, men hurtig feedback kan være nyttig, når du tester udseende og fornemmelse eller simple interaktioner.

Spørgeskemaer: Hvis du vil indsamle kvantitative data fra en bredere gruppe mennesker, kan du oprette et spørgeskema for at evaluere designet eller undersøge kundeadfærd mere dybdegående.

Sider som usertesting.com: Du kan uploade dine designs til en af disse sider og rekruttere folk gennem dem (ved hjælp af kriterier, hvis det er nødvendigt). De vil derefter klikke sig gennem dine designs, optage deres tanker og besvare spørgsmål.

Ansigt-til-ansigt-test: Ja, dette kan være en dyrere løsning, da du sandsynligvis skal rekruttere folk og betale incitamenter; det kan dog være uvurderligt, hvis du tester komplekse interaktioner eller funktioner med høj risiko.

Værdi nr. 4: Reagér på ændringer i stedet for at følge en plan

Agile projekter og vandfaldsprojekter kunne ikke være mere forskellige på dette punkt. I traditionelle softwareudviklingsprojekter fastlægger du krav, omkostninger og tidsplaner på forhånd, mens agil udvikling tillader og omfavner ændringer.

Ændringer er gode! De er ikke onde! Hvor mange projektplaner er præcis blevet gennemført, sådan som du udarbejdede dem i begyndelsen? Ikke mange, vil jeg tro (jeg har arbejdet på projekter med dusinvis af gentagelser af projektplanen).

Planer er det bedste gæt på et bestemt tidspunkt, og du kan gøre dem mere præcise, efterhånden som du bevæger dig fremad – de har dog en tendens til ikke at give plads til ændringer. Hvad sker der, hvis kundens behov ændrer sig? Hvis virksomheden skifter kurs? Hvis din kunde ændrer prioriteter? Hvis den angivne funktion ikke er så enkel at bygge, som du troede.

Agile arbejdsmetoder omfavner usikkerhed ved at anvende en adaptiv planlægningstilgang (såsom planlægningspoker). Scrum-værdierne foreskriver for eksempel, at teamet planlægger arbejdet sprint for sprint. Før en tidsafgrænset arbejdsperiode begynder, tager agile teams elementer fra backloggen og prioriterer dem til udvikling.

Selvom der ofte er et pres for at fastlåse omkostninger, tidsplan og omfang ved projektets begyndelse, giver det ofte et langt bedre slutprodukt at være mere realistisk omkring den usikkerhed, du står over for. I sidste ende er det det, du, kunden og dine interessenter bør ønske. 

Her er nogle måder at begynde at give plads til ændringer i dine projekter og tilskynde til større fleksibilitet:

Udarbejd en “let” plan for at tilfredsstille interessenterne

“Men vi har brug for en plan!”, råber dine interessenter. I stedet for at skræmme dem ved at sige: “Overraskelse, der er ingen plan!”, skal du udarbejde en enkel leveranceplan for at give dem tillid til den lidt mindre formelle tilgang.

Hvis du arbejder med agile projektledelse ved hjælp af Scrum-processer, har du en liste med prioriterede og estimerede brugerhistorier i din backlog. Arbejd sammen med produktejeren om at gruppere disse i overordnede releases, og kortlæg dem på din produktroadmap.

Prøv ikke at planlægge alt, da det underminerer fordelene ved at bruge Scrum-metoden. Vis dine interessenter, hvad du planlægger i de første to eller tre releases, og forklar dem derefter, hvordan genplanlægning er en central del af en agil arbejdsform, og at du vil kommunikere opdateringer og yderligere releases undervejs. Forhåbentlig giver det dem den nødvendige tryghed!

Introducer teamet gradvist til en sprintbaseret tilgang

Mike Cohn foreslår i sin artikel “Introduktion af en agil proces i en organisation” at hjælpe teams med gradvist at vænne sig til Scrum ved at definere et sæt sprinttyper, for eksempel:

• Prototypeudvikling
• Indsamling af krav
• Analyse og design
• Implementering
• Stabilisering

Her beskriver han, hvordan dette kan hjælpe:

“Vi arbejder derefter sammen med teamsene om at definere de artefakter, der vil være resultatet af hver sprinttype. Brug af sprinttyper introducerer netop så meget formalisme, at teamsene tydeligere kan se deres vej gennem projektet. Efterhånden som teamsene bliver bedre til den uformelle agile proces, udfaser de gradvist konceptet med sprinttyper.”

Dette er endnu en måde at forme din releaseplan på. Hvis du tildeler hver sprint en “type”, kan dine interessenter se, hvordan planen tager form, samtidig med at du undgår at skulle garantere funktioner. Dit team får også en bedre fornemmelse af, hvad de skal arbejde med.

Gå væk fra faste deadlines

At give dit team en deadline eller kommunikere en fast dato til din kunde er strategier, der enten er dømt til at mislykkes eller i det mindste medfører stress undervejs. Det er afgørende at opbygge tillid mellem dig og dit team samt din kunde eller interessent for at bevise, at du vil levere – og levere værdi – til slutkunden.

Husk, at du forsøger at reducere behovet for flere kontrolpunkter og godkendelser. Deadlines på dit projekt hjælper dig ikke med at nå dette mål. Det er heller ikke godt konstant at ånde dit team i nakken og presse dem for det arbejde, de “lovede” at levere.

Som jeg nævnte ovenfor, kan roadmaps og releaseplaner være en god mekanisme til at bevæge sig væk fra en tilgang med faste datoer. At give interessenterne en fornemmelse af, hvad der vil blive udgivet i den nærmeste fremtid, kan forsikre dem om, at der er en plan.

Brug et omfang baseret på tid og materialer

Hvis du har et omfang med fast pris og faste leverancer, er det svært at levere på en mere agil måde. Du kan bestemt anvende nogle af de teknikker, jeg allerede har gennemgået, såsom at muliggøre et mere samarbejdsorienteret team. Men du vil være begrænset i, hvor meget du kan reagere på og tilpasse dig ændringer, lade teamet bestemme, hvad de arbejder med, eller bruge en mere kundecentreret tilgang.

Arbejd sammen med dit interne team og kunden om at etablere et omfang baseret på tid og materialer – dvs. at kunden betaler for et team frem for faste leverancer. I begyndelsen kan kunder blive nervøse, hvis de ikke ved præcis, hvad de får.

For at imødegå denne bekymring kan du inkludere en backlog med aktiviteter eller opgaver, der kan komme i betragtning til lancering, som en del af omfanget. Angiv i kontrakten, at teamet vil genplanlægge og prioritere backloggen med input fra kunden, efterhånden som projektet skrider frem (selvom I måske ikke kommer omkring alle punkter).

For at hjælpe med at håndtere skiftende prioriteter og leverancer kan teams benytte agil styringssoftware til løbende at omprioritere deres backlog og samarbejdsværktøjer til softwareudvikling til at koordinere samarbejde på tværs af funktioner.

På denne måde forpligter du dig ikke til et fast omfang, men kunden har færre bekymringer om, hvordan det færdige produkt kommer til at se ud.

Fortsæt med at følge fremdriften

Opfølgning på og visualisering af fremdriften ryger ikke ud ad vinduet, fordi der ikke findes en formel projektplan. Ved at holde fremdriften synlig for teamet og interessenterne sikrer du ikke blot, at du ikke mister potentielle blokeringer og flaskehalse af syne, men holder også interessenterne orienteret. 

Et Kanban-lignende WIP-board eller agile kontrolpaneler fungerer godt til agile projekter. Når du har visualiseret din proces, kan du begynde at kortlægge understøttende opgaver og aktiviteter. Det hjælper dig med at identificere flaskehalse, som du kan fjerne for at muliggøre hurtigere levering til kunden.

Kritik af Det Agile Manifest

Som enhver anden projektledelsesmetodologi er agil ikke perfekt. Kritikere påpeger, at forfatterne bag Det Agile Manifest var en homogen gruppe, som måske ikke tog alternative arbejdsmetoder i betragtning, såsom fordelene ved at arbejde på afstand eller hvordan agilitet kan anvendes uden for softwareudviklingsområdet.

Hvis agilitet føres for langt, kan det betyde, at beslutninger træffes af et udvalg, hvilket sænker arbejdstempoet. Manglende dokumentation kan ende med at skade projektleveringen, især i et miljø med fjernarbejde, hvor asynkron kommunikation er afgørende.

Hvis du beslutter dig for at bruge agile metoder i dine projekter, skal du sørge for at rådføre dig med de agile værdier og principper. De er en nyttig vejledning til at holde de værste tendenser ved agile metoder i skak.

Læs mere om debatten om, hvorvidt agilitet er en metode eller en tankegang her.

Agilitet, ikke agile metoder

En sidste tanke er: Husk retrospektivet! Som manifestet siger:

Med regelmæssige mellemrum reflekterer teamet over, hvordan det kan blive mere effektivt, og tilpasser derefter sin adfærd i overensstemmelse hermed.

Uanset hvilken type proces du arbejder med, er retrospektivet en effektiv måde at undersøge, hvordan I arbejder, og optimere med henblik på succes. Sørg for regelmæssigt at inkludere projektretrospektiver i den proces, du bruger – og sørg for, at du har en mekanisme til at indarbejde jeres læring! PS: Det er vigtigt at få dine mere stille teammedlemmer til at tale med under retrospektiver – her kan du se hvordan.

Hvad er det næste?

Hvis du vil vide mere om, hvordan du implementerer agile arbejdsmetoder og lærer af de bedste projektledere i branchen, kan du se vores DPM-medlemsmuligheder.