Det agila manifestet förklarat och hur du tillämpar det

Vad är det agila manifestet?

Det agila manifestet är en skriftlig proklamation som innehåller fyra värderingar och 12 principer som är avsedda att förbättra arbetssätt inom mjukvaruutveckling.

Manifestet var mer filosofiskt än föreskrivande och var tänkt att kunna anpassas till team av olika storlek samt olika mål och förutsättningar.

Det agila manifestets 4 värderingar

Det officiella agila manifestet består av dessa 4 värderingar:

1. Individer och samspel framför processer och verktyg
2. Fungerande mjukvara framför omfattande dokumentation
3. Samarbete med kunden framför avtalsförhandling
4. Att reagera på förändringar framför att följa en plan

Det är intressant att notera att författarna följde värderingarna med detta förtydligande: "Det vill säga att även om det finns ett värde i punkterna till höger, värderar vi punkterna till vänster högre."

Detta understryker idén att det agila manifestet inte handlar om att följa en viss process eller använda ett specifikt agilt verktyg. Det handlar om att anta ett specifikt tankesätt.

Det agila manifestets 12 principer

Utöver de fyra värderingarna listar det agila manifestet 12 stödjande principer som förklarar hur värderingarna ska tolkas och tillämpas i agila projekt.

1. Sätt kunden främst

Den högsta prioriteten är att tillfredsställa kunden genom tidig och kontinuerlig leverans av värdefull mjukvara.

2. Välkomna förändringar

Välkomna förändrade krav, även sent i utvecklingen. Agila processer utnyttjar förändringar till kundens konkurrensfördel.

3. Leverera ofta

Leverera fungerande mjukvara ofta, från ett par veckor till ett par månader, med en förkärlek för den kortare tidsramen.

4. Samarbeta mellan team

Affärsrepresentanter och utvecklare måste arbeta tillsammans dagligen under hela projektet.

5. Utveckla talanger

Bygg projekt kring motiverade individer. Ge dem den miljö och det stöd de behöver, och lita på att de får jobbet gjort.

6. Prata

Den mest effektiva metoden för att förmedla information till och inom ett utvecklingsteam är ett samtal ansikte mot ansikte.

7. Mät det som betyder något

Fungerande mjukvara är det främsta måttet på framsteg.

8. Anpassa arbetstakten för att undvika utbrändhet

Agila processer främjar hållbar utveckling. Sponsorer, utvecklare och användare bör kunna hålla en jämn takt på obestämd 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.

Create Free Account

Have an account? Log In

9. Fokusera på kvalitet så går arbetet snabbare

Kontinuerlig uppmärksamhet på teknisk spetskompetens och god design förbättrar agiliteten.

10. Omfamna enkelhet

Enkelhet–konsten att maximera mängden arbete som inte behöver utföras–är avgörande.

11. Detaljstyr inte

De bästa arkitekturerna, kraven och designerna växer fram ur självorganiserande team.

12. Reflektera och justera

Med regelbundna intervall reflekterar teamet över hur det kan bli mer effektivt och finjusterar och justerar sedan sitt beteende därefter.

Historien bakom, författarna till och ursprungsberättelsen om Agila manifestet

Inom teknikvärlden diskuteras Agila manifestet med samma vördnad och respektlöshet som vilken helig text som helst som har förts vidare över tid.

I februari 2001 samlades 17 mjukvaruprofessionella, som kallade sig själva ”The Agile Alliance”, i den amerikanska delstaten Utah för att utveckla vad de kallade ett ”Manifest för agil mjukvaruutveckling”. Dokumentet, som betonar fyra värderingar och 12 principer, är nu känt som Agila manifestet.

Författarna till Agila manifestet hänvisas ofta till som The Agile Alliance och inkluderade representanter för olika utvecklingsprocesser, däribland extremprogrammering, Scrum och Crystal. 

