Agile-radikal revolution eller enkel evolution?

Under förra decenniet förnyade ett antal Agila metoder systemutvecklingen. Ofta beskrivs dessa som ett helt nytt sätt att tänka och arbeta i projekt. I själva verket är det en samling principer som visat sig framgångsrika.

Ladda ner artikeln som PDF

Måste man överge sin nuvarande projekt- modell och anamma en Agil metod fullt ut, eller kan man tillämpa de agila principerna i sin nuvarande modell?

I denna artikel beskrivs de Agila principerna i relation till traditionella projektmodeller.

Vad menas med Agila metoder?

Ordet agile betyder ”lättrörlig” eller ”vig”. Agile Software Development (eller kort ”Agile”) är ett synsätt gemensamt för en grupp av lättrörliga metoder. Grundtanken med Agila metoder är att i en föränderlig värld krävs utvecklingsmetoder som hanterar förändring som en del av verkligheten, inte sådana som blundar för förändringar eller som försöker reglera bort dem. Fler regler kommer inte ge oss fler lyckade projekt. Vi behöver flexibilitet – inte rigididet.

Agila metoder kan alltså sägas vara ett paraply-begrepp. Det är inte en systemutvecklings-metodik i sig utan snarare en uppsättning värderingar, attityder och principer. Inom de agila metoderna finns ett antal olika utvecklings-metodiker som anses vara lättrörliga. En metod anses vara agil då metodikens upphovsman bekänner sig till de agila värderingarna.

Historik och bakgrund

Under många år har IT-utveckling baserat sig på olika varianter av vattenfallsmodellen, dvs. på utgångspunkten att man i ett projekt börjar med att fånga alla krav som ligger till grund för systemet. Därefter designar man lösningen för att när detta är klart utveckla och implementera. När implementeringen är klar arbetar man med tester och validering/ verifiering. Slutligen sjösätts lösningen och man övergår i underhåll.

Det finns många dokumenterade exempel på att agila metoder kan fungera bättre än vattenfallsmetoden. De svårigheter som uppstår när man försöker finna och dokumentera alla krav i förväg och sedan göra specifikationer som underlag för utvecklingen kan hanteras bättre med agila metoder.

Extra tydligt blir detta i miljöer där kraven hela tiden förändrar sig.

Vidare finns många exempel på projekt som levererar enligt dessa specifikationer, kanske till och med i tid och inom givna resursramar, men där det visar sig att det inte alls var det resultat som verksamheten behöver.

Ett betydelsefullt motiv till att förändra ett vattenfallsliknande arbetssätt är vikten av att tidigt få fram delresultat som kan börja användas och ge nytta i verksamheten långt tidigare än när hela projektet är färdigt.

Under 1990-talet skapades oberoende av varandra ett antal alternativa arbetssätt som en reaktion mot vattenfallsliknande metoder som man upplevde som tröga och alltför omfattande. Metoder som SCRUM och DSDM utvecklades oberoende av varandra och blev allt mer populära. Gemensamt för de olika metoderna som växte fram, var att de grundades på erfarenheter kring både vad som fungerar bra och vad som hade lett till att många IT projekt havererar. I mångt och mycket kan de olika agila metoderna tyckas vara sunt förnuft paketerat på lite olika sätt.

Något gott kom ut av dessa olika initiativ. Istället för att, som brukligt är, alla började slåss för ”sin” metod, samlades sjutton ledande profiler för olika lättrörliga metoder i januari 2001 på en skidort i Utah för att diskutera vad man var överens om och vad som skiljde. Man enades om vissa principer och värderingar. Detta synsätt kom att kallas Agile. Under detta möte skapades nätverket Agile Alliance där man gemensamt vidareutvecklar och delar med sig av de värderingar, principer och arbetssätt som ligger till grund för alla lättrörliga metoder.

De gemensamma principerna och värderingarna dokumenterades i ett gemensamt manifest – Agile Manifesto.

Agile Manifesto – det agila manifestet

Följande punkter utgör grundbultarna i det agila manifestet

• Individer och samspel framför metoder, processer och verktyg.
• Användbart resultat framför omfattande dokumentation.
• Kundsamarbete framför kontraktsförhandlingar.
• Anpassning till förändring framför att följa en statisk plan.

