Vad kännetecknar agilt projektarbete? Vi reder ut begreppen kring ”agile”
Agila arbetssätt drar till sig mer och mer intresse, inte bara i projektvärlden utan i många sammanhang. Handlar det bara om ännu ett nytt modeord eller finns det värde som kan förbättra möjligheterna att lyckas med projekt? I den första av våra längre videos ger Mats Nyman sin syn på agilt projektarbete.
Vad betyder agilt på vanlig svenska?
Agilt betyder lättrörlig, vig. Tanken är att ha ett tillvägagångssätt när man styr ett projekt som öppnar för förändring, att ha en ödmjukhet och en insikt i att det inte alltid blir så som vi har tänkt oss. En ödmjukhet inför att vi initialt inte vet så mycket. Allt eftersom tiden går lär vi oss mer och mer, och vi kommer på saker längs vägen. Agile är ett sätt att hantera förändring smidigt.
Uttrycket kommer ifrån systemutveckling. Det finns otaliga exempel på projekt som spenderat mycket tid på att utveckla saker och ting som — visar det sig när vi väl levererar — har projektet dels dragit ut på tiden och kostat mycket arbete och pengar, och dels att det vi lagt tid, svett och tårar på i slutändan, ett eller två år senare, inte är det som användaren vill ha.
Hur hanterar man då det här projektet? Hur hanterar man osäkerhet och förändring?
Agile är egentligen en uppsättning principer, en best practice som då kanske har visat sig fungera bättre än ett mer vattenfallsorienterat synsätt.
Tanken är att dela upp längre projekt i flera kortare faser och att ha en aktiv användarmedverkan — de som vet vad som verkligen behövs i verksamheten måste vara tillgängliga i teamet när vi utvecklar. Synsättet är att vi som utvecklar projektet bör jobba tillsammans med de som skall använda det i slutändan.
Tanken är vidare att den person som är med och vet vad som verkligen behövs tidigt i varje fas skall prioritera och vara tydlig med vad som behöver ut nu. Tanken är då att leverera successivt och kontinuerligt, bygga på med mer och mer innehåll, sjösätta små delar av resultatet längs vägen och börja nyttja det, snarare än att göra en stor big bang-leverans. Risken vid en stor leverans är att vi upptäcker att vi har tolkat helt fel. Det är viktigt att vi teamet under projektets gång får feedback som vi kan ta med oss in i nästa fas.
Det handlar mycket om att samarbeta, inte bara med kunden utan även att det finns bra samarbete inom teamet. En viktig princip när vi jobbar agilt är att vi försöker organisera så att det är färre medarbetare med i teamet, och att de som är med kan lägga en stor del av sin tid i projektet, så att de kan få fokus och arbetsro utan att bli splittrade. Helst skall de arbeta heltid i projektet.
Samarbete face-to-face är det mest effektiva sättet att kommunicera så vi försöker lokalisera så att alla är smlade på ett ställe. Det är bättre att bara kunna vända sig till nån för frågor än att ödsla tid på att skriva.
Vi har mycket visualiseringsmaterial som kanbantavlor på väggarna, så att vi ser vad vad det är för något vi håller på med, vad som ligger i pipen, vad som är gjort. Vi söker en transparens kring processen. Det gör att medarbetare oftare sätter fart än i andra situationer och får saker att hända, eftersom man vet att man kontinuerligt kommer att följas upp och att det blir tydligt när man har kommit efter eller börjat slarva med åtaganden. Tätt samarbete är att sträva efter.
En annan viktig best practice är enkelhet, simplicity. Konsten att göra rätt saker, varken mer eller mindre. Man bör exempelvis undvika en massa icke-värdeskapande mellandokumentation. Det bästa sättet att visa att vi kommer framåt i projektet är att vi periodiskt levererar saker. Helst saker som går att tillämpa men annars konkreta delar av slutresultatet.
Det är eftersträvansvärt att leverera varje månad, och när vi då levererar efter en månad bör vi ha ha en demo där vi visar upp vad vi gjort för inbjudna berörda så att vi får feedback och kan kommunicera.
Sedan bör teamet reflektera över hur månaden har gått. Vad har gått bra denna tidsrundan, vad kan vi göra bättre till nästa? Vi vill ha små mini-lessons learned som vi kan ha nytta av under pågående projekt.
Det finns många agila principer, men ganska mycket är vanligt sunt förnuft förpackat på ett smakligt sätt.
Varför har agilt vuxit så i popularitet de senaste åren?
Det finns två perspektiv här. Dels är det så att organisationer som tillämpar agila principer får ganska stor verksamhetsnytta per insatt timme som spenderas i projektet. Vi tenderar att få tidiga leveranser och färr timmar som läggs på att utveckla funktionalitet som sen inte kommer att användas.
Det andra perspektivet är att teamet ofta upplever att det är roligt att arbeta agilt. Man lär rätt så mycket av varandra när man jobbar så tätt tillsammans. Och ofta är det så att teamet committar sig att göra jobb som en slags produktägare. Vi hjälps åt att tidsuppskatta, vi hjälps åt att göra grejer. Det blir ganska transparent och ett ganska aktivt sätt att jobba som är lustfyllt och kul. Vi känner oss duktiga och produktiva.
En fråga som kan ställas är om yngre genrationer tycker att det är roligare att jobba agilt än äldre generationer. Kommer det locka till sig folk i framtiden?
Det ligger nog nånting i det. Men man skall veta att agile inte passar alla människor. Om man tänker sig en djupt kunnig expertperson som varit lång tid på en arbetsplats och som får ut mycket prestige av att vara expert inom området, en sådan person kan ha svårt att dela med sig av sin kunskap, att byta mindset till ett agilt förhållningssätt. Agilt kan då vara mer av ett hot eller ett hinder. Men agilt kan nog attrahera många.
I vilka typer av projekt är agilt inte optimalt?
En viktig princip är ju anpassningsbarheten. Ledstjärnan är “Embrace change”, välkomna förändring till kundens fördel. Trots det finns det projekt där det är komplicerat och kostsamt att ändra vad som redan är gjort. Då kan det finnas argument för att inte arbeta agilt.
Det finns i vissa agila modeller något som kallas ett suitability filter, ett frågefilter man svarar på som ger indikation på om den agila modellen är den rätta eller inte.
Det finns trots allt ett antal situationer där agilt inte fungerar. Man kan då välja att kanske tillämpa endast delar av de agila principerna, att blanda traditionella metoder med agila metoder.
Man bör ha ett agilt tankesätt kring agilt.