För att vinna i schack så räcker det inte att vara mästare på en pjäs – exempelvis mycket bra på att positionera löparen. För att vinna så behöver man se till helheten, både kortsiktigt och långsiktigt. Så är det även med DevOps…

Schack vs. DevOps

Mången äro de som har spelat schack under dess 1500 år långa historia. Med dåtida gamification så tränade krigsherrar strategiskt och taktiskt tänkande över ett bräde med pjäser med specifika förmågor för att förmå att besegra sina motståndare på slagfältet. Från en tid då besegra fiendens kung var målet till en tid då det handlar om anpassning och digital transformation för att vinna kundens hjärta. Vår tids arena handlar om digitalisering och snabba anpassningar men i stora drag är modellen den samma – vi vill vinna.

För att vinna i Schack så räcker det inte att vara mästare på en pjäs – exempelvis mycket bra på att positionera löparen. För att vinna så behöver man se till helheten, både kortsiktigt och långsiktigt. Så är det även med DevOps då det inte räcker med att vara en fullstacksutvecklare med Zlatankapacitet i kodande. Detta för att det inte är en uppgift för enskilda resurser utan ett samarbete mellan flera discipliner (pjäser) som behöver orkestreras med precision likt en symfoniorkester dirigeras. Varje drag leder till en senare konsekvens som behöver vägas in före exekvering, med ambitionen att nå optimala förutsättningar och scenarion där IT-projekten möter affärsbehoven och de strategiska målen.

Varje parti Schack genomgår en livscykel bestående av 3 faser – Strategisk (Öppning), Taktisk (Mittspel) och Operativ (Slutspel). Genom att bryta ner livscykeln i faser så blir det kommunicerbart kring var man har utvecklingspotential. Att spela Schack på tid gör att man kan träna på att lägga proportionerligt med tid på faser och mäta hur man ligger till mot tidigare mätpunkter. Att mäta aktiviteter i utvecklingsprojekten innebär att man får mätpunkter och beslutsunderlag för framtida förbättringar och bättre kan anpassa situationen till sin fördel.

Öppning – Strategi

Nybörjare i Schack spelar ofta ut sina starkaste pjäser först, med tanken att göra en snabb schackmatt. Mer rutinerade spelare bygger upp en position efter en utstuderad strategi utan att förlora tempo genom att behöva flytta samma pjäs flera gånger under öppningen. Precis som i Schack så ser man att mer rutinerade IT-projekt har utarbetade planer och strategier för hur man skall hantera hela livscykeln och försöker leverera värde utan att behöva skapa samma värde flera gånger, dvs. inget nytt värde.

Stormästare i Schack spenderar mycket tid på öppningsstudier och motståndares tidigare partier. Att studera tidigare lärdomar från lyckade och misslyckade projekt är viktigt för att få en bra projektstart. Det är även viktigt att planera för förvaltning tidigt då det är i projektstarten man sätter förutsättningar för hur väl resultatet och effekter uppnås senare i livscykeln.

Genom att tidigt sätta upp arkitektur, integrationer och processer för automation och samarbete så säkerställer man tidigt att det som levereras samt överlämningar från olika discipliner fungerar smidigt och taktas efter förmåga. Man vill tidigt veta vad som fungerar då det är svårare att ändra strategier ju fler drag man har genomfört. Strategier måste integrera tekniken med affärinitiativen, Schack utan bra öppning är som DevOps utan strategi och styrning.

Mittspel – Taktik (Dev)

Mittspelet i Schack handlar om att lämna tryggheten från förberedda studier och taktiskt anpassa sig till rådande situation. Genom att rent psykologiskt läsa och påverka sin inre röst och motståndare genom undermineringar, taktiska fällor och små vinster. Genom att kontinuerligt utvärdera hur det går och om det finns några möjligheter eller problem så kan projektet bli mer adaptivt och teamet får en högre grad av överlappning och transparens i varandras roller vilket leder till naturlig kompetensöverföring och mindre risker. En svaghet är inte en svaghet om den inte går att attackera och tidig attack kan vara bästa försvaret.

Man försöker hitta positioner och ställningar som känns bra givet förutsättningar, så även i DevOps där man försöker få byggen att gå igenom tester och färdiga bitar distribuerade hela vägen och kontinuerligt övervaka, förfina och optimera flaskhalsar.

Slutspel – operativt (Ops)

Nu är vinsten i sikte – det är inte så mycket pjäser kvar på brädet och spelet går in i en mer operativ fas, där det gäller att kunna förutse vägen till vinsten. Projektet är nu i slutfasen och det gäller att få acceptans från kund och för förvaltningsorganisationen att säkerställa effektmål, förutsättningarna för vidareutveckling blir avgörande.

Mästaren är den med förmågan att kunna räkna hem vinstgivande drag med en tvingande serie drag. Ett bagage av svaga tidigare drag gör det avsevärt svårare att hitta rätt drag. Inte alla IT-projekt når denna fas, då de ibland faller platt under tidigare faser, men med bra verktyg för att mäta Teknisk Skuld genom kodanalys och bra arkitektur och dokumentation erbjuder en enklare acceptans och kan påvisa rätt kvalitet på rätt element – varken mer eller mindre utan precis på målet. Det är genom att motverka teknisk skuld som vi kan fortsatt vara agila och flexibla i framtiden.

Summering

Ett vanligt talesätt bland schackspelare är – Hotet är starkare än genomförandet. Tanken är att genom att hota med ett drag, så kan man påverka sin motståndare i en viss riktning som medför mer tankeverksamhet än att faktiskt utföra draget. Vi är människor med mänskliga relationer och utan tydlig kommunikation och tillit så kan hotet mot leveranser och överlämningar blir starkare än önskat.

Att inte göra något drag alls i en värld som digitaliseras blir en snabb schackmatt.

Det är genom DevOps som vi levererar moderna digitala lösningar, vi startar med en Strategi och en tydlig målbild för att sedan adaptivt och agilt hantera Taktiska faser och överlämningar för att säkra en Operativ seger och långsiktigt vinna våra kunders hjärtan.