Ovanstående punkter skall inte tolkas som att t.ex. metoder, processer och verktyg inte har något värde och skall ignoreras. Allt i punkterna ovan är viktigt men de ord som markerats med fetstil är viktigast.

Vi på Wenell delar dessa värderingar och har under många år propagerat för vikten av att:

• Metoder, processer och verktyg behövs, men är inte tillräckligt. Motiverade individer och väl fungerande kommunikation, helst ansikte-mot-ansikte, är nödvändigt för att bli framgångsrik.
• Prioritera, se till att få fram användbara resultat först och dokumentera på en lagom nivå. Undvik omfattande ”mellan- dokumentation” som inte tillför värde.
• Förutsätt att planerna kommer att förändras. Bygg in mekanismer som underlättar förändring. Tillämpa närzonsplanering och tydliggör med milstolpar när olika resultat skall vara klara.
• Samverka kontinuerligt med kund och mottagare för att stämma av att projektresultatet blir det som kunden förväntar sig. Fokusera på att skapa nytta i kundens verksamhet genom att tydliggöra effektmålen och leda projektet med dem i åtanke.

De agila principerna

De agila principerna bör vara vägledande i alla projekt där man har för avsikt att arbeta lättrörligt. I det agila manifestet och den ursprungliga formuleringen av de agila principerna har utgångspunkten varit mjukvaruprojekt och man talar i termer som kommer från systemutveckling. Principerna är dock generella och är användbara i många olika typer av projekt, dock inte alla. Nedan har vi gjort en tolkning av de agila principerna som fungerar även i ”icke systemutvecklingsprojekt”.

• Viktigast är att göra kunden nöjd genom tidiga och regelbundna leveranser av värdeskapande projektresultat
• Anpassning till förändrade krav och förutsättningar är naturligt, även i ett sent skede; utnyttja förändring till kundens/organisationens fördel
• Leverera användbart projektresultat ofta, helst med bara några veckors mellanrum
• Verksamhetskunniga och utvecklare arbetar tätt tillsammans
• Självgående och ansvarstagande individer är den främsta framgångsfaktorn
• Kommunikation ansikte mot ansikte är det bästa sättet att förmedla information, både inom teamet och till omvärlden
• Användbara resultat är det främsta måttet på framsteg
• Enkelhet – konsten att göra rätt saker, varken mer eller mindre, är grundläggande
• Gruppen utvärderar och anpassar regelbundet sitt arbetssätt för att förbättra sin effektivitet.

I fortsättningen kommer vi att resonera kring hur man kan inspireras av de agila principerna även om man använder en traditionell projektmodell som grund.

Agil tillämpning av en generell projektmodell

En modell är en förenkling av en komplex verklighet. En projektmodell, menar vi, måste anpassas och tillämpas på ett sätt som på bästa sätt stödjer en viss verksamhet såväl som det enskilda projektet. Låt oss resonera om hur man kan tillämpa och kombinera det som är bra i traditionella projektmodeller med de sunda och lättförståliga principerna som utgör grunden för agil projektledning.

Bilden illustrerar projektflödet i Wenells projektmodell och visar på ett överskådligt sätt projektets förlopp från idé till nyttjande. Liknande beskrivningar finns i de flesta etablerade projektmodeller.

Projektflödet består av ett antal faser och beslutspunkter, så kallade grindar. Faserna innehåller olika arbetsmoment som skall utföras och grindarna är framåtriktade beslutspunkter där projektets affärsmässighet/ nytta prövas. Denna uppdelning av förloppet ger erfarenhetsmässigt en mer genomtänkt struktur åt projektarbetet och högre kvalitet genom att arbetet fokuseras på de viktigaste aktiviteterna. Som bilden visar startar ofta efterföljande fas innan den tidigare är helt avslutad.

Tanken med denna uppdelning i faser är att i de tidiga faserna, förstudie och start, på ett systematiskt sätt bygga upp kunskapen om projektet, belysa projektet ur ett affärsmässigt perspektiv och skapa bra underlag för beslut om det är vettigt att gå vidare med projektet eller ej. Denna grundtanke är sund även när man tillämpar agil projektledning.

En viktig insikt som präglar agila metoder är dock, att det i vissa typer av projekt, är väldigt svårt att tidigt specificera i detalj vad som skall åstadkommas och levereras. Osäkerheten är ofta stor och det är nästan omöjligt att beskriva en tydlig målbild och tydliga avgränsningar innan man har kommit en bit in i projektet. Mycket erfarenhet visar också att projekt som ignorerar denna insikt har en tendens att dra ut på tiden och förbruka rejält mycket mer resurser än vad man initialt hade planerat.

