Är planering inte Agilt?

I många sammanhang där SCRUM eller andra Agila metoder införts har det varit ett flertal personer som argumenterat mot planering. Jag minns att jag ofta svarade att Agila metoder kräver bättre ordning och reda och planering än vattenfallsprocessen. Enligt min åsikt gav vattenfallsplaneringen en falsk trygghet och det tror jag många håller med om. Med Agila metoder har vi en möjlighet att både få till en bättre planering och bättre möjligheter att anpassa oss till förändringar under projektets gång. När det gäller förändringar tycker jag att det viktigaste är att inställningen till en förändring har ändrats. Nu förväntar man sig förändringar och har en plan för hur dessa skall hanteras och projektet planeras utefter att förändringar kommer att ske. I vattenfallsprocessen upplevde jag i praktiken att projekten motarbetade förändringar till det yttersta för att kunna hålla de åtaganden som man tidigare gjort.

Samtidigt som vi vill planera för releaser, marknadsföringskampanjer och göra åtaganden till kunderna, vill vi inte planera mer än nödvändigt. Risken är att vi lägger mycket tid, som i vattenfallsprocessen, på att planera saker som aldrig implementeras eller lika illa, användaren använder inte funktioner vi levererat samtidigt som de saknar annan funktionalitet. I alla fall måste vi hitta ett sätt att prediktera vad som kommer att ingå i våra releaser. Hade det varit vattenfallsprocess hade vi pratat om att prediktera när vi releasar men här är fokus på vad som kommer att ingå.

Inom SCRUM använder vi Story Points eller motsvarande för att bedöma en viss utvecklingsinsats. Med hjälp av erfarenheten av hur många Story Points vi klarar av i en SPRINT kan vi bedöma vår hastighet. Genom att sätta Story Points på allt vi måste göra kan vi få en bild över vad som kan levereras vid en viss tidpunkt. Denna metod kräver att någon läser och förstår alla uppgifter till en viss detaljeringsnivå. Oavsett storlek på en organisation kan detta innebära en insatts som är bortkastad när kraven ändras. I SAFe  arbetar vi med flera abstraktionsnivåer. För att göra en långsiktig roadmap skall vi jobba på Epic eller Feature nivå i stället. Jag kallar dessa Epic Points och Feature Points och jag hanterar dem på samma sätt som Story Points. Fördelen med detta angreppssätt är att vi inte behöver bryta ner och göra detaljstudier av allt som skall göras utan en arkitekt som har ett övergripande ansvar och förståelse för systemet bedömmer de olika Epics eller features relativa storlek och med historisk data kan vi bedömma företagets velocity för Epics respektive features beroende på vilket vi arbetar med.

Oavsett om ni använder SAFe, less eller annat ramverk för ert arbete är det mycket information som skall hanteras. Ett verktyg som stödjer företagets arbete är ett måste. Jag har arbetat med flera verktyg med ärendehantering som grund, t ex JIRA, utan att få det stöd som jag vill ha i mitt arbete som projektledare eller annan chefsbefattning. Efter många års funderande och sökande efter verktyg har jag nu hittat ett intressant ACT (Agile Collaboration Tool) som jag verkligen tror på och som jag nu fördjupar mig i. Detta ACT  har en arkitektur som gör det Agilt. Det kan anpassa sig efter användarens behov av information i stället för att användaren skall anpassa sig till hur utvecklarna av verktyget tycker att det skall användas. Jag har alltid sagt att om man väljer ett verktyg, ClearCase var ett av de första jag valde i början av 90-talet, så skall man använda dem som tillverkaren har tänkt sig. Med detta ACT ser jag en möjlighet att låta ett företag jobba som de vill men ändå få stöd för sitt arbete oavsett vilken chefsposition de har.

Jag återkommer när jag har fördjupat mig ytterligare i ACT.