Projektledning – Agila metoder

Inledning

I det här inlägget kommer jag att redogöra för vad agil projektledning och systemutveckling är samt hur denna skiljer sig från traditionella metoder. För att belysa skillnaderna har jag valt ut fem olika begrepp/områden som jag kommer att studera mer i detalj, och dessa är: projekttriangeln, projektledarrollen, projektgruppen, mötesrutiner och dokumentation. Avslutningsvis reflekterar jag över den agila metodens för- och nackdelar.

Den agila modellen

Den agila projektmodellen har sitt ursprung ur det missnöje som i slutet av 1900-talet fanns i IT-branschen mot de då existerande modellerna, man ansåg att dessa var alltför stela och byråkratiska. För mycket tid lades på dokumentation och för lite på att utveckla de IT-system som skulle levereras. Nya mer flexibla projektmodeller växte fram och i början av 2001 samlades företrädare för dessa för att skapa gemensamma riktlinjer för hur denna typ av projekt kunde drivas. Man skrev ner dessa riktlinjer i det som kallas för det ”Det Agila Manifestet”, http://agilemanifesto.org/iso/sv/. I detta manifest skriver man bland annat följande:

Individer och interaktioner framför processer och verktyg

Fungerande programvara framför omfattande dokumentation

Kundsamarbete framför kontraktsförhandling

Anpassning till förändring framför att följa en plan

Det vill säga, medan det finns värde i punkterna till höger,

värdesätter vi punkterna till vänster mer.

Man förtydligar sedan detta i 12 stycken principer, dessa finns att läsa på http://agilemanifesto.org/iso/sv/principles.html. Två av dessa principer lyder: ”Vår högsta prioritet är att tillfredsställa kunden genom tidig och kontinuerlig leverans av värdefull programvara” samt ”Leverera fungerande programvara ofta, med ett par veckors till ett par månaders mellanrum, ju oftare desto bättre.” Och detta är ett av den agila projektmetodens särdrag, man har många små leveranser istället för en eller ett fåtal större, som ju är det normala i traditionella projektmetoder. En av de största fördelarna med detta är att man lättare kan anpassa sig till de förändringskrav som ofta uppstår under projekt. I och med att beställaren får många små delleveranser så kan man snabbt upptäcka saker som behöver förändras och på ett smidigt sätt planera in detta i kommande delleveranser. Faktum är att de agila principerna till och med välkomnar förändringar under projektets gång detta då beställaren får ett bättre och mer konkurrenskraftigt system. (Gustavsson, 2007, sid 20 – 24 samt http://agilemanifesto.org/iso/sv/)

Andra särdrag hos den agila metoden är att projektledaren fungerar mer som en stödjande lagkapten än som en styrande chef samt att man inte gärna förändrar projektgruppen under projektets gång. Mer om detta och andra karaktäristika för den agila metoden beskriver jag nedan.

Projekttriangeln – tid, kostnad och resultat

Projekttriangel är ett sätt beskriva de tre parametrar som ett projekt styrs av. Tid, kostnad och resultat kan sägas vara projektets begränsningsparametrar då det är tillgången på dessa tre resurser som sätter projektets ramar. Detta gäller för såväl traditionella projekt som för agila. Skillnaden är dock att man i traditionella projekt kan förändra alla dessa tre parametrar under projektets gång medan man enligt den agila metoden endast kan förändra leveransparametern. Det vill säga om man i ett agilt projekt inser att man inte kommer kunna hinna leverera planerat resultat i tid så senarelägger man inte leveransen eller tillför mer personalresurser utan man skär istället ner på vad som ska levereras.

Logiken bakom detta är att det i praktiken oftast är mycket svårt att tillföra personalresurser i ett projekt med kort varsel. Om man skulle få tillgång till fler personer i projektet så skulle detta i många fall innebära att det uppstod personalbrist på andra platser i verksamheten. Dessutom är det svårt att snabbt få in nya medlemmar i projektgruppen. Att öka projektgruppens storlek blir ineffektivt. Två av grundprinciperna inom den agila metoden är ju just att behålla projektgruppen liten och intakt samt att ha kort tid mellan olika delleveranser, skulle man då skjuta upp leveransdatum eller utöka projektgruppens storlek så faller mycket av konceptet. (Gustavsson, 2007, sid 28 - 32)

