The Phoenix Project - En bok om IT i allmänhet och DevOps i synnerhet
Peter Neikell
Lite teori…
De senaste åren har DevOps blivit alltmer omtalat. Allt som oftast som den förändring som kommer att lösa all världens IT-problem. Mycket av grunderna i DevOps bygger på lärdomar från den traditionella tillverkningsindustrin som till exempel teorin om begränsningar (TOC), Lean och Toyota Production System (TPS). Det handlar i mångt och mycket om att identifiera flödets begränsningar, hitta ett sätt att utnyttja den begränsande kapaciteten fullt ut och sedan anpassa övriga flödet till dessa begränsningar.
Teorin om begränsningars 5 regler kan i korthet beskrivas så här.
Identifiera begränsningarna i flödet Detta sker genom att undersöka flödets olika delar. Vanliga begränsningar är. · Resurser – personer, maskiner etc · Handlingssätt – Begränsningar av flödet som styrs bland annat av ledningsbeslut och företagskultur. T ex att använda samma policy för allt arbete eller ”så här har vi alltid gjort”-mentalitet. · ”Onödiga” begränsningar – Saker som lätt kan åtgärdas med pengar, t ex bättre datorer, ny mjukvara, rätt resurs för rätt uppgift etc
Hur man utnyttjar de identifierade begränsningarna bäst · Optimerar användningen av den begränsande faktorn · Hittar sätt att ta sig runt begränsningarna
Att anpassa hastigheten på övrigt arbete till begränsningens hastighet · Drar ner på överproduktion · Begränsar mängden pågående arbete (WIP) · Jämnar ut flödet
Investera i den identifierade begränsningen · Skaffa fler resurser, maskiner etc · Rätt resurs på rätt plats
Upprepa tills du uppnår det du vill · När en flaskhals åtgärdats är det något annat som blivit begränsande istället. Detta bör vara en ständigt pågående process.
Lite handling…
När jag fick DevOps-gurun Gene Kims bok The Phoenix Project i min hand, så var min första tanke; - Hur spännande kan det vara med en novell om IT-produktion?
Det visade sig dock att det kan vara mycket spännande. Men kanske framför allt lärorikt.
När vi kommer in i handlingen har det fiktiva tillverknings- och försäljningsföretaget Parts Unlimited stora problem med sitt affärskritiska projekt, Phoenix. Projektet drar över budget, lanseringen har blivit uppskjuten flera gånger och är trots detta långt ifrån klart. Huvudpersonen Bill, som är en mellanchef på IT-avdelningen blir uppringd av VD’n och erbjuds rollen som IT-chef. Samtidigt får Bill veta att han har 90 dagar på sig att få ordning på och sedan sjösätta Phoenix. Misslyckas han, kommer hela IT-avdelningen att outsourcas.
Efterhand som dagarna går ställs Bill inför det ena problemet efter det andra. Det handlar om alltifrån att affärssidan försöker starta egna IT-projekt genom att kontakta resurser direkt, ett icke-fungerande incidenthanterings- och förändringsarbete, till att säkerhetsavdelningen ser sig själv som viktigast av allt. Medan Bill och hans team kämpar på för att lösa de problem som de ställs inför dyker Eric, som lite mystiskt benämns som ”en potentiell styrelsemedlem”, upp i handlingen. Han beter sig lite som Mr. Miyagi i Karate Kid, och ger halvkvädna ledtrådar som tvingar Bill att tänka till för att först försöka identifiera, och sedan bemästra, de tre vägarna inom produktion. Detta görs bland annat genom ett antal besök i en av Parts Unlimiteds produktionsanläggningar där de diskuterar principerna bakom Lean och TOC.
De tre vägarna som Eric vill att Bill ska få en förståelse för är:
Lär känna ditt flöde – Skapa en förståelse för hur flödet fungerar. Detta kommer att snabba upp leveransen hela vägen från utveckling till drift och vidare till slutanvändare.
Konstant flöde av feedback – Korta ner feedback-looparna så att förbättringar kan göras kontinuerligt. Om detta lyckas, leder det till stabilare flöden och därigenom en större trygghet i att leveranser kan ske som önskat.
Kontinuerligt lärande och experimenterande – Sträva efter att skapa en miljö som uppmuntrar till experimenterande och risktagande där man vågar misslyckas, och att man drar lärdom av dessa misslyckanden. Detta i kombination med förståelsen för att ”övning ger färdighet”, kommer att leda till en organisation som vågar utmana sig själv och samtidigt ha erfarenheten och kunnandet för att reda ut situationer som dessa utmaningar kan orsaka. Allt gjort i syfte att förbättra organisationens flöden.
Författarna, Gene Kim, Kevin Behr och George Spafford har lyckats skriva en bok där man lätt känner igen sig i de flesta av de situationer som huvudpersonen Bill hamnar i. Detta oavsett om det handlar om system som går ner med där på följande eskaleringar, felaktigt resursanvändande till följd av att man inte följer uppsatta beslutsvägar, till problem med långsamma databaser.
Den förändring av kultur och arbetssätt som genomförs, och den utveckling som Bill och hans team genomgår under de 90 dagar de har på sig att lösa IT-problemen på det fiktiva företaget Parts Unlimited är fantastisk. Självklart beror detta delvis på att tempot är uppskruvat för att hålla kvar läsarens intresse. Men en organisation som är beredd att satsa, och som har ett antal engagerade medarbetare med stort kunnande har alla möjligheter att förändra och förbättra sin organisation genom implementering av DevOps.
Boken är dessutom en utmärkt inspirationskälla för hur man kan använda DevOps för att IT ska bli en del av affären, och inte bara en stödprocess vid sidan om.
Lite slutsatser…
De lärdomar som jag själv tar med mig är en kombination av de tre vägarna och TOC och kan sammanfattas i följande punkter.
Det är viktigt att våga se bortom sitt eget team. Att hela tiden försöka se helheten i flödena och att alltid ha företagets bästa i åtanke.
Bryt ner större uppgifter i mindre, hanterbara delar för att få upp hastigheten i leveranserna.
Se till att få igång ett återkopplingsflöde tidigt i arbetet för att involvera alla intressenter. Detta leder till samförstånd, bättre effektivitet och högre kvalitet.
Då IT-arbete är ganska abstrakt är det otroligt viktigt att försöka visualisera det så att alla förstår vad som behöver göras och vad som pågår. Här kan en Kanban-tavla vara till stor hjälp.
Automatisera så mycket som möjligt för att göra moment snabbare och mer effektiva samtidigt som man tar bort en stor felkälla i den mänskliga faktorn.
Summa summarum kan jag bara varmt rekommendera alla som inte redan läst The Phoenix Project att skaffa sig ett exemplar, sätta sig bekvämt tillrätta och njuta av en intressant stund.