Att införa Continuous Delivery & Deployment i komplexa system

Vi fokuserar mycket på effektiva scrum team, agila ramverk, organisatoriska transformationer, men glömmer ofta bort hur våra kunder kan ingå i produktutvecklingen. Här berättar Martin Fornegård om sina erfarenheter inom implementation av Continuous Delivery & Deployment som är en viktig del i det agila ekosystemet.

Inom träningskretsar pratar man om att det tar 10 000 timmar för att bli expert på något svårt. Nu är ju inte det helt sant, men det är välkänt att det du gör kontinuerligt och frekvent blir du väldigt bra på. Vill du bli bra på tennis så behöver du träna tennis ofta. Det kommer vara jobbigt i början för att du inte är van vid rörelserna och träningsvärken kommer komma som ett brev på posten. Men snart kommer du känna dig starkare, snabbare och säkrare, samtidigt som du gör mer rätt och får roligare. Och det är viktigare att träna lite varje dag än ett långt pass en gång i månaden. Att det krävs 10 000 timmar för att bli expert på något signalerar ju att man bör sprida ut timmarna kontinuerligt under lång tid. 

En fråga jag ibland får när jag jobbar med team och organisationer som vill ändra sitt sätt att arbeta för att bli effektivare, till exempel från att leverera mjukvara sällan till ett mer kontinuerligt leveranssätt är: ”Varför skulle jag göra något som är så besvärligt oftare?” Jo för att det du gör ofta blir du väldigt bra på! Vilket ju betyder att det kommer sluta vara så besvärligt efter ett tag. Antingen för att du lär dig hur du ska göra eller för att du kommer hitta på något sätt att automatisera momentet. Eller för att det besvärliga du gjorde faktiskt inte tillförde något värde och du helt enkelt slutar göra det! Alternativet är att göra det där besvärliga några gånger per år och då blir det svårare att lära av misstagen. Det blir också svårare att experimentera, att ta ett litet steg, utvärdera och kontinuerligt bli bättre.

Erfarenheter från verkligheten
Företaget jag arbetade på säljer produkter och tjänster till telekomföretag över hela världen, och ibland kan det vara svårt att få gehör hos kunderna för nya idéer. De telekomkunder med extremt komplexa system jag har arbetat med har traditionellt tyckt det varit otroligt svårt, besvärligt och farligt att uppdatera mjukvaran i systemen. För ett telekomnät har det ofta föregåtts av en planeringsfas på två till tre månader, följt av en testfas i ett labb, installeringsfas på delar av ett operativt nätverk, monitorering under en tid och sedan installering på resten av nätverket. Totalt kunde det ta ca tre till sex månader beroende på nätverkets komplexitet och storlek. När vi på utvecklingsavdelningen började erbjuda Continuous Delivery and Deployment (CD&D) som koncept till våra kunder, såg vi att bara genom att ändra arbetssätt och automatisera delar av leverans och testning, kunde ledtiden kortas avsevärt. Från det att vi släppt ny mjukvara på marknaden, till det att kunden hade hela systemet i drift på den nya mjukvaran tog det istället ca två veckor. För de kunder som verkligen anammat CD&D som koncept kunde de göra uppdateringen endast ett par dagar efter ny mjukvara släppts på marknaden.

Det vi gjorde var att titta på de moment som ingick i det totala leverans- och feedbackflödet för att sedan kunna bryta ner och effektivisera delarna, men fortfarande med fokus på helheten. 

Helheten är ett nyckelord här. Vår vision var att bli snabbare, inte bara internt, utan till det att kunden faktiskt använde produkten och vi fått och analyserat feedback. Detta pågick i flera år, och är fortfarande inte färdigt, men vi såg ganska snart att det gav positiv effekt. Ibland på områden som vi inte hade räknat med tidigare, även om det i efterhand verkar ganska självklart. Det triggade hela organisationen att våga ta ytterligare steg i rätt riktning.

1. Utvecklingsavdelningen beslöt, till att börja med, att släppa mjukvaran, fem gånger så ofta till marknaden, enligt devisen små batchar istället för en stor. 35 utvecklingsteam förstod nu vikten av bl.a. kvalitet, och att ha allt på plats innan koden integrerades. Administrativa moment började automatiseras, eller lades ut på teamen och deras ”Definition of Done” uppdaterades.
2. En prenumerationstjänst för mjukvara sattes upp. Förut kunde t.ex. mjukvaran laddas ner till en server för att sedan läggas på ett usb, köras i taxi till kunden, för att sedan installeras på en ny server i kundens nät.
3. Med rätt och snabb feedback kan utvecklingsavdelningen ta rätt beslut om hur funktionaliteten i uppgraderingen kan förbättras. Denna information kom delvis genom insamling av data men också genom att ha tätare dialog med kunderna och de som skötte näten.
4. De snabbare leveranserna gjorde oss relevanta för kunderna att ha ett DevOps samarbete med, vilket gjorde att vi kunde återanvända interna tester i kundens nät, och ledde till utveckling av ett nytt konkurrenskraftigt testverktyg. Testkostnaden för kunden minskade med ca 50%.
5. Vi började införa ett automatiskt sätt att samla ihop och återmata data till utvecklingsorganisationen, samt automatiskt analysera densamma.