Detta innebär också att man i agila projekt använder sig av time-boxing, det vill säga man jobbar med en fast deadline och utför så mycket av aktiviteterna som är möjligt med de resurser man har. Det man inte hinner med tar man med i kommande leveranser. (Gustavsson, 2007, sid 40 - 41)

Projektledarrollen

Den största skillnaden för en projektledare i ett agilt projekt är att denne fungerar som lagkapten och inte som chef. Projektledarens främsta uppgift är alltså inte att styra gruppen utan att stötta och hjälpa gruppen och röja undan eventuella hinder så att denna ska kunna utföra sina uppgifter. Besluten fattas inte av projektledaren över projektmedlemmarnas huvuden utan det är projektgruppen tillsammans med projektledaren som fattar besluten. Jämfört med den traditionella projektorganisationen är den agila alltså mindre hierarkisk.

Men det finns givetvis situationen där projektledaren även i agila projekt måste fatta beslut, främst då projektgruppen trots medlingsförsök från projektledarens sida inte lyckas enas kring ett beslut. I dessa fall ligger avgörandet hos projektledaren. Man bör dock sträva efter att minimera antalet sådana tillfällen.

Det är projektledarens ansvar att projektet leds enligt den agila metoden, dvs. han måste vara väl förtrogen med konceptet samt ha förmågan att lära upp de projektmedlemmar som inte är insatt i metoden. Det är viktigt att projektledaren förklarar sin egen roll för projektmedlemmarna och övriga intressenter. (Gustavsson, 2007, sid 67 - 70)

Gustavsson tar bland annat upp följande punkter som exempel på konkreta aktiviteter som ligger inom den agila projektledarens ansvarsområde:

• Se till att eventuellt oklara krav förtydligas.
• Säkra projektets bemanning så att denna har rätt kompetens samt inte förändras under projektets gång.
• Gå på möten samt ansvara för tillhörande praktikaliteter.
• Kommunicera utanför projektgruppen.
• Arrangera kick-off och avslutningsmöte.
• Hantera kunder och projektbeställare.
  (Gustavsson, 2007, sid 71)

Projektgruppen

En stor skillnad mellan det agila arbetssättet och det mer traditionella är att man ger varje enskild projektmedlem ett större ansvar och befogenheter. Projektledaren skall mer ses som en lagkapten än som en chef. Dessutom finns ett kollektivt ansvar inom gruppen på ett helt annat sätt än i traditionella metoder, det vill säga man går in och hjälper varandra oavsett om arbetsuppgiften egentligen ligger utanför personens ursprungliga ansvarsområde. Detta innebär i sin tur att man premierar tvärkompetens, det vill säga man försöker undvika att det finns vissa uppgifter som endast kan lösas av en speciell projektmedlem. Man undviker också att ta in externa experter. Arbetar man strikt agilt så finns det inga specifika roller utan hela projektgruppen arbetar tillsammans för att uppnå projektmålen och varje enskild projektmedlem anpassar sina arbetsuppgifter till vad som för stunden efterfrågas i projektet. Projektgruppen skall vara liten, optimalt är en storlek på fen till nio personer, och gruppens sammansättning skall inte förändras under projektets gång. I mer traditionella projektmetoder så är rollerna mer fasta och man är mer öppen att ta in externa experter samt förändra projektgruppens sammansättning under projektets gång. (Gustavsson, 2007, sid 75 - 77)

Det finns dock en roll som avviker lite från ovanstående beskrivning och de är testrollen. Den rollen ska även i den agila metoden vara klart utpekad, detta då är viktigt att inte programmerarna testar och granskar sin egen kod. Testaren ska dock tillskillnad från traditionella projektmetoder finnas med under hela projektet, detta då i den agila metoden ju finns många delleveranser som ska testas. (Gustavsson, 2007, sid 81 - 82)

I och med den agila metoden så förändras alltså arbetssättet. ”Systemutvecklaren har blivit social” lyder rubriken på Guzmáns artikel om den agila projektmetoden. Och även om rubriken är något tillspetsad, det fanns ju givetvis sociala systemutvecklare även innan den agila metoden föddes, så ligger det något i detta då systemutvecklaren med det agila arbetssättet har kontakt med personer inom fler kompetensområden. I de mer traditionella vattenfallsmetoderna så var det relativt vattentäta skott mellan de olika kompetenserna, dvs. affärsutvecklarna gjorde först en affärsmässig bedömning, därefter tog IT-arkitekter och systemerare vid, dessa lämnade i sin tur vidare till programmeraren och slutligen testade testaren systemet. Det agila arbetssättet bygger ju på att man kommunicerar över kompetensgränserna, programmerare och systemerare kan till exempel ha direktkontakt med beställare och användare vilket snabbar upp processen samt ger dem en större förståelse för vad det är projektet ska leverera. Som projektmedlem är det också stimulerande att bredda sitt kontaktnät. (Guzmán, 2012)

