Det verkar bli ett intressant år, 2013. Jag och Martin har jobbat mycket med att hitta rätt folk till rätt plats på jobbet, och det går framåt även om vi nog skulle må bra av någon mer senior webbutvecklare. Vi har börjat jobba i sprintar i ett av våra interna projekt, och vi lär oss mycket av det agila tänket varje dag som går.
För tydlighetens skull har vi alltså inte hoppat in i någon projektmodell såsom Scrum eller Kanban rakt av, utan fokuserar helt enkelt på att dela in arbetet i veckobaserade mini-sprintar där teamet tillsammans diskuterar igenom vad som ska göras, sätter poäng på de olika delarna och gemensamt ger ett löfte för vad som bör åstadkommas under den sagda tiden.
Att sätta poäng istället för att uppskatta tid verkade lite märkligt initialt. Vi satte 1 poäng = 3 timmar bara för att ha någon gemensam referenspunkt att utgå ifrån, men tanken är egentligen att komplexiteten på en uppgift ska ge poängen, inte hur lång tid den förväntas ta. Den stora fördelen som jag ser det med poängen är att kunna se att teamet tar sig framåt i förväntat tempo varje vecka. Att mäta hur många timmar som levererats eller hur beläggningsgraden ser ut är ju ganska irrelevant om det är produktivitet vi är ute efter. Vem som helst kan leverera 40 h/vecka, det är bara att låta tiden gå. Att rapportera in många genomförda poäng kräver däremot en insats och att det man gör dessutom har passerat någon som testar grejerna. Om teamet normalt sett brukar leverera 10 poäng på en sprint och vi plötsligt ser att det bara levereras 5 poäng under samma tid har vi ett problem. Hade vi bara sett till arbetade timmar hade kanske inte problemet upptäckts över huvud taget.
Vi började med ett mål att kunna leverera 15 poäng per vecka, och efter första avstämningen visade det sig att vi hann med ungefär 12 av de 15 poängen. Den största anledningen till att vi inte hann med allt var att ett par delar var för luddigt definierade och byggde på tycke och smak, vilket i sin tur gjorde att det blev svårt att passera testerna och klurigt för utvecklarna att veta exakt vad de skulle göra. Det försökte vi förbättra direkt till nästa sprint genom att dels ha mindre ärenden, och dels använda oss av skisser i de fall det fanns utrymme för tolkningar kring hur något skulle implementeras.
En annan svår del är at vi inte är vana vid att lägga så mycket tid på förarbetet. Redan efter 45 minuters sprintplanering börjar folk vrida på sig och undra när det är klart. Samtidigt känns det som planeringen tillsammans med testerna är de viktigaste delarna i sprinten. Slarvar vi där blir det inte bra till slut. Det är ungefär samma dilemma som jag har med att skriva offerter – ju mer tid jag lägger på dem, desto bättre blir de och desto lättare blir det att få kunden och teamet att förstå vad som ska göras. Men att lägga massor av tid på en offert som kanske aldrig blir genomförd är inte bra – och jag behövs ofta på andra platser i organisationen.
Det gick hur som helst ganska lätt att bli synkade i poänguppskattningarna. Alla är med och poänguppskattar, både projektledare och utvecklare. De som uppskattar lägst och de som uppskattar högst får förklara hur de tänker, och sedan enas gänget om en gemensam poäng. Det har hittills inte varit några större problem, och pricksäkerheten har varit förvånansvärt hög jämfört med hur det har sett ut i några av våra andra projekt.
Apropå andra projekt är det inte helt enkelt att sälja in agil utveckling mot kund. I alla fall inte att förklara upplägget och skriva offerter där vi kanske inte vet exakt vad som ska levereras. Det är sådant som gör kunden nervös. "Allt det där agila låter ju bra och så, men jag vill ha ett fastpris och veta vad jag får".
Parallellt med det här håller jag på att sätta mig in i de olika agila projektmodellerna lite mer på djupet. Boktips tas gärna emot.