Så, från att leverera mjukvara som tagits fram av 400 utvecklare varje halvår så började vi göra det kontinuerligt varje månad, med sikte på varje vecka. Stora telekomkunder i Europa, Asien och USA kunde ändra sitt arbetssätt dramatiskt och minskade sina ledtider och kostnader drastiskt. Produktkvaliten ökade och kunderna var nöjda. CD&D blev ett koncept som ändrade telekomoperatörernas syn på leverans och driftsättning av mjukvara.

Hur börjar man då?
När jag pratar med de som sköter systemen hos kunderna vill de, helt naturligt, aldrig ändra sina komplexa system för att risken finns att de noga justerade och konfigurerade systemen inte beter sig som förväntat efter en uppgradering. Samtidigt vill de ha de nya funktioner och rättningar som kommer i den nya mjukvaran. För att lösa det dilemmat finns det några generella grepp som man kan ta till:

1. Automatisera distributionen av mjukvaran. Den ska alltid finnas tillgänglig hos kunden när den behövs.
2. Automatisera testerna. Detta är ofta den tyngsta delen, men också den som lönar sig snabbast i form av kortade ledtider.
3. Automatisera installationen. Det här innebär ofta en förändring i själva produkten för att den ska vara bakåtkompatibel, och lätt att hantera. Samt att det ska vara lätt att göra en ”fallback”, alltså gå tillbaka till den förra installationen, om man hittar något fel man inte kan leva med.
4. Planera för uppgraderingar så ofta man kan för att kunna göra små, stegvisa förändringar i systemet.
5. Automatisera återkopplingen. Tyvärr glöms detta ofta bort men är otroligt viktig, för som alla vet, utan återkoppling är det väldigt svårt att förbättra.
6. Automatisera analysen av data från återkopplingen. Ofta är det stora mängder data som måste analyseras för att kunna dra några slutsatser.
7. Se till att utvecklande organisation kan rätta fel, och leverera dem, snabbt. Vi kommer aldrig kunna göra ett felfritt system från början, men vi kan se till att de fel som ändå görs kan rättas och levereras snabbt och smärtfritt. Och med en bra feedback- och analysprocess kan vi hitta fel, rätta det, och leverera rättningen, innan kunden har insett att det alls finns ett fel.

Sammanfattning
Inför man CD&D på rätt sätt kommer värde adderas kontinuerligt istället för kanske någon gång per år. Nya funktioner, förbättringar och rättningar kommer i en stadig ström samtidigt som ledtiden och kostnaden minskar för att installera den nya mjukvaran. Kvalitén på produkten ökar för att det sätter en press på de som utvecklar, som de bara får om kunden är inblandad. En utvecklare får en helt annan inställning om det som integreras kan gå ut till kund redan dagen efter kodleverans istället för att vänta månader på återkoppling. 

På samma sätt som med de organisationer som infört Continuous Integration på riktigt, och aldrig vill byta tillbaka till att bara integrera sin kod mer sällan, vill inte de kunder med komplexa system gå tillbaka till att bara uppdatera sin mjukvara en gång vartannat år. Även om det var besvärligt i början att uppgradera oftare så har fördelarna i form av återkoppling om kvalitet, riskminimering och att alltid ha den senaste funktionaliteten i sitt nätverk, varit helt oslagbar, och svår att leva utan när du väl har vant dig. Plus att det faktiskt har blivit billigare att sköta nätverket! Därmed inte sagt att CD&D är enkelt att införa, men det är väl värt investeringen.

Om det krävs 10 000 timmar eller ej är omöjligt att svara på men en sak är säker, gör inte allt på en gång.

• Kartlägg var ni är nu.
• Ta ett litet steg i riktning mot målet.
• Lär av vad som hände och justera riktningen.
• Repetera.
  
  

Martin Fornegård
Martin är en senior managementkonsult med stor erfarenhet av Continuous Delivery & Deployment och coachar stora organisationer i skalad agil verksamhet.