Flera av de agila principerna adresserar detta problem och ett sätt att tackla denna osäkerhet är att dela upp genomförandet i flera kortare delar där man försöker att leverera konkreta, användbara resultat tidigt och ofta. Det förekommer en mängd olika benämningar på dessa delar i olika agila modeller. Några exempel är Iteration, Inkrement, Timebox och Sprint. Vi har valt att kalla en sådan tidsavgränsad del i projektgenomförandet där vi i slutet levererar ett användbart resultat för inkrement. En vanlig rekommendation för varaktigheten av ett inkrement är ca 2-6 veckor.

Inkrementet inleds av en kort inkrementstart där vi definierar innehållet i termer av prioriterad funktionalitet/resultat att leverera, gör tidsuppskattningar osv. Under inkrementet skall teamet få arbeta ostört och fokuserat med hög intensitet. I slutet av inkrementet förbereds leveransen av ett väl genomtestat och kvalitetssäkrat resultat som visas upp och demonstreras. I samband med denna demonstration/leverans blir det väldigt tydligt vad projektet åstadkommit och olika typer av statusrapportering blir överflödig. I samband med slutet på inkrementet genomför teamet också en tillbakablick där man diskuterar vad som fungerat bra i teamets arbete och vad som kan förbättras. Denna diskussion leder till löpande förbättring av teamets arbetssätt i projektet.

Att dela upp en lång genomförandefas i flera kortare delar, inkrement, ger flera fördelar:

• Gruppen får tydliga resultat längs vägen att sikta på, vilket ger tydlighet och fokus
• Gruppen levererar kontinuerligt delar av slutresultatet som kommer verksamheten till nytta långt tidigare än vid en stor leverans i slutet
• Kund/användare tar löpande emot leveranser, nyttjar resultaten och kan tidigt få ut nyttoeffekter av dessa
• Kund/användare ger feedback till projektgruppen som löpande får input till justeringar och förbättringar till kommande leveranser.
• Framsteg och status i projektet blir mycket tydligt då de levererade resultaten visas upp och dessa demonstrationer kan i stora delar ersätta normal statusrapportering
• Möjlighet att, i samband med varje leverans, reflektera över teamets arbetssätt och ta fram förslag till förbättringar

Intressenter

Eftersom en viktig agil princip är att leverera nytta, är det klokt att tidigt sträva efter att tydliggöra hur denna nytta ser ut. Intressentanalys behövs även i agila projekt eftersom projektet behöver få kunskap över vilka individer, grupper och organisationer som har viktiga insikter och åsikter kring vilken denna nytta är. I de tidiga faserna bör man skapa en gemensam förståelse för detta i utvecklingsteamet. Arbetet med att tydliggöra intressenterna och deras förväntningar leds av Produktägare/nyttoansvarig (se organisation nedan) och denna roll har under projektet huvudansvaret för att prioritera och tydliggöra vilka av alla förväntningar som teamet skall prioritera och utveckla resultat för.

Under genomförandet har denna roll ansvar för att definiera vilka resultat som skall utvecklas i varje inkrement. Insikter i att förväntningar och behov förändras och förtydligas under tiden i ett projekt bör prägla prioriteringarna. När projektet väl stängs, har man då fått resultat som ger maximal nytta i förhållande till förbrukad tid och resurser.

Målformulering – Projektets Arena

I de tidiga faserna är det viktigt att försöka tydliggöra målbilden för projektet. Projektets Arena består av en sammanfattning av både de önskade effekterna av projektet och det resultat som skall levereras när projektet är färdigt. Avgränsningar är också en viktig del i arenan och tydliggör vilka resultat som inte skall levereras. Tid- och kostnadsramar kompletterar bilden så att vi också får en känsla för när projektet skall vara färdigt och vilka resurser det kommer att förbruka.

Arbetar vi agilt måste vi dock inse att en sådan definition grundar sig på den kunskap vi har om projektet under de tidiga faserna. Denna kunskap kommer att utvecklas och förfinas under tiden projektet fortlöper. Vi måste vara beredda att använda den nya kunskapen och revidera målen så att de speglar en aktuell bild av projektet och omvärldens krav och förväntningar.