Mötesrutiner

Det som är karaktäristiskt för den agila metoden är de dagliga avstämningsmötena. Enligt Gustavsson bör dessa vara mycket korta, ca 15 minuter, och genomföras stående. Stående därför att de inte ska bli långdragna diskussioner. På dessa korta dagliga möten ska alla projektdeltagare närvara och man ska gå igenom vad man har gjort sedan föregående möte, vad man kommer att göra fram till nästa möte samt vilka eventuella problem som finns för att man ska kunna leverera detta. Om det finns tid kan man även diskutera om det finns nya aktiviteter som bör planeras in samt om det finns något nytt beslut som gruppen har intresse av att veta. Var och en av projektdeltagarna ska alltså svara på dessa frågor, på så sätt får man en detaljerad bild av vad varje person gör på daglig basis. Detta leder till att tempot hålls uppe samt att eventuella problem upptäcks snabbt. Ovanstående kan jämföras med mer traditionella projektmetoder där längre möten hålls med längre tidsintervall, kanske varje eller varannan vecka, något som ökar risken för att eventuella problem inte upptäcks i tid samt kan leda till att tempot minskar. (Gustavsson, 2007, sid 155 - 157)

De möten som hålls är i första hand inte till för att projektledaren ska kontrollera och styra utan för att projektmedlemmarna ska få reda på vad de andra arbetar med och om det finns några problem. I de agila projekten har ju projektgruppen ett kollektivt ansvar där det ingår att hjälpa de medlemmar som har problem. (Gustavsson, 2007, sid 151)

En annan typ av möte är det som hålls i samband med varje etappleverans. Här ska leveransen presenteras för projektets intressenter. Och i sann agil anda ska mötet hållas kort, runt en timme, och förberedelserna bör inte ta mer än två timmar. Det är viktigt att man här presenterar det faktiska resultatet och inte en förskönad presentation. Intressenterna ska på mötet få se exakt så som systemet ser ut, i annat fall riskerar de att bli besvikna när de ser den färdiga produkten. Denna presentation är även viktig för projektmedlemmarna då den innebär en form av avslut och något jobba för. Mötet skall inte gå över till att bli ett planeringsmöte för nästa etapp utan de eventuella synpunkter som uppstår under presentationen ska memoreras och sedan diskuteras på ett kommande planeringsmöte. (Gustavsson, 2007, sid 173 - 175)

I samband med varje etappslut så hålls i agila projekt också ett erfarenhetsmöte, detta till skillnad från traditionella projekt där denna typ av möten oftast hålls i samband med projektavslutet. Fördelen med att hålla denna typ av möte efter varje etapp är att man i kommande etapper i det pågående projektet kan dra nytta av detta. Möten bör vara korta, max en timme, och utgå från de två frågeställningarna vad som gick bra och vad som kan förbättras. Varje projektmedlem tänker igenom dessa frågeställningar och sedan diskuterar man alla synpunkter gemensamt. De förbättringsförslag som kommit fram tar man sedan med sig till nästa etapps uppstartsmöte. (Gustavsson, 2007, sid 177 - 179)

Dokumentation

