Alldeles nyligen besökte jag Agical, ett mjukvaruföretag i Stockholm som arbetat agilt i många år, och som lyckats mycket väl med det. Jag har varit på besök tidigare, men det är mer än tio år sedan, så det var dags att återknyta bekantskapen.
Att arbeta agilt har blivit väldigt populärt, men det har också lett till att idéerna tunnats ut på många arbetsplatser. Ola Ellnestam, VD på Agical, och jag, bestämde oss för att skriva en artikel ihop och visa hur agilt arbete på Agical fungerar.
I slutet av artikeln har Ola råd för både ledning och utvecklare som vill arbeta mer agilt.
Henrik:
Det var roligt att träffa hela teamet på Agical förra veckan. Det märks att det är full fart på mjukvaruutvecklingen. Innan vi pratar om det, tänkte jag fråga om bakgrunden. När startade ni Agical, och hur jobbade ni i början?
Ola:
Agical startades våren 2005. Lite som en motreaktion på hur arbetet bedrevs i branschen på den tiden. Det var väldigt vanligt med projekt. Nästan alla IT-system utvecklades av en del av organisationen, medan en annan del skötte drift och underhåll.
Vi ville ändra på det.
I början jobbade vi ofta på våra kunders villkor. Projekt, kravspecar och linjeorganisation. Men vi visste att det gick att arbeta annorlunda, det hade vi gjort i enstaka fall. Vi ville sätta en annan prägel på arbetet. Det skulle vara agilt. Snart två decennier har gått så det är värt att minnas att det var i en tid då vi fick förklara vad vi menade. Vecka efter vecka, månad efter månad. För allt och alla.
Agilt var nytt, fräscht och framförallt rebelliskt.
Henrik:
Vad var det för agil metod ni kom i kontakt med först? Vad var det hos den som gjorde arbetet lättare? Jag märkte när jag besökte er att ni har kul när ni jobbar. Bidrog agila arbetssätt till det?
Ola:
Extreme Programming (XP) var den första metoden som vi kom i kontakt med. Sen kom Scrum och en dos Lean Software Development. Resan var lite olika för oss alla, men en sak var gemensam redan då. Vi ville ha kul. Det skulle vara lustfyllt och givande att arbeta med systemutveckling.
Henrik:
Den metod som ni använder nu är ju er egen. Kan du berätta lite om hur den har vuxit fram, och både likheter och skillnader jämfört med andra agila metoder?
Ola:
Sättet vi arbetar på idag är starkt färgat av XPs värderingar och tankarna bakom Lean Software Development. Enkelhet, kommunikation och korta ledtider är oerhört centralt hos oss.
Vi sitter ihop och arbetar ihop. Vi äger koden tillsammans och vidareutvecklar den tillsammans.
Allt detta på samma plats. Samtidigt. Det är enkelt.
XPs “Planning Game” eller Scrums “Sprintplanering” har vi rationaliserat bort. Vi förhandlar dagligen om vårt fokusområde. Vårt skämtsamma motto är: Leverera nya önskemål innan användarna hinner ändra sig. Det funkar bra. Eftersom vi levererar kod tre gånger om dagen kan vi också byta riktning när som helst. Det uppskattas av användarna av systemet.
Det är vår tolkning av korta ledtider från Lean-tänket.
Henrik:
Många team kämpar med att leverera en gång i månaden, eller en gång i kvartalet. Hur gör ni för att leverera tre gånger om dagen? Och hur håller ni kvaliteten på koden tillräckligt hög?
Ola:
Det började med att vi skaffade oss ett väldigt enkelt sätt att kunna återgå till en fungerande version av systemet. Vi har ett sätt där vi med några enkla kommandon kan återställa systemet till normal drift. När något går snett. Vi kallar det vår “ångra”-strategi.
Med ångra-strategin på plats tog vi sedan nästa steg: Delleveranser
Vi utmanade oss själv att stycka upp funktioner. I tät dialog med verksamheten så kunde vi minska omfånget på önskade funktioner, och leverera tidigare. Eller leverera en ersättare vid sidan av det äldre sättet att göra något. Vi använder tekniker som underlättar löpande driftsättningar. T. ex “Dark Launches”, “Keystone” och “Brytare”.
När vi var bekväma med dessa tekniker vågade vi gå från utveckling i “feature branches” till kortlivade Git-förgreningar. Därefter dumpade vi även de kortlivade förgreningarna och ägnar oss numera åt “Trunk Based Development”.
Koden håller vi i schack med hjälp av tester, statisk typning och programmering i grupp eller par.
Henrik:
När jag var på besök hos er nämnde du att refactoring är viktigt för er. Kan du berätta lite om det?
Ola:
Refactoring är ett fundamentalt verktyg i vår grupp. Det är så pass viktigt och högt aktat att vi jämställer det med skickligheten hos en hantverkare, färdigheterna hos en konstnär eller kanske tekniken hos en skridskoprinsessa.
Vi använder refaktorisering hela tiden för att kunna forma om kodbasen efter behov. Hundratals, om inte tusentals, grepp rinner ur våra fingrar dagligen. Byt namn på metod, kapsla in, exponera, flytta, möblera om och så vidare. Allt detta i läsbarhetens och förståelsens namn.
För datorer spelar det ingen roll hur koden ser ut, så länge den kompilerar. För oss människor däremot är läsbarhet och förståelse av största vikt. Vi måste förstå vad och varför koden ser ut som den gör, annars vågar vi inte ta ansvar för den. Än mindre ändra i den.
I och med att vi är så starka på refaktorisering kan vi använda vår nära relation till verksamheten på ett bra sätt. Vi har lätt att omsätta nya behov och ny information omedelbart.
Något som bara är möjligt för att vi kan forma om kod snabbt. Det, och att driftsätta ofta.
Henrik:
Det finns många företag som kämpar med att få mjukvaruutveckling att fungera. De använder ofta Scrum. Har de större projekt har de SAFe som ett övergripande ramverk för att koordinera flera team. Har du något råd att ge chefer som vill bygga en väl fungerande utvecklingsorganisation?
Ola:
Det är lätt att ledas in på spåret, större projekt kräver en större mängd människor. Vi tänker direkt: “Ska vi bygga en pyramid så behöver vi vara tusentals arbetare” eller “Ska vi programmera ett jättestort dataprogram så behöver vi vara hundratals utvecklare”.
Ironiskt nog så är det vår egen vilja att lyckas som gör att vi lägger krokben på oss själva. Vi vill lyckas snabbt. Vi kastar ombord folk. Vilket bara sinkar oss.
Om vi ska göra stordåd, vilket jag personligen tror är en fälla i sig. Men OM vi ska det göra det så bör vi få ta det lugnt och låta det växa fram över en längre tid.
Vi behöver lugna ner oss och skala på längden, istället för bredden. Istället för att lägga till 10 nya saker till att-göra-listan, kolla om du kan stryka tiotusen saker från den.
Med andra ord; motstå frestelsen att göra organisationen större. Hjälp varandra att hålla organisationen liten och uppmuntra varandra till tålamod.
Litet är vackert.
Henrik:
Det stämmer med mina erfarenheter. Jag ser ofta projekt med 4-5 gånger fler personer än som verkligen behövs. Orsaken är att man mer eller mindre per automatik tar in mer folk, istället för att försöka förstå vad det är för problem man har. Jag ser också att man tar in mer folk utan hänsyn till om mjukvaruarkitekturen tillåter att många människor arbetar effektivt tillsammans.
Vad kan enskilda utvecklare, och utvecklingsteam, göra på egen hand för att lösa problem med dåligt fungerande mjukvaruutveckling?
Ola:
Jag utvärderar organisationer som utvecklar mjukvara efter fyra punkter
Tiden det tar att leverera en förändring
Antalet leveranser per dygn
Graden av felaktiga leveranser
Genomsnittlig tid för återställande av felaktig leverans
Om vi tittar noga så handlar det om storlek och kvalitet på flödet.
Vill du att arbetet ska flöda bättre runt dig och ditt arbetslag ska du bli bättre på att fokusera på rätt sak. I sin tur betyder det att du ska kunna släppa det du gör om något viktigare dyker upp.
En enkel recept för det är
Dela upp det du gör i mindre bitar
Leverera löpande
Leverera hela vägen
Gör färre saker
Tekniker för det här har vi rört vi tidigare om men jag sammanfattar här
Lär dig:
Förstå affärsvärdet
Refaktorisera
Lyssna på varandra
Prata klarspråk
Henrik:
Tack Ola! Bra råd, både för ledning och utvecklare.
Det var kul att vara med och se hur ni jobbar. Minst lika full fart som när jag träffade er förra gången, för tio år sedan, och det syns att ni har roligt.
Jag hoppas att vi syns snart igen.
Henrik Mårtensson 
Henrik Mårtensson är lyckligast när han arbetar som troubleshooter för företag och andra organisationer: “Något är fel med hur vi jobbar, men vi vet inte riktigt vad. Kan du titta på det?”
Henrik arbetar också som processexpert, agil coach, Scrum Master och projektledare. Han har ett förflutet som programmerare och systemarkitekt, och har jobbat för stora företag, små företag, för myndigheter, och vid ett minnesvärt tillfälle, en vikingaby. Han tycker att organisationer borde satsa mer på kompetensutveckling, för alla i organisationen, och att de bör göra små, reversibla experiment innan de hoppar in i storsatsningar med båda fötterna.
Henrik har skrivit flera böcker om management och processförbättring, deltagit i management-antologier, och har, som hobby, lett två serietidningsprojekt. Förutom att skriva, älskar han att fotografera, gärna med teman från Science-Fiction, Fantasy, Horror, och deckare. Han kombinerar ofta fotografi och 3D-grafik. Lite då och då bloggar han om management.
- LinkedIn: Henrik Mårtensson
- Twitter: @Kallokain