Ett sätt att hantera denna balansgång är att definiera målen för hela projektet på en lite grövre nivå än brukligt för att sedan per inkrement i genomförandet arbeta med stenhård prioritering så att vi får fram de viktiga resultat som skall levereras och ge maximal nytta.

Det förekommer olika tekniker för sådan prioritering i de olika agila metoderna och en bra och användbar teknik kallas MoSCoW och kommer från DSDM/Atern. MoSCoW kan användas både för att prioritera vikten av olika leverabler för hela projektet och framför allt i prioriteringen i olika inkrement.

Bokstäverna M, S och C i ordet MoSCoW står för olika nivåer av prioritering.

• Must Have’s är de viktigaste kraven som måste vara med i leveransen, annars falerar hela tanken på den leveransen.
• Should Have’s är också viktiga krav som vi anstränger oss hårt att få med i leveransen. Om det ställs på sin spets och vi tvingas prioritera kan dock Should Haves prioriteras bort.
• Could Have’s är de minst prioriterade kraven och kan ses som ”bra att ha”. Vi har definierat att vi vill få med dessa i leveransen men om vi tvingas prioritera så är det Could Have’s som först prioriteras bort.

DSDM/Atern rekommenderar att inte ha mer än 60% av utvecklingsinsatsen i ett inkrement definierat som Must Have’s.

W betyder Won’t Haves och kan användas som avgränsningar som tydliggör vad som inte skall med i en given leverans. De två förekomsterna av bokstaven o kan ses som makeringar för att inkrementet är tids och resursstyrt (On time och On budget).

Sammanfattningsvis bör man sträva efter en tydlig målformulering för hela projektet men inse att vi har begränsad kunskap om vad som komma skall. Aktiv prioritering genom projektet där vi drar nytta av våra ökande kunskaper, och förändrade omständigheter är av största betydelse när vi arbetar agilt. Detta innebär att vi får bra koll på när vi levererar och vilka resurser som förbrukas, men exakt vad leveransen innehåller är flytande. Grundtanken i detta förhållningssätt ar att vi får ut maximal nytta i leveransen i förhållande till förbrukad tid och resurser.

Visualisering

Visualisering är ett sätt att skapa förståelse för vad man vill åstadkomma. Det finns många olika sätt att visualisera på, allt från olika typer av trädstrukturer och enkla skisser till pappmodeller och prototyper. Det gäller att välja visualiseringssätt utifrån projektets behov. Att visualisera är naturligtvis viktigt i alla projekt, inte bara agila.

”User stories” och ”storyboarding” är ett par exempel på tekniker som används för att beskriva vad man skall kunna använda ett projekts resultat till.

En viktig princip inom agila metoder är att visualisera problem och status. Ett vanligt sätt att göra detta är att använda en aktivitetstavla (eller ”task board”). Om vi tänker oss att vi brutit ner ett inkrements leverans i beskrivningar i form av användarberättelser så är tanken att dessa får en rad var på aktivitetstavlan. På raden finns de aktiviteter som hör till respektive användarberättelse skrivna på t.ex. Post-it-lappar. Vidare finns kolumner för ”Att göra”, ”Påbörjat”, ”Klart för verifiering” och ”Klart”. Allt eftersom arbetet fortskrider flyttar man lapparna så att en aktuell bild av status skapas.

Varianter på samma tema förekommer men principen är att göra det väldigt tydligt vad vi har att göra, vad det arbetas med just nu, vad som är klart etc.

Man kan också komplettera med en graf vars Y-axel symboliserar t.ex. totalt antal mantimmar som teamet åtagit sig vid inkrementets start. X-axeln visar inkrementets kalenderdagar. Varje dag så plottar man in bedömd mängd kvarvarande utvecklingstimmar. Detta visar ganska snabbt en trend hur läget är och om det finns risk att några användarberättelser riskerar att inte hinnas med.

Organisering

På Wenell använder vi en samspelskarta som en slags checklista för att tydliggöra olika roller som är viktiga i projektets kärnorganisation och i dess omvärld.

Tanken är att få en bra och tydlig bild för alla så att vi har en visualisering av vilka individer som axlar olika roller i just detta projekt. Visualisering, tydlighet och transparens är viktigt i alla projekt.

