DevOps metodiken bygger på ett erkännande av både Lean- och Agile, där man plockar ut de mest värdeskapande metoder och praktiker och kombinerar dem för att få ut maximalt värde över hela organisationen. DevOps handlar dock inte bara om att kombinera utveckling (development) och drift (operations) utan också att skapa en kultur som innebär samarbete, kommunikation och kontinuerlig förbättring. Vi bad Jessica Zygelman, som precis gjort denna resa, att delge sina erfarenheter och lärdomar.
Att hitta rätt i kulturen kan vara en utmaning när man ändrar ett företags utvecklingskultur. Vikten av att säkerställa samsyn kring ett kulturskapande arbetssätt är central, när man eftersträvar att utveckla människorna i organisationen. Målet är en värdeskapande utveckling på alla organisatoriska nivåer, där man jobbar mot gemensamma mål i en öppen kultur utan silos.
Redan 2008 på en konferens rörande Agil utveckling myntades fenomenet DevOPS, då Patrick Debois stod och förespråkade behovet och vinsten av att få utveckling och drift att samverka bättre. Men fortfarande är det många organisationer som inte kommit dit, så hur kommer man dit och vad krävs för att man ska lyckas?
Kulturförändring för alla
Jag fick vara med om att bygga upp en DevOps kultur i ett bolag med lång tradition inom IT utveckling. Detta var en utmaning som har varit fantastisk rolig och lärorik för mig. Det har handlat om en kulturförändring hos både beställare, användare, utvecklare och även inom hela organisationen. Att skapa värde kan man ju tycka att man alltid gjort, men genom DevOps metodiken är det vad man pratar om, tillsammans i det öppna rummet. Man pratar inte tidsuppskattningar, man pratar inte tid överhuvud taget på samma sätt som man traditionellt alltid gjort vad det gäller utveckling av programvara. Målsättningen är att leverera ett värde kontinuerligt med hög kvalitet och i kortare cykler än man gjort tidigare.
Så här jobbade vi
Vi började jobba med att definiera vår backlogg och våra user stories. Det är konkreta och relativt, i sammanhanget, enkla uppgifter. Men att få med processägare och beställare i tankesättet att vi ska leverera värde och sluta prata tidsestimeringar och stora implementationer, det var en tuffare uppgift. Tillsammans arbetade vi i korta iterationer enligt ett agilt arbetssätt där vi hela tiden involverade processägarna. De involverades i allt från att förbereda nästa iteration med att fånga in krav och författa user stories, till att vi lyssnade på deras åsikter angående prioriteringar. Processägarna var delaktiga men det var teamet som ägde backloggen och hade det sista ordet hur olika user stories skulle prioriteras.
I varje sprint planerade vi utifrån vad vi kände till avseende kapacitet, prioritering och kända buggar. De senare skulle alltid prioriteras högst. Sedan händer det alltid något oplanerat i varje sprint, buggar, sjukdom eller något annat hinder dyker upp. Detta måste man räkna med när man planerar en sprint, men det lär man sig med tiden. Buggar prioriterades alltid och utreddes löpande när de kommer in. Det gjordes en bedömning huruvida de måste lösas direkt eller om de kunde läggas i backloggen för att tas om hand senare. De dagliga stand-up-mötena var prioriterade för alla och gav hela teamet en bra inblick hur det går för varje teammedlem. När man var färdig med sin egen uppgift frågade man alltid sina kollegor om de behövde hjälp innan man tog sig an och påbörjade nästa uppgift. Man hade aldrig mer än en uppgift pågående samtidigt såvida man inte väntade på svar från en beställare. Helst ska varje user story vara så nedbruten i kortare tasks (uppgifter) så att den kan tas om hand av flera team medlemmar. På det sättet fick vi till ett bra samarbete i teamet och kunde lättare hjälpas åt att färdigställa en user story.
Skapa ett öppet klimat
Vi lyckades skapa ett klimat där det var en självklarhet att hjälpas åt inom ett team och mellan teamen. Om någon fastnade så tog man hjälp av varandra för att lösa problemet tillsammans. Inom teamet testade och granskade vi varandras kod innan vi genomförde regelbundna demo där funktionaliteten visades för en beställargrupp/processägargrupp. På dessa demo-tillfällen hade de möjlighet att komma med synpunkter och godkänna funktionaliteten innan den sattes i produktion. Vi månade hela tiden om att ha en öppen och transparant dialog med berörda processägare. Det ledde till ett stort intresse och engagemang hos dem då de kände sig delaktiga och att teamet lyssnade på dem. Det som inte godkändes vid demon korrigerades antingen innan release eller fick åtgärdas i nästa iteration för att släppas i kommande release två veckor senare.
Avsätt tid för reflektion
Förutom att vi avslutade varje iteration med en demo så genomförde vi också ett möte med möjlighet för reflektion den sista dagen i varje iteration. Alla i teamet deltog i dessa retrospektive-möten utifrån ett för sprinten utvalt tema. Som team medlem turades man om att ansvara för och hålla i dessa möten. Tillsammans svarade vi på ett antal frågor i syfte att hela tiden förbättra och utveckla vårt arbetssätt. Vi reflekterade över vad som gjort att vi kanske inte hunnit med allt vi hade planerat inom sprinten, men lyfte också fram allt bra vi gjort för att boosta oss som team.
”När man som produktägare och scrum master får höra att - vi har bra stämning i teamet, vi hjälps åt och vi har ett gemensamt ansvar för alla pågående user stories, då blir man varm i hjärtat”. DevOps handlar väldigt mycket om människor och kultur och att man skapar en god arbetsmiljö där ingen lämnas åt att lösa något själv utan man levererar som ett team. Man firar som ett team och hjälps åt som ett team utan någon prestige. Klyschan ”Laget före Jaget” kan kännas lite uttjatat men det stämmer så bra in på hur vi lyckades implementera DevOps tillsammans.
Att samlas i ett produktägarforum
Vi som agerade produktägare hade var sitt team som ansvarade för en utpekad värdekedja. Vi möttes i ett gemensamt forum varje vecka för att informera varandra om våra teams utmaningar och vad vi fokuserade på för tillfället så att vi förhindrade att teamen jobbade i silos. Behövde vi hjälp från varandra flaggade vi för det inför en sprintplanering och kom det in buggar som riskerade att beröra flera team så var det en självklarhet att man hjälptes åt över team-gränserna. Även om man hade sitt ansvar och såg till sitt team först så var man aldrig långt borta att hjälpa varandra över teamgränserna. Detta var ett beteende som uppmuntrades och uppskattades av alla. Produktägarna hade också en gemensam genomgång med alla från samtliga team vid behov. Det kunde tex. vara att ett team delade med sig av ett väl fungerande arbetssätt eller att man lärt sig något nytt som man trodde att fler kunde ha nytta av. Dessa gemensamma träffar var mycket uppskattade och skapade förutsättningar för ett gott samarbetet mellan teamen.
Gammalt är inte modernt
Utmaningarna för oss var att vi hade gott om ”gammal kod”, en så kallad teknisk skuld i vår kodbas. Det gjorde tyvärr att tempot och omfattningen av våra leveranser ibland påverkades. Vi ville inte bara bygga in nya lösningar i gammal kod. Vi ville skapa värde även för utvecklarna genom att skriva om gammal kod till ny kod när vi fick chansen. Vi ville helt enkelt skapa värde både för användarna, i form av önskad funktionalitet, och för utvecklarna som på sikt skulle få arbeta i en uppfräschad kod. Ibland hamnade vi dock i en ond cirkel där varje story som skulle utvecklas tog lång tid att färdigställa på grund av denna utmaning. Detta gjorde att vi fick ta fram ett antal principer för att kunna ta beslut och värdera varje förändring Att introducera nya medlemmar i teamet där man har mycket teknisk skuld att arbeta med är tidskrävande och kan vara frustrerande men detta handlar mycket om ett förhållningssätt och att man har tålamod och hjälps.
Mognadsprocess och nästa steg
När vi blev mogna i detta arbetssätt och även våra användare blev mer vana, både som beställare och mottagare, så började vi mer och mer titta på hur vi kunde jobba med automatisering samt att införa testdriven utveckling. I mitt team fick man varje vecka lägga några timmar på självstudier i aktuella relevanta ämnen. Den tiden fick man själv välja och den fanns med i den gemensamma planeringen. Ibland utnyttjade vi tiden i gemensamma möten för att dela med oss av nyvunnen kunskap som ”tips och trix”. DevOps handlar om att jobba med ständiga förbättringar för att skapa värde. Det gäller både de tekniker man jobbar med, den funktionalitet man levererar och det arbetssätt som tillämpas inom teamet och organisationen man befinner sig inom.
Lärdomar
Lyhördhet: Lyssna in processägare, användare och utvecklarna och justera efter hand som man utvärderar vad som fungerar bra och mindre bra. Skapa även ett klimat där man är lyhörd gentemot varandra i teamet
Tålamod: Förändring tar tid, och en kulturförändring tar verkligen tid. Att hitta sin egen väg och hela tiden förbättra och våga pröva. Låt det få ta tid.
Transparens och mod: Våga säga ifrån om något inte går att lösa och våga också ifrågasätta värdet av ett önskat behov. Våga tala om på retrospektiv vad som inte fungerat bra, så kommer man oftast fram till en lösning tillsammans som ett team.
"Lyhördhet och tålamod, transparens och mod är viktigt för framgångsrikt arbete med DevOps Jessica Zygelman, incubit AB"
Vid intresse eller för vidare dialog om vår erfarenhet av DevOps, vänligen kontakta vår kollega Jessica Zygelman