En snabb titt på den officiella webbplatsen för manifestet visar författarna i en miljö som kan föra tankarna till ett hemligt sällskap eller ett möte med grundlagsfäder. Det stod klart att deras avsikt var att skapa något som skulle lämna ett bestående avtryck i branschen. Det har det definitivt gjort.

Även om personerna som träffades i Utah inte var pionjärerna bakom agila principer i allmänhet, befäste de de värderingar som under en tid hade vuxit fram i bakgrunden av mjukvaruutvecklingsvärlden.

I dag har den agila metoden genomsyrat nästan alla branscher.

Författarna var:

• 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

Varför Agila manifestet fortfarande är viktigt

Agila manifestet är fortfarande relevant tack vare sitt fokus på människocentrerade arbetssätt och sin flexibilitet.

Snabba tekniska förändringar medför ofta förändrade projektkrav. Agila manifestet gör det möjligt för projektledare att prioritera anpassningsförmåga och samarbete genom att skapa en lyhörd och motståndskraftig projektmiljö som samtidigt kan leverera arbete, förnya sig och byta riktning vid behov.

Det främjar också ett kundcentrerat tankesätt genom att värdesätta fungerande lösningar framför omfattande dokumentation. Det gör det möjligt för projektledare att samla in återkoppling tidigt och kontinuerligt förfina sitt arbete, så att projektet ligger nära användarnas behov. Detta iterativa och kunddrivna arbetssätt ökar projektens framgångsgrad och kundnöjdhet.

Så tillämpar du Agila manifestet

Vi ska gå lite djupare in på var och en av de fyra värderingarna i Agila manifestet. Genom att gå igenom kärnvärderingarna utforskar vi också de 12 principer som bygger vidare på var och en av dem.

Värdering nr 1: Individer och samspel framför processer och verktyg

Agil utveckling handlar i grunden om människor. Agilt arbetssätt betonar att ett team arbetar tillsammans, samarbetar nära och fattar beslut självständigt. Agilt arbetssätt handlar inte om att tala om för ett team vad det ska göra eller bygga. 

I agila projekt måste kommunikationen vara fri och kontinuerlig, inte definierad och schemalagd. Att arbeta i avskärmade silos är inte vad agilt arbetssätt handlar om.

Utvärdera teamets kommunikation

Fråga dig själv: har du och ditt team samtal ansikte mot ansikte? Eller förlitar ni er på e-post, dokument och vissa särskilt omtyckta meddelandeverktyg (inga namn nämns här)? 

Även om ni arbetar på distans kan ett samtal ansikte mot ansikte göra att saker händer snabbare. Särskilt när ett team håller på att bildas uppmuntrar synkron kommunikation tillit och öppenhet och bidrar till att bygga relationer.

Var mindre av ett kontrollfreak

Vi har alla gjort oss skyldiga till detta ibland. Men tillit är en integrerad del av agilt arbetssätt. Letar du efter något du kan införa direkt? MIKROSTYR INTE (ja, jag menade att skrika det).

Det är frestande att bryta ner uppgifterna i detalj, dela ut dem till teamet och sedan följa upp dem tills de når den pålagda tidsfristen (eller inte), så att du har kontroll över allt. Men för att verkligen ge ditt team handlingsutrymme behöver du backa lite och låta dem ta ägarskap över sitt arbete!

Uppmuntra ett självorganiserande team

Det handlar inte om att hantera – det handlar om att leda och underlätta. Ett självorganiserande team innebär att teamet väljer hur arbetet bäst ska genomföras. De bör själva bestämma hur de ska omvandla arbetsbackloggen till kod som kan lanseras. Men gå inte till den motsatta ytterligheten och ge ingen hjälp eller vägledning – teamet behöver fortfarande en vision, motivation och hjälp med att lösa hinder.

Hur gör du då för att sluta dela ut uppgifter och i stället avgöra hur du kan underlätta arbetet?

Stressa inte över processen eller verktyget