En extremt viktig roll för att möjliggöra agilt arbete är att det finns en individ som representerar nyttoperspektivet och har djup kunskap om hur resultaten skall användas och vilken nytta som förväntas uppstå. Denna roll kallas i SCRUM för Produktägare (Product Owner). I DSDM/Atern finns fler roller med en tänkt eskalerinsordning men den primära rollen för prioritering kallas Business ambassador.

Att definiera ansvar och befogenheter för denna roll och tydliggöra vem som axlar den är mycket viktigt. En av de viktigaste orsakerna när ett agilt arbetssätt inte fungerar är att denna roll inte är väldefinierad och personen som axlar den inte är närvarande och tillgänglig.

En viktig princip i agil organisering är att skapa möjlighet till kraftsamling, fokus och arbetsro. För att möjliggöra detta är det bra att sträva efter team med begränsad mängd deltagare (ca 5-9 personer) och med hög tillgänglighet i projektet. Vi strävar efter att bemanna projektet med heltids-personer som inte tvingas splittra sin tid mellan olika projekt och annan verksamhet.

Erfarenhetsmässigt fungerar detta bäst och man får ut mest nytta per arbetstimma om man kan arbeta på detta sätt. En viktig uppgift för projektledaren/ teamledaren är att se till att medlemmarna i teamet får möjlighet till denna kraftsamling samt att röja undan olika typer av hinder för projektet.

I flera agila metoder markeras också vikten av att medlemmarna i teamet är aktiva i planering och tidsättning och självmant tar på sig arbetsuppgifter och ansvar för olika resultat snarare än att projektledaren styr vem som skall göra vad och när. Medarbetarna i teamet betraktas som ansvarskännande individer och agerar som sådana med rätt förutsättningar och stöttning. En för alla, alla för en, skall prägla ett väl fungerande agilt team. Man tar ett kollektivt ansvar för att lägga upp arbetet så att man har en fungerande leverans i slutet av varje inkrement. Detta förhållningssätt rimmar också mycket väl med olika teorier och forskning kring gruppdynamik och motivation.

Planering

Tidsuppskattning och planering är otroligt viktigt för de flesta utvecklingsprojekt. Utan en bra planering utsätter vi projektet för ett antal problem. Ändå är det så att planering är svårt och planerna är ofta fel. Projektgrupper tenderar att reagera på detta faktum genom att välja en av två extremer. Antingen planerar man inte alls eller så väljer man att sätta så mycket tid och kraft i planeringen att man blir övertygad om att planerna är korrekta.

Planering handlar mycket om att reducera risk. Den största risken för många projekt är att utveckla fel produkt/resultat. Ofta ser man definitionen av ett lyckat projekt som förmågan att leverera i tid, inom givna resursramar och med alla funktioner/resultat inkluderade. Detta är dock en farlig definition då den inte tar hänsyn till det faktum att en funktion som verkade bra när projektet startades kanske inte är värd insatsen det tar att utveckla den när vi väl får koll på detaljerna. I agil planering behöver planeringen löpande omprövas så att den ökade kunskapen tillvaratas. En kund eller användare blir antagligen heller inte så nöjd om fantastiska idéer till nya smarta funktioner avfärdas till förmån för mediokra funktioner bara för att dessa var med i den ursprungliga planen.

Som tidigare nämnts strävar vi, i agila projekt, efter tidiga täta leveranser med prioriterat innehåll. Detta skapar förtroende mellan projektmedlemmarna och de kunder/användare som skall nyttja resultatet.

En ganska stor skillnad i planeringen av ett agilt projekt jämfört med ett mer traditionellt är att man i det agila projektet initialt planerar på en grövre nivå. Vi inser att kunskapsnivån om projektet är låg i början för att öka genom hela projektet, samt att det kommer en massa förändringar och förtydliganden. Så att försöka planera i detalj från början till slut är helt enkelt inte effektivt. Det är också för många projekt ett sätt att lura sig själv. Bara för att planen är detaljerad betyder inte det att den är korrekt. Vi strävar alltså efter att löpande planera under hela projektet. Det viktigaste är planerandet, inte planen. Insikterna och kunskapen vi bygger upp under planerandet varar långt efter det att planen har skrotats och ersatts av en annan.

Den grövre planeringen kan mycket väl göras med traditionella tekniker såsom arbetsstrukturer, logiknät och gantt. Viktigt är dock att jobba lite grövre och inte försöka t.ex. tidsuppskatta på detaljnivå när vi inte har tillräcklig kunskap. Planering med milstolpar som representerar uppnådda resultat längs vägen passar jättebra och speglar tanken med tidiga och täta leveranser.

