Ni har börjat att jobba agilt: teamen är formerade, backloggar skapade och utvecklingen är igång.
Plötsligt, men egentligen inte oväntat, dyker kravet på rapporter till högre chefer upp och en beställare är missnöjd med att man faktiskt inte fått allt man trodde att man skulle få. Förut var det självklart att det var projektledarens uppgift att hantera dessa frågor, men nu är det ju självstyrande team med produktägare och scrum masters som kör. Vems är ansvaret då?
Projekt och projektledare för framtiden
Under övergången från en vattenfallsorienterad projektmetodik till en agil metodik skapas ibland vanföreställningen att man nu kan kasta bort alla gamla lärdomar om planer, budgetar, omfattning, kontrakt och styrning. Samtidigt har man inte förändrat kraven som organisationen ställer på styrning och uppföljning. Slutsatsen är att många organisationer är i en övergång och inte utvärderat sina krav på ett projekt med den nya metodiken. Ofta faller ansvaret tungt på projektledaren att klara övergången och hantera en ny världsbild.
Som bekant har projektledare många uppgifter, både hårda och mjuka. Under workshops som jag haft med projektledare, när vi diskuterat projektledarens roll, kommer det fram arbetsuppgifter som omfattar allt från att hämta kaffe och köpa bullar till att skriva kontraktstillägg. Som agil projektledare vill jag tipsa om ett par saker man ska vara medveten om i den nya världen.
Översättare av verkligheten
Ett projekt har dels ett inre liv och dels ett antal gränsytor till kringliggande intressenter. Styrgruppen vill ha en månadsrapport, budgeten följs upp i företagets ekonomisystem och linjechefer vill veta hur deras personer agerar. Ofta är inte den omkringliggande organisationen eller processen lika agil som projektet är. Det är nu en ny sida hos projektledning behövs när det gäller agila projekt. Här handlar det om att översätta från hur information i ett vattenfallsprojekt sammanställs och presenteras till hur man gör i ett agilt projekt.
En fundamental sak med agil utveckling är att den kretsar runt att skapa värde för beställaren och minimera ovidkommande arbete. Som projektledare innebär det att störa utvecklingsteamen så lite som möjligt med ovidkommande krav och i stället använda det som produceras i teamet enligt den valda agila metoden, och översätta informationen därifrån till önskat format. Att lägga fler krav på utvecklingsteam för att generera mer information som syftar till fylla i gamla mallar är inte rätt väg att gå.
Som projektledare ska du inte tveka att ifrågasätta organisationens krav på uppföljning och mallar. Vilken information är verkligen nödvändig och används? Ta tillfället i akt att se över vad som behövs i din organisation när ni tar steget in i den agila världen. Jag vill också understryka vikten av att använda det som produceras av teamet i en normal agil uppföljning (burn down grafer, releaseplaner etc). De går att ofta enkelt översätta till just din organisations mallar. Att som projektledare förstå hur ett scrumteam fungerar är givetvis oerhört viktigt.
Omfattningen är ett rörligt mål
Omfattningen av vad som ska ingå i projektet är alltid ett föremål för diskussion, åsikter och prioriteringar. Vattenfallsprojekt med sina rigorösa initiala kravarbeten hamnar långt ifrån de agila projekten som är orienterade runt en lättare kravbild med mer möjligheter till samarbete, förändringar och utvidgningar. Här kan givetvis kontrakt eller överenskommelser som stipulerar öppenhet och lättrörlighet, men samtidigt binder exempelvis budget och tid, leda till problem. Okunskap, ovilja och oförmåga att anpassa omfattningen av projektet kan få vilken relation som helst att gå i kras och chefer att gå i tak. Projektledaren ska se till att överenskommelser hanteras på ett bra sätt och att omfattningen av projektet efterföljs. Utbildning och förväntanshantering blir centralt för att alla verkligen ska förstå innebörden i att vara tvungen att ta bort saker ur den ursprungliga omfattningen när tid eller budget inte kan förändras.
Mitt tips till projektledaren är att satsa på tre saker; utbilda dina intressenter, dokumentera nuvarande omfattning och plan samt förklara konsekvensen av aktuell status. Det uppstår förvånansvärt ofta situationer där beställare inte vill eller kan förstå konsekvensen av att omfattningen ändras under projektets gång och här behöver de hjälp.
Ett annat ledarskap
Inom den agila världen tillämpar man tvärfunktionella team och man tror på teamens förmåga att kunna lösa och leverera värde. Man använder sig av självorganiserande team för att få en bra gruppdynamik och effektivitet. Tron på att teamen, med rätt förutsättningar, kan klara uppgiften är stark. Projektledarens roll som styrande har ändrats till att bli en stödjande coach, jämna vägen för utvecklingen och lämna detaljerna till teamen. Den här omställningen är nog smärtsam för vissa projektledare men med ödmjukhet och tillit kommer man långt!
Min rekommendation är att ta ett steg tillbaks, var delaktig i retrospektiven och förklara konsekvenser av ett visst beteende snarare än att styra projektgruppen. Visa med handling att du tror på teamet och ge dem ansvar och möjlighet att lyckas. Den kunskap som en projektledare har är inte samma som ett utvecklingsteam har och man behöver lära av varandra.
En ständig förändring
En övergång till att jobba agilt i en organisation är givetvis en förändring som kommer att påverka alla inblandade och likaså resultatet av det som produceras i organisationen. I det som jag beskrivit i den här artikeln står det klart att projektledarens roll kommer att förändras och ny kunskap behövs. Vissa organisationer har redan tagit bort rollen projektledare och många av uppgifterna fördelas på andra roller som till exempel Produktägare och Scrum Master. Men innan alla har kommit så långt, och i vissa fall passar nog inte den övergången heller, kommer rollen projektledare finnas kvar. Dock kommer rollen att utvecklas på olika plan för att passa in i de nya mönster som finns i just din organisation.