Jag vet, jag vet – det talas ständigt om verktyg för projektledning och programvara för agil projektledning i världen för agila projektledare.

Men så här ligger det till: Din kund bryr sig inte om din interna agila arbetsprocess. Och det bör de inte heller göra.

Agilt arbetssätt handlar om att sätta kunden främst och ge teamet möjlighet att leverera bättre och mer värdefullt arbete. Mer om kundfokus senare!

Ta bort stuprören

Stuprör hindrar samarbete och motverkar därför agila värderingar. 

Överväg följande tips för att komma bort från stuprör:

• Samplacera teamet: Ja, den här punkten igen. Det är bra om era designers kan sitta nära varandra och prata om design, men vore det inte bättre om de pratade med utvecklarna om att bygga den här fantastiska produkten? Jag vet att det kan vara svårt att genomföra i en större organisation eller i distansmiljöer, men även att samlas i en gemensam Slack-kanal eller ha schemalagda gemensamma arbetspass där människor kan utföra fokuserat arbete samtidigt på distans kan hålla teamet mer sammanlänkat.
• Motverka överlämningar mellan avdelningar: Det mer styrda, vattenfallsinspirerade arbetssättet där varje avdelning arbetar i olika steg (UX, sedan design, sedan utveckling och därefter kvalitetssäkring) kan ofta leda till kommunikationsbrister och ökat slöseri i ett projekt. Överväg att låta teamet arbeta tillsammans med funktioner i stället för att lämna över arbetet längs en kedja. Även om ni arbetar i sprintar med en inledande designsprint bör du involvera utvecklarna i designsprinten – det är trots allt de som ska bygga detta!

Värde nr 2: Fungerande programvara framför omfattande dokumentation

Kom ihåg att manifestet inte säger att dokumentation ska tas bort – det värderar helt enkelt punkterna till vänster högre än dem till höger. Det betyder att dokumentation fortfarande finns kvar. Scrum har till exempel användarberättelser som informerar utvecklaren om hur arbetet med bygget ska komma igång.

Men vad kan du göra för att komma bort från tung, tidskrävande dokumentation och snabbt komma fram till något konkret?

Effektivisera dokumentationen du använder

Identifiera eventuella problemområden eller hinder i processen. Använder ni för mycket dokumentation? Tar det en evighet att utforma det perfekta kravdokumentet, lägger ni massor av tid på en funktionell omfattning och får sedan slut på tid för att bygga produkten? Minska onödig dokumentation genom att:

• Fokusera på design- och utvecklingsuppgifter som bidrar till själva produkten, i stället för på ett skriftligt dokument som i slutändan inte kommer att användas
• Hålla workshoppar i ett tidigt skede för att definiera krav och nästa steg i stället för att skriva långa dokument. Dokumentera och dela resultaten med foton och korta anteckningar.

Kom snabbt igång med bygget

Att skriva mängder av kravdokumentation är ett sätt att kartlägga verksamhetens, kundens och slutanvändarens behov. Men i slutändan är det mycket mer användbart att se något som fungerar, beter sig och reagerar.

Överväg några av följande sätt att snabbt driva projektet framåt:

• Komprimera den inledande utforskningen eller definitionen till en kortare tidsperiod: Genom att begränsa hur mycket tid du lägger på att definiera och reda ut saker kan du snabbare komma fram till något som designerna och utvecklarna kan ta sig an. Du kan snabba upp processen med hjälp av dessa frågor för utforskningsmöten.
• Håll workshoppar: Workshoppar med teamet samlar intressenterna så att beslut kan fattas snabbare.
• Ändra din projektplan: Har ni först definierat arbetet, sedan designat och därefter utvecklat? Överväg att tidigarelägga utvecklingen och låta designers och utvecklare ta fram något tillsammans tidigare i processen.

Använd prototypmetoder i stället för platta designer

I stället för att se framsteg som ett definitionsdokument eller en platt design som är en kryssruta för kunden att godkänna, visar du dem något som blir en del av den färdiga produkten.