Detaljerna bör hanteras och planeras i varje inkrements uppstart. Då samlas teamet och produktägaren för att gå igenom den prioriterade kravlistan och definiera innehållet i kommande inkrement. Produktägaren prioriterar innehållet i leveransen och teamet ansvarar för tidsuppskattningar och hur stor del av den prioriterade kravlistan de åtar sig att utveckla under inkrementets löptid.

Ett omtyckt sätt att tidsuppskatta som används i flera agila metoder är planeringspoker (Planning poker). Enkelt uttryckt går det till så att varje resultat som skall vara med i inkrementets leverans beskrivs på ett tydligt och lättförståligt sätt t.ex. i en användarberättelse (Hur skall jag som användare kunna nyttja resultatet?). Teamet är samlat och alla medlemmar har en uppsättning kort med olika tidsestimat på (t.ex. 0, 1, 2, 3, 5, 8, 13, 20, 40 och 100).

Enheten kan vara mantimmar eller ”storypoints” el. dyl. Varje medlem i teamet gör en egen skattning vad man tror att ett visst resultat tar att utveckla. När alla har valt ett kort ur sin lek, visar alla sina gissningar och man jämför. Om det är stor differens mellan den lägsta och den högsta skattningen får de som gjort dessa redogöra för hur de tänkt.

Dessa klargöranden för hur man tänkt diskuteras och sedan görs en ny skattning av alla. Detta görs tills man enas om en rimlig skattning som alla kan acceptera. Erfarenhet visar att detta fungerar bra eftersom bedömning görs av flera individer med lite olika expertkunskap. Vidare är detta ett exempel på en teknik som fokuserar på lärandet och den gemensamma förståelsen. Planerandet är viktigare än planen! Dessutom är det kul!

Sammanfattningsvis bör agil planering kännetecknas av:

• Att vi fokuserar mer på planerandet än själva planen
• Att vi välkomnar förändring, om vi inser att det är smart och skapar ökad kundnytta
• Att vi strävar efter planer som är lätta att ändra
• Att projektmedlemmarna är delaktiga i planeringen och själva tidsuppskattar och tar på sig arbetsuppgifter

Hantering av osäkerhet

Förmågan att leva med osäkerhet och hantera den finns inbyggd i det agila synsättet. ”Embrace Change” är en devis som ofta används. Tanken är att vi hela tiden lär oss mer och mer i projektet och kan ta klokare beslut ju mer kunskap vi har. Att löpande kunna ta emot, och till och med välkomna förändringar är en viktig inställning. Allt för att användarna skall få så värdefullt resultat som möjligt. Detta möjliggörs genom produktägarens prioriteringar och känsla för vad som är mest användbart och relevant.

Kommer nya krav och förväntningar till projektet är det möjligt att ta med dessa i ett inkrement som ligger framför oss, men självklart får annat innehåll som bedöms mindre viktigt tas ut ur projektet eller inkrementet (se MoSCow).

Att i projektets tidiga faser ändå se över och analysera risker och möjligheter är av stort värde och skapar kunskap om kritiska framgångsfaktorer i projektet. En enkel teknik för att göra dessa analyser med tillhörande åtgärdsplaner är Minirisk som är en av de vanligaste teknikerna för detta.

Ytterligare en mekanism som förespråkas i de flesta agila modeller är att ha korta dagliga statusmöten, eller ståuppmöten. Tekniken är enkel och väldigt givande. Man samlar hela teamet stående i U-form så att alla ser och har ögonkontakt med alla. Var och en i teamet besvarar tre enkla frågor.

1. Vad har jag gjort sedan föregående möte?
2. Vad skall jag göra till nästa möte?
3. Har jag något som hindrar mig/är problematiskt?

Mötet är hårt tidsstyrt och bör inte ta mer än 15 minuter. Om saker dyker upp på mötet som måste diskuteras/hanteras får de individer som är berörda ta detta efter mötet. Under mötet kan projektledaren uppdatera status i projektet t.ex. på en aktivitetstavla eller liknande så att det tydliggörs vad vi har gjort färdigt, vad vi arbetar med just nu och vad som ännu inte är påbörjat. Vidare kan man grafiskt åskådliggöra hur upparbetade timmar ligger i relation till skapat resultat. Allt blir synligt och lätt att förstå.