Här skiljer sig den agila metoden avsevärt från de traditionella metoderna genom att man försöker att minimera dokumentationen så långt det är möjligt. En av punkterna i det agila manifestet handlar om just detta, där står det att man ska sträva efter enkelhet och ”maximera mängden arbete som inte görs”. (http://agilemanifesto.org) Faktum är att den agila metoden uppstod till stor del som en reaktion på att den mängd tid och energi som gick åt till dokumentation i de traditionella metoderna. Dokumentationen blev också ofta snabbt inaktuell då kraven vanligtvis förändrades under projektets gång, mycket tid spenderades alltså att uppdatera gammal dokumentation. De fanns dem som tyckte att en allt för liten del i utvecklingsprojekten gick åt till själva utvecklandet, något man ville förändra i och med den agila metoden. (Gustavsson, 2007, sid 20)

Det är dock givetvis inte så att agila projekt genomförs helt utan dokumentation, en viss dokumentation behövs men det man vill undvika är att dokumentera bara för dokumenterandets skull. Dokumentationen ska vara efterfrågad. Och den dokumentation man ska fokusera på är den som är av nytta utanför projektet, till exempel förvaltningsdokumentation. Man ska minimera projektintern dokumentation och inom projektet istället använda sig av muntlig kommunikation. (Gustavsson, 2007, sid 43 - 47)

Reflektioner

Jag själv arbetat ett antal år i projekt som drivits med den traditionella vattenfallsmodellen och då tyckt att denna ibland varit alltför stel och omständlig så jag kan se tjusningen med den agila modellen. Här har vi en modell som fokuserar på att få saker och ting gjorda istället för att lägga tid på sådant som långa möten och tidskrävande dokumentationskrav. Dessutom fokuserar den agila modellen på korta projekt med snabba leveranser, något som jag som arbetat i den snabbt föränderliga webbranschen kan se nyttan med. I en föränderlig miljö är den agila metoden bättre då den inte utgår från en detaljerad kravspecifikation och därför lättare kan anpassa sig till ändrade krav som uppstår under projektets gång, något som är mycket vanligt när det gäller till exempel webbprojekt.

Även Gustavsson tar upp ovanstående fördelar med den agila metoden men nämner också att metoden är bra då projekten är så pass komplexa att det är svårt att i förväg föreställa sig hur slutresultatet kommer att bli samt vid vidareutveckling i förvaltningsorganisationen. (Gustavsson, 2007, sid 16) Kan bara instämma i detta. Vid riktigt komplexa projekt kan det antagligen vara en fördel att bryta ner det till flera mindre delleveranser enligt den agila metoden. Efter varje delleverans så är det nog lättare att få en klarare bild av hur slutresultatet kommer bli och man kan då också lättare planera för nästa delleverans. Dessutom tror jag att det är psykologiskt riktigt att dela upp ett långt och komplext projekt i flera väl avgränsade delleveranser, på så sätt får man något mer greppbart att fokusera på.

Men jag ser också att det finns tillfällen då den agila metoden inte är lämplig, exempelvis då man i ett projekt är beroende av fysiska ting som är svåra att förändra. Inom IT-branschen kan detta till exempel röra sig som hårdvara. Att förändra hårdvaran i efterhand kan bli mycket dyrbart och det är därför oklokt att inte ha en mycket detaljerad kravspecifikation redan från början. Samma sak gäller givetvis även utanför IT-branschen, inom byggbranschen kan man knappast starta projekt utan att från början ha en detaljerad kravspecifikation. Dels för att kunna göra hållfastighetsberäkningar och liknande men även för att det är alltför kostsamt att införa förändringar i efterhand. Här kan man alltså inte planera en delleverans i taget utan måste planera alla leverans i detalj redan från början.

Gustavsson tar även upp detta med fasta kontrakt, fasta deadlines med spikade leveranser och offentliga upphandlingar och påpekar att vid dessa tillfällen är den agila metoden inte lika effektiv. Vid alla dessa tillfällen saknas förutsättningar för den flexibilitet och rörlighet som den agila metoden bygger på. Den agila metoden bygger ju på att man sätter upp ett datum för leverans och visar det sig att man inte kan hålla detta så är det innehållet i leveransen man förändrar och inte deadlinen eller resursutnyttjandet. Har man en fast deadline och spikat leveransinnehåll så är det enda man kan förändra resursutnyttjandet, något som inte är förenligt med den agila metoden. Vid offentliga upphandlingar är situationen liknande eftersom den färdiga lösningen då alltid är detaljerat beskriven redan från början. (Gustavsson, 2007, sid 16-17)

Referenser

Gustavsson, Tomas. 2007. Agile – konsten att slutföra projekt. Karlstad: TUK Förlag AB.

Guzmán, Rebecka. 2012. Systemutvecklaren har blivit social. IDG. Elektronisk. http://www.idg.se/2.1085/1.469067. Läst 2012-10-08.

Schwaber, Ken & Sutherland, Jeff mfl. 2001. Manifest för Agil systemutveckling. Elektronisk. http://agilemanifesto.org/iso/sv/. Läst 2012-10-09.

Tonnquist, Bo. 2007. Projektledning. Stockholm: Bonnier Utbildning.