Använd snabb prototypframtagning för att få något att fungera och vara användbart – och, ännu viktigare, något som du kan testa med kunder. Att samla in feedback på en prototyp blir ett användbart sätt att följa framsteg, i stället för att förlita sig på en leverans som inte har fördelen av att vara en del av slutprodukten.

Du kan skapa prototyper med olika detaljnivåer:

• Låg detaljnivå: Klickbara designer. Detta är när du snabbt behöver ta fram en skiss för att testa med kunder; det handlar mer om att testa utseende, känsla och enkla interaktioner.
• Medelhög detaljnivå: Användning av viss rörelse eller animering.
• Hög detaljnivå: Fungerande HTML. Används för komplexa interaktioner, men kan tas vidare till kod som är redo att lanseras.

Prototyper med hög detaljnivå ligger närmare ”fungerande programvara” än de andra typerna, men kan vara mer tidskrävande att ta fram. Prototyper med låg eller medelhög detaljnivå ger utvecklare bättre vägledning än platta designer.

Leverera något till slutanvändaren eller kunden snabbt

Det här är viktigt.

Med frekventa lanseringar av fungerande programvara kan kunden använda de nya funktioner som har lanserats. I stället för att vänta till slutet av projektet på en storslagen lansering är det avgörande att leverera värde till kunden tidigare för att skapa en bättre produkt.

Hur kan du uppnå tätare leveranser i din organisation?

• Granska din projektplan eller projektöversikt: Har du planerat att slutföra utvecklingen och sedan lansera i slutet av projektet? Arbeta i stället med teamet för att dela upp arbetet i funktioner eller arbetsdelar som kan lanseras separat under projektets gång.
• Fokusera på blockerare: En central del av din roll är att hjälpa teamet att undanröja hinder när problem uppstår. Hur kan du hjälpa dem att leverera mer effektivt? Finns det arbetssätt som fördröjer lanseringar? Att genomföra en sprintretrospektiv med teamet kan synliggöra möjligheter till processförbättringar.
• Automatisera: Om din organisation lägger mycket arbete på lanseringar bör du automatisera processer där det är möjligt. Automatiserade tester och distributioner kan till exempel spara manuellt arbete och minska arbetsinsatsen som krävs för en lansering. Prata med ditt agila utvecklingsteam om vilka processer de använder och vilka möjligheter till automatisering som finns.

Värde nr 3: Kundsamarbete framför avtalsförhandling

I stället för att i början av ett projekt utforma ett extremt detaljerat avtal som anger exakta leveranser, omfattning, budget och tidsplaner bör du hålla ditt agila avtal så övergripande som möjligt. Fatta beslut under projektets gång genom att samarbeta nära med dina kunder och intressenter.

Agilt arbete handlar inte om att lägga massor av tid på att definiera krav i förväg. Det handlar om att påbörja ett projekt och lära sig under resans gång, baserat på kundtester och feedback från fungerande programvara.

Använd ett kundcentrerat arbetssätt

Jag älskar det här citatet från en artikel av Neil Killick:

”En agil tänkare frågar ständigt: ’Vilket är det enklaste/snabbaste sättet att skapa värde för kunden?’ Ställer du den frågan varje dag? Om inte, är det ditt första steg.”

Det är inte bara designers och utvecklare som bör tänka så här – det bör även projektledare göra. Vi ansvarar också för att leverera bästa möjliga produkt eller tjänst till en kund. Din kund, användaren av din produkt eller tjänst, bör stå i centrum för allt du gör.

Sätt slutkunden i centrum för planen

Planera utifrån värdefulla kundresultat i stället för leveranser och uppskattningar. Vad vill vi att kunden ska göra, och varför? Hur kommer vi att mäta att detta fungerar?

Styr om samtalet så att fokus ligger på vilket värde vi har skapat för kunden, snarare än på hur många arbetsuppgifter vi har levererat.