Genom att tillämpa en sådan mötesordning blir teamet tidigt varse om något strular eller är på väg att spåra ur.

Projektgenomförande

En tydlig skillnad mellan traditionella projekt och agila projekt är indelningen i många kortare etapper där vi utvecklar en liten del av det totala projektets leverans i varje etapp.

När denna etapp är klar levereras detta resultat, demonstreras för alla intresserade och kan börja nyttjas av användarna.

Användarna ger återkoppling till teamet som suger i sig denna feedback och drar nytta av den i resterande etapper. På detta sätt blir det väldigt tydligt om missförstånd uppstått etc. Risken att vi i slutändan levererar en massa oanvändbara eller felaktiga delar minskar radikalt.

I kommande etapper bygger man vidare på det tidigare resultatet och levererar löpande och ganska tätt mer och mer delar av det totala resultatet. En viktig fördel utöver återkopplingen att vi är på rätt väg är att användarna mycket tidigare kan börja använda och få nytta av resultatet. Man får nyttoeffekter i verksamheten innan hela projektet är färdigt.

Vidare finns möjligheten att när som helst bryta projektet och ändå ha stora delar färdiga och användbara.

Som tidigare nämnts är en viktig del i teamets arbete att ständigt förbättra sig. Genom att i samband med varje leverans sätta sig tillsammans och prata igenom hur teamet arbetar och ”vässa sågen” kommer insikter fram som gör att man ständigt anpassar gruppens arbete och förbättrar effektiviteten.

Ett sätt att enkelt genomföra ett sådant reflekterande möte är att alla i teamet funderar igenom hur de upplevt det senaste inkrementet. Man kan t.ex. skriva det man tycker varit bra på gröna post-it-lappar och sådant som man upplever som mindre bra på röda. Sedan sätter medlemmarna upp sina lappar på en tidslinje över det senaste inkrementet och berättar kort hur man upplevt det. Projektledare/teamledare faciliterar detta arbete och summerar teamets iakttagelser i en lista över vad som bör förbättras i nästa inkrement.

Projektavslut

När projektet har levererat sitt sista inkrement är det klokt att avsluta projektet på ett strukturerat sätt. Viktiga aktiviteter i avslutningen är att sammanfatta projektet och sprida dess erfarenheter till andra berörda. Dock är mycket av arbetet med erfarenhets- sammanfattning och ”lessons learned” redan gjort i agila projekt, då man faktiskt gör ett mini-avslut i varje inkrement.

Vidare vill vi avsluta en del formalia med att stänga tillfälliga konton, tidsrapporteringskoder etc. på ett snyggt sätt. Att upplösa organisationen, ge varandra feedback och fira det lyckade resultatet är andra viktiga aktiviteter.

En sak som blir lite annorlunda är mätning av uppfyllelse av projektmålen. Dessa var grovt formulerade från början och kan ha ändrat sig ett antal gånger under det agila projektet.

Överlämning av resultatet till olika mottagande roller har ju redan gjorts ett antal gånger under projektet i samband med delleveranserna efter varje inkrement. Således borde det formella avslutet i ett väl genomfört agilt projekt bli enklare än i ett mer traditionellt projekts storleverans i slutet.

Till sist

De agila principerna är baserade på ”Best practice”, det som baserat på mängder av erfarenhet visat sig fungera bra i framför allt systemutvecklingsprojekt. Principerna är dock väldigt sunda och bör med fördel kunna användas i många andra olika projekttyper.

Kanske inte för alla typer av projekt och inte alla av principerna, men så är det ju alltid.

Svaret på, om agila metoder är en radikal revolution eller en enkel evolution, varierar säkert beroende på hur man är van att hantera projekt. Fundera på principerna och tänkt över vad som borde kunna skapa värde i just dina projekt. Jag tror fast och fullt att mycket av detta sunda förnuft har stor tillämpbarhet i många olika projekt.

Lycka till!

Några agila länkar

• www.agilemanifesto.org – om agila manifestet
• www.agilesweden.com – om agile på svenska
• www.dsdm.org – om DSDM/Atern
• www.controlchaos.com – om SCRUM
• www.xprogramming.org – om XP
• www.poppendieck.com – om Lean software development

Av Mats Nyman, Wenell Management AB 2010