När ett företag går mot att arbeta agilt innebär det starten på en förändring som slår bredare än vad man kan tro. Det är lätt att tänka att agil utveckling är något som berör ett eller flera team med utvecklare som nu arbetar på ett nytt sätt. Men det är bara början. 

När utvecklingen sker enligt någon av de agila metoderna, t ex Scrum, innebär det till att börja med att det inte finns en färdig kravspecifikation innan utvecklingen startar. För att arbetet ska bli framgångsrikt behövs ofta en tydligt vision kring vad som ska uppnås och vilka effekter som ska uppnås. Men organisationen behöver vara bekväm med (eller i alla fall inse) att mycket lärande kommer att ske längs vägen och att det därför bara är bortkastad tid att ta fram detaljerade specifikationer för de funktioner som du tror behövs längre fram. 

Agil utveckling innebär att skimären av tydligt scope tas bort och osäkerheten tydliggörs genom att planen inte är fastslagen.

Det gör att projektets styrgrupp behöver ställa om från att fokusera på risker och hur stor del av kravspecifikationen som är klar till att fokusera på hur väl projektet verkar uppfylla effektmålen. Dessa ska gärna kunna mätas via tester snarare än att gå på projektledarens uppskattning. 

Om de system som utvecklas är kundnära och affärskritiska behöver också organisationen tänka om kring hur man ser på mjukvaruutveckling. Jag får ofta frågan från styrgrupper och ledningar när projektet är slut. På ett sätt är det en väldigt relevant fråga då projektet har fått en budget och ska uppfylla effektmål. Å andra sidan är det en tydlig indikation på att organisationen inte har tagit till sig agil utveckling. De frågor du ställer avslöjar oftast hur du tänker. 

I ett traditionellt projekt utvecklas en tjänst inom ramen för ett projekt. Mot slutet av projektet genomförs en överlämning till förvaltning. Dokumentation blir en viktig leverans från projektet då alla, utom i bästa fall några nyckelpersoner, försvinner när projektet stänger. Produkten vidmakthålls sedan i förvaltning med mindre uppgraderingar för att bibehålla funktionalitet. Vid ett sådan upplägg är frågan när projektet är klart väldigt relevant då det inbär att tjänsten är färdigt, ”kunderna” får nytta av den och utgifterna minskar då förvaltningen inte nämnvärt vidareutvecklar tjänsten. 

När du tar fram nya kundnära tjänster via agil utveckling är syftet med projektet oftast något helt annat. Enligt scrum behövs inte projektledare längre. Utvecklingsteamet tar ett större ansvar och en scrummmaster (som också kan vara utvecklare) hjälper teamet med arbetsprocessen, men är inte någon som bestämmer över de andra. Behövs då ett projekt och en projektledare över huvudtaget?

I en agilt mogen organisation är det inte självklart, men i en organisation som inte är van att arbeta agilt är svaret entydigt ja! Det behövs en brygga mellan en traditionell sekventiell organisation och en agil (som arbetar i mindre iterativa steg) organisation. Jag tycker om att se dessa ”bryggor" som ett införandeprojekt snarare än ett utvecklingsprojekt. Projektet är främst ett verksamhetsprojekt som ser till att det nya arbetssättet landar bra i organisationen. 

Det går att liknas vid ett projekt att inför en ny produktionslina i en verkstad. Projektet är till för att se till att arbetet i produktionslinan och logistiken runt flyter effektivt. När arbetet flyter på kan projektet avvecklas, men produktionslinan fortsätter naturligtvis att producera. Projektet behövs bara tills alla bitar har kommit på plats, de nya processerna fungerar och de som är involverade vet vad de ska göra. Då kan projektet stängas och målet med projektet är uppnått. Det betyder inte att produktionslinan uppnått sitt produktionsmål för perioden. 

Många gånger innebär stängningen av ett projekt mindre än man kan tro. Den enda skillnaden kan vara att projektledaren inte behövs längre och att ansvaret flyttas till linjen. Alla andra roller är oförändrade av projektets stängning. Det gör överlämningen ganska odramatisk. Dokumentation behövs, men inte för att utbilda nya personer utan för att ha ordning på sina processer. 

Om en styrgrupp inser projektets roll blir också frågorna till projektledaren bättre. Det är tre vinklar på projektledarens och styrgruppens ansvar.

• Skapa en tjänst som uppfyller riktiga kundbehov
• Se till att de processer som sätts upp är effektiva och kan fortsätta att skapa kundvärde långt efter projektet
• Se till att organisationen kan hantera den nya tjänstens vidare utveckling

Om vi ser att funktionstillväxten är fortsatt stor så kommer kostnaden för utvecklingen att vara jämförbar oavsett om utvecklingen drivs inom ett projekt eller som en del av linjens arbete. Om tjänsten ska lanseras publikt är det oftast bra att behålla projektet över lansering för att hantera de extraordinära aktiviteterna som behövs. 

Från ett ledningsperspektiv är ett för stort fokus på själva projektet och det som levereras inom projektet lätt vilseledande. Frågan när är projektet klart? är mindre viktig än frågan när är de dessa kritiska leveranser klara? När kan vi lansera tjänsten?

Min erfarenhet är att det är bättre att fokusera på en tjänsts produktlivscykel istället för organisationsformen. En produkt eller tjänst bör förmodligen hanteras på olika sätt under en tillväxtfas än under en avvecklingsfas.

Under tillväxtfasen sker ofta både utveckling av nya funktioner och marknadsföring för att få nya användare. Det är inspirerande för medarbetare att arbeta med en tjänst i denna fas då ledningens intresse ligger på hur det går och det händer mycket runt tjänsten.

När tjänsten börjar mogna och organisationen fokus flyttar vidare till nyare tjänster är det fortfarande väldigt viktigt att allt fungerar kring tjänsten, men entreprenörskänslan börjar sakta avta och nu är fokus på att den ska fungera. Teamet som jobbar med tjänsten är nu mycket mindre, både på utvecklingssidan och kring marknadsföring. 

Så vad svarar du då när någon frågar: När är projekt klart?
"Det beror på vad du tänker på. Projektet är klart så fort organisationen är redo att ta över processerna runt det agila teamet. Om du undrar när vi ska lansera vår första version så sker det om en månad, sen kommer vi att släppa förbättringar kontinuerligt under de kommande åren enligt vår roadmap."

Se projektet som ett verksamhetsprojekt med ansvar för införandet av ett nytt arbetssätt i verksamheten, inte som ett IT-projekt som ska utveckla en ny digital tjänst. Om organisationen är överens om det från början kommer utvecklingsteamet och övriga organisationen att dansa bättre i takt under tjänsten livscykel.