Involvera kunden nära

I stället för att hålla ett veckovis statusmöte och sedan leverera till kunden och intressenterna i slutet av en viss period bör du arbeta för att involvera kunden i projektet på daglig basis.

Om du arbetar mer enligt en Scrum-process bör du göra kunden till produktägare. Produktägaren ansvarar för att sammanföra verksamhetens, de tekniska och kundens krav. Det är avgörande att få kundens stöd och samarbeta tidigt och ofta för att undvika förseningar. I slutändan leder det till en bättre produkt eller tjänst för slutkunden.

Involvera en frånvarande kund

Om din kund inte har tid att bidra till projektet eller på annat sätt inte är engagerad bör du se till att någon i teamet representerar kunden. Det är avgörande att någon tar hänsyn till kundens och verksamhetens behov.

Även om kunden inte är engagerad från dag till dag bör du se till att kommunicera regelbundet med kunden och åtminstone involvera kunden i diskussioner om agil planering och prioritering. Samarbeta med kunden för att visa fördelarna med att vara involverad.

Implementera en produktfärdplan

Överväg att använda en produktfärdplan för att kartlägga produktens utveckling. En produktfärdplan kommunicerar planen för produkten och visualiserar funktioner som planeras att levereras. En färdplan är inte fastställd i början av ett projekt, utan utvecklas över tid för att återspegla förändringar i prioriteringarna.

Se till att du pratar med dina slutanvändare eller kunder

Jag kan inte nog betona detta – du måste försöka testa din produkt med slutanvändare och kunder tidigt och ofta. 

Tester ger så många fördelar:

• Du kan säkerställa att din produkt uppfyller kundernas behov, det vill säga: är produkten värdefull för kunden och därmed för verksamheten? Det hjälper dig att bedöma produkt–marknadsanpassningen.
• Du kan integrera kundfeedback i din design- och utvecklingsprocess, vilket resulterar i en bättre slutprodukt.
• Du kan få insikter som kan ligga till grund för framtida arbete.

• Det ofta nämnda problemet med kundtester är budgeten – det kan vara dyrt. Här är några sätt att testa oavsett projektets budget:

Gerillatestning: Jag gillar den här metoden eftersom den är billig och enkel. Erbjud dig att köpa en riktig eller virtuell kopp kaffe till personer om de vill svara på några frågor om din design eller prototyp. Det är svårare att bestämma vem som svarar på dina frågor, men snabb feedback kan vara användbar när du testar utseende, känsla eller enkla interaktioner.

Enkäter: För att samla in kvantitativa data från ett bredare urval av personer kan du skapa en enkät för att utvärdera designen eller gå djupare in på kundernas beteende.

Webbplatser som usertesting.com: Du kan ladda upp din design till en av dessa webbplatser och rekrytera personer genom dem, med hjälp av kriterier vid behov. De klickar sig sedan igenom din design, spelar in sina tankar och svarar på frågor.

Testning ansikte mot ansikte: Ja, det här kan vara ett dyrare alternativ, eftersom du sannolikt behöver rekrytera personer och betala ersättning. Det kan dock vara ovärderligt om du testar komplexa interaktioner eller funktioner med hög risk.

Värde nr 4: Anpassa sig till förändringar i stället för att följa en plan

Agila projekt och vattenfallsprojekt kunde inte skilja sig mer åt i det här avseendet. I traditionella programvaruutvecklingsprojekt fastställer du krav, kostnad och tidsplan i förväg, medan agila arbetssätt tillåter och välkomnar förändringar.

Förändring är bra! Det är inte något ont! Hur många projektplaner har fungerat exakt som du utformade dem i början? Inte många, skulle jag gissa (jag har arbetat med projekt där projektplanen har genomgått dussintals iterationer).

Planer är en bästa gissning vid en viss tidpunkt, som du kan göra mer exakt allteftersom du går vidare – men de brukar inte tillåta förändringar. Vad händer om kundens behov förändras? Om verksamheten ändrar riktning? Om kunden ändrar sina prioriteringar? Om den angivna funktionen inte är så enkel att bygga som du trodde?

Agila arbetssätt omfamnar osäkerhet genom att använda en anpassningsbar planeringsmetod, till exempel planeringspoker. Scrums värderingar föreskriver till exempel att teamet planerar arbetet sprint för sprint. Innan en tidsbegränsad arbetsperiod börjar hämtar agila team objekt från backloggen och prioriterar dem för utveckling.

Även om det ofta finns en strävan efter att fastställa kostnad, tidsplan och omfattning i början av ett projekt leder det ofta till en mycket bättre slutprodukt att vara mer realistisk kring den osäkerhet du möter. I slutändan är det detta som du, kunden och dina intressenter bör vilja ha. 

Här är några sätt att börja ta hänsyn till förändringar i dina projekt och uppmuntra större flexibilitet:

Skapa en ”lätt” plan för att tillfredsställa intressenterna

”Men vi behöver en plan!”, ropar dina intressenter. I stället för att skrämma dem genom att säga ”Överraskning, det finns ingen plan!” kan du skapa en enkel lanseringsplan som ger dem förtroende för det något mindre formella arbetssättet.

Om du arbetar med agil projektledning med Scrum-processer har du en lista med prioriterade och uppskattade användarberättelser i din backlog. Samarbeta med produktägaren för att gruppera dessa i ungefärliga lanseringar och koppla dem till produktens färdplan.

Försök att inte planera allt, eftersom det skulle motverka fördelarna med att använda Scrum-metoden. Visa intressenterna vad du planerar i de första två eller tre lanseringarna och förklara sedan att omplanering är en central del av ett agilt arbetssätt. Du kommer att kommunicera uppdateringar och ytterligare lanseringar allt eftersom. Förhoppningsvis ger detta dem det förtroende de behöver!

Vänj teamet vid ett sprintbaserat arbetssätt

Mike Cohn föreslår i sin artikel ”Att införa en agil process i en organisation” att man hjälper team att gradvis vänja sig vid Scrum genom att definiera ett antal sprinttyper, till exempel:

• Prototypframtagning
• Kravinsamling
• Analys och design
• Implementering
• Stabilisering

Så här beskriver han hur detta kan hjälpa:

”Vi arbetar sedan med teamen för att definiera de artefakter som blir resultatet av varje sprinttyp. Sprinttyper skapar precis tillräckligt mycket formell struktur för att teamen tydligare ska kunna se hur de ska ta sig igenom projektet. När teamen blir mer vana vid det informella i den agila processen släpper de gradvis konceptet med sprinttyper.”

Detta är ytterligare ett sätt att utforma din lanseringsplan. Om du tilldelar varje sprint en ”typ” kan dina intressenter se hur planen tar form, samtidigt som du slipper behöva garantera specifika funktioner. Ditt team får också en bättre uppfattning om vad de kommer att arbeta med.

Frångå fasta tidsfrister

Att ge teamet en tidsfrist eller kommunicera ett fast datum till kunden är strategier som antingen är dömda att misslyckas eller åtminstone leder till stress på vägen. Att bygga förtroende mellan dig och ditt team samt mellan dig och kunden eller intressenten är avgörande för att visa att du kommer att leverera, och leverera värde, till slutkunden.

Kom ihåg att du försöker minska behovet av flera avstämningar och godkännanden. Att införa tidsfrister i projektet kommer inte att hjälpa dig att nå detta mål. Det är inte heller bra att flåsa teamet i nacken och jaga dem efter arbetet som de ”lovade” att leverera.

Som jag nämnde ovan kan färdplaner och lanseringsplaner vara ett bra sätt att gå från ett arbetssätt med fasta datum. Genom att ge intressenterna en bild av vad som kommer att lanseras inom den närmaste framtiden kan du försäkra dem om att det finns en plan.

Använd en tids- och materialbaserad omfattning

Om du har en omfattning med fast pris och fasta leverabler är det svårt att leverera på ett mer agilt sätt. Du kan definitivt använda några av de tekniker jag redan har diskuterat, till exempel att skapa ett mer samarbetsinriktat team. Men du kommer att vara begränsad när det gäller hur mycket du kan reagera på och anpassa dig till förändringar, låta teamet avgöra vad de ska arbeta med eller använda ett mer kundcentrerat arbetssätt.

Samarbeta med ditt interna team och kunden för att införa en tids- och materialbaserad omfattning – det vill säga att kunden betalar för ett team i stället för fasta leverabler. Till en början kan kunder bli nervösa om de inte vet exakt vad de får.

För att minska denna oro kan du inkludera en backlog med aktiviteter eller uppgifter som kan övervägas inför lanseringen som en del av omfattningen. Ange i avtalet att teamet ska omplanera och prioritera backloggen med kundens medverkan allt eftersom projektet fortskrider (även om ni kanske inte hanterar varje punkt).

För att hantera föränderliga prioriteringar och leverabler kan team förlita sig på agil projektstyrningsprogramvara för att kontinuerligt omprioritera sin backlog och samarbetsverktyg för programvaruutveckling för att samordna tvärfunktionellt samarbete.

På så sätt förbinder du dig inte till en fast omfattning, samtidigt som kunden får färre frågor kring hur slutprodukten kommer att se ut.

Fortsätt följa upp framstegen

Att följa upp och visualisera framsteg försvinner inte bara för att det saknas en formell projektplan. Genom att hålla framstegen synliga för teamet och intressenterna ser du inte bara till att ni inte tappar potentiella hinder och flaskhalsar ur sikte, utan håller också intressenterna uppdaterade. 

Att använda en WIP-tavla i Kanban-stil eller agila instrumentpaneler fungerar bra för agila projekt. När du har visualiserat processen kan du börja kartlägga stödjande uppgifter och aktiviteter. Detta hjälper dig att upptäcka flaskhalsar som du kan undanröja för att möjliggöra snabbare leveranser till kunden.

Kritik av det agila manifestet

Precis som alla andra projektledningsmetoder är agilt inte perfekt. Kritiker påpekar att författarna till det agila manifestet var en homogen grupp som kanske inte tog hänsyn till alternativa arbetssätt, till exempel fördelarna med att arbeta på distans eller hur agilt kan tillämpas utanför mjukvaruutveckling.

Om det drivs för långt kan agilt innebära beslut genom kommitté, vilket saktar ner arbetstempot. Brist på dokumentation kan i slutändan skada projektleveransen, särskilt i en miljö där man arbetar på distans och asynkron kommunikation är avgörande.

Om du bestämmer dig för att använda agila arbetssätt i dina projekt bör du läsa igenom de agila värderingarna och principerna. De är en användbar vägledning för att hålla agila arbetssätts värsta tendenser i schack.

Läs mer om debatten om huruvida agilt är en metod eller ett tankesätt här.

Smidighet, inte agilt

En sista tanke är: kom ihåg retrospektivet! Som manifestet säger:

Med regelbundna intervall reflekterar teamet över hur det kan bli mer effektivt och justerar sedan sitt beteende därefter.

Oavsett vilken typ av process du använder är retrospektivet ett effektivt sätt att granska hur ni arbetar och optimera för framgång. Se till att regelbundet inkludera projektretrospektiv i den process du använder – och att du har en mekanism för att införliva det ni har lärt er! PS: Det är viktigt att få de tystlåtna teammedlemmarna att prata även under retrospektiven – så här gör du.

Vad händer härnäst?

Om du vill lära dig mer om hur du implementerar agila arbetssätt och lär dig av branschens bästa projektledare kan du läsa om våra DPM-medlemsalternativ.