DevOps – Implementering og forankring i organisationen

Ofte ender dialogen mellem development og operations i et typisk ’blame-game’ hvor begge siloer bebrejder hinanden og mener at det er de andres skyld. Hvis ovenstående illustration er en genkendelig situation, eller tilsvarende ordvekslinger udspiller sig i jeres organisation, så kan det være at det er tid til at bevæge jer DevOps-vejen.

Organisationer, der lykkes med at arbejde med DevOps går 2.555 gange hurtigere fra commits til produktion end andre organisationer. Alene derfor kan det være en rigtig god idé, at se på sin organisation og på ’plejer’ og opnå en helt ny måde at arbejde på. DevOps handler om at Udvikling, QA og Operations skal 'smelte sammen' så der bliver skabt et team og en kultur hvor alle har ligeligt indsigt i og ansvar for alle processer, der foretages.

Men hvilken værdi giver DevOps:

• Nedbryder siloer, skaber positiv kulturændring og bedre samarbejde

• Automation, der reducerer fejl og sikrer at der reageres hurtigere på fejl

• Skaber forretningsværdi og kortere time-to-value

Har man fået styr på DevOps, vil man pga. det tætte samarbejde, og især automatisering, kunne høste en masse fordele og en af de primære er, at mængden af fejl vil blive reduceret voldsomt. De automatiserede flows og tests gør det nemt og ultra agilt, at reagere på de fejl, der utvivlsomt vil komme. På den måde bliver man lynhurtigt opmærksom på fejlen og kan rette den og deploye en ny version, der med tryghed kan sendes ud og erstatte det fejlede. Det lykkelige scenarie ovenover kræver dog en kulturændring og det er vigtigt at kigge på, at forskellige afdelinger har forskellige KPI’er de bliver målt på. Operations bliver fx. målt på antal fejl og udviklingsafdelingen, bliver målt på udgivelsen af nye features. Kunne disse parametre ændres til hvor hurtigt kan man rette en fejl i produktionen, ville det skabe langt mere synergi i de nye teams, der skal arbejde sammen.

Ved at adoptere principperne fra agil udvikling, automatisering, continuous integration og continuous delivery kan man nå målet; at kalde sin organisation DevOps. Dermed kan man opnå det vigtigste ved DevOps, hvilket er, at man forstår og prioriterer kundens og forretningens behov, så man kontinuerligt leverer værdi.

Man kan ikke sige DevOps uden at kunne stave til Agil

Mit eget første møde med agile processer ude i virkeligheden, var som ansat i en virksomhed, der leverede embedded software og sensorer til autonome operationer til forskellige industrier. Derfor var der meget fokus på sikkerhed. Der var på et tidspunkt et krav fra organisationen om, at vi skulle begynde at levere hurtigere. Virksomheden besluttede at det der skulle til, var at arbejde agilt, da det burde speede processerne op, og alle blev sendt på et 2-dags scrum-kursus. På kurset øvede vi os i teambuilding og i at afholde de forskellige mødetyper, der hører med til scrum-processen og fik en masse gode ideer.

Da vi nu havde lært en masse om processerne, så kørte vi bare de nye processer ind i vores normale dagligdag. Desværre mistede vi meget af den forståelse, der egentlig er meningen med agil. Det resulterede i, at vi havde en masse store opgaver, der fx. tog optil 2-3 uger. Vores daily scrum møder gik derfor mest ud på at fortælle hvor mange dage eller uger, der skulle bruges på at færdiggøre opgaven og gøre opmærksom på at man evt. skulle have support fra andre teams. Det tog lang tid at forklare hvor man var og hvad problemet bestod i, ofte så umuligt at man nærmest opgav på forhånd- resultatet var, at man aldrig fik den support og hjælp, som man håbede på fra samarbejdet og selve mødet daily scrum voksede til en enorm tidssluger.

På samme måde så blev de værdier der lå i sprint-planning, retrospective og review aldrig rigtigt kapitaliseret og det endte med, at vi blot afholdt ét langt møde på den samme dag, i stedet for flere korte møder med hver sit fokus, da det alligevel tog en hel dag at komme igennem det hele. Der var derfor allerede en masse fejl og en misforstået tilgang til hvordan man forsøgte at implementere de agile processer. Så mange, at Devops faktisk slet ikke var et tema.

En af de første fejl, havde at gøre med planlægningen. I virksomheden var der mange specialister med en helt særligt viden, så opgaverne var ofte assignet særligt til kun den ene ekspert, hvilket gjorde at opgaverne voksede og blev formuleret til at indeholde en masse dele. Fejlen ved det er, at når der skulle samarbejdes, så var der ikke rigtigt noget naturligt hul hvor man kunne trække andre med ind i arbejdet og der fandtes ingen visualisering af hvor i processen specialisten var. Man mistede derfor team-support muligheder, da man ikke kunne se hvorfor arbejdet var lavet som det var, eller hvordan den andens tilgang var. Man kunne ikke spejle sig i andres processer, vidensdele eller sparre som et team, og reviews og test blev svære at overskue for udenforstående. Begreber som ’continuous integration’ og testing blev ikke udført, men udeladt og glemt. Alt dette taler helt imod det centrale i at begynde at arbejde med DevOps, nemlig at ’muren’ mellem udvikling- og testafdelingerne skal nedbrydes.

I DevOps skal der helst ikke være hverken en test-afdeling eller en operations-afdeling. Test skal ligge hos udviklerne og de skal have ejerskab med det de leverer og vide, at der skal leveres kvalitet. Continuous integration, som indbefatter testing og merging af kode, skal verificere, at hver gang der videreudvikles, så testes det, at alt der er lavet tidligere, ikke er ødelagt. Har man delt opgaverne op i mindre dele, så kan man på de løbende reviews blive meget mere konkret og sikre endnu bedre information til hinanden. Reviews handler ikke om at være efter hinanden, men at dele viden og få en forståelse for hvorfor folk har bsluttet netop det de har og valgt de og de løsninger, så man kan guide hinanden og bevæge sig samlet fremad. Til sidst er der automatiseret release – for har man tiltro til at det man laver kan bygges, at det kan testes og at det virker, så kan man også lige så godt release – hver gang.

Så det er vigtigt, at stille sig selv nogle spørgsmål før man går i gang: ER I agile? For ellers kan det ikke betale sig, at begynde at tale DevOps...

De 3 spørgsmål I skal stille jer selv er:

• Leverer dit team fungerende software til brugere og samler feedback ved hver iteration?

• Har teamet lov til at ændre krav, baseret på bruger-feedback?

• Kan teamet ændre sine processer, baseret på det som de lærer?

Der skal gøres plads til de ændringer i processerne, der er gavnlige – fx. skal der kunne ændres på krav og processer hvis man ønsker, at komme frem til en mere smidig måde, at gøre tingene på.

Kernekonflikten i DevOps er, at der de allerfleste steder eksisterer en ’wall of confusion’ imellem udviklerne, QA og operations. Udviklerne har som fokus, at få skudt noget nyt afsted hurtigt – det er et krav fra deres PM og ofte også bundet op på deres bonus – operations skal sikre at alt virker og at ’skibet’ ikke synker- så de vil hellere være grundige og beholde status-quo, fordi det virker. Om det derfor tager 1 eller 2 dage, er mindre vigtigt - det vigtigste er, at Ops og QA gennemsøger og finder de fejl, der måtte være. Når en fejl bliver identificeret i produktion, vil Ops forsøge at afhjælpe situationen og bede udviklerne om at løse problemstillingen, men udviklerne er allerede rykket videre til udvikling af nye features, og har derfor ikke fokus eller interesse i at vende tilbage til allerede “afsluttede” opgaver.

Der er derfor et typisk clash i organisationen, som betyder at vedligeholdelsen bliver nedprioriteret, da mange organisationer har projekt-fokus, så pengene til udvikling stopper når projektet går i produktion. Dermed bliver ønskerne fra Ops nedprioriteret – Dev har ikke tid – Ops lukker derfor af for nye løsninger og vil have flere test og ændringer igennem før de vil acceptere nye ændringer til produktion – Dev bliver mere og mere irriterede og det er set, at Dev til tider finder på at release udenom Ops. Samlet set går det ud over forretningen, når disse kritiske afdelinger slet ikke arbejder sammen.

Det giver sig selv, at denne situation skaber et usundt arbejdsmiljø med interne kampe. I stedet for at kigge på udvikling, QA og operations som tre forskellige teams, bør man sammensætte et team hvor alle har fokus på samme mål og kontinuerligt leverer værdi til kunden. Det skal være slut med at smide opgaverne frem og tilbage mellem afdelingerne. På den måde bliver samarbejdet og teamet tværfunktionelt og kan sætte sig ind i kundens behov og den brugeroplevelse, der er i løsningen. Da teamet ovenikøbet nu er tværfunktionelt, er der et øget fokus på både at levere nye løsninger og features, men også at levere testede og veludviklede løsninger. Når udviklerne kommer tæt på test, får de mulighed for at automatisere alt, så der kan itereres hurtigt og fanges fejl uden besværlige, manuelle tests.

De klassiske begynderfejl:

1) Det er kun en del af organisationen, der har hørt om DevOps, tager ejerskab for DevOps og bliver misforstået af de andre enheder, når de kommer med deres gode råd, ideer om automatisering eller ændringer til arbejdsmetoder.

Læring: Man kan ikke kun starte processen nedefra. Man skal have støtte helt oppefra i organisationen.

2) Man har hørt om DevOps og ved det kan være udfordrende at få implementeret. Så man skaber en ny rolle fx. en Head of DevOps i IT. Denne person går så typisk i gang med at automatiserer en masse og træffe en masse beslutninger og skabe en masse regler. Misforståelsen her er, at det blot skaber en ny mindre IT afd. Eller endnu en IT afd. der føler ejerskab med DevOps – samme situation, som ovenfor. Egentlig skaber det endnu mere governance uden at give et bedre flow eller automatisering. Læring: Det er kulturen i virksomheden, som skal ændres, når der skal arbejdes med DevOps og det involverer mere end blot én afdeling.

Hvorfor DevOps?

De fleste organisationer arbejder med software i dag. Software er ofte kernen og det centrale i næsten alle slags brancher og derfor ikke noget, man kan komme udenom. Men hvorfor skal vi bruge alle de kræfter og al den tid på at ændre hele organisationen for at komme i gang med DevOps – hvorfor skal det være så svært?

Det handler ikke bare om software, men en kultur, der skal ændres således at ansvaret bliver alles og at informationen er delt. Det gør at vedligehold og udvikling bliver til én samlet enhed i stedet for konkurrenter og at man samtidig minimere overdragelsen af arbejde imellem forskellige teams, så værdifuld information ikke går tabt.

DevOps adresserer på den måde risikoen ved nyudvikling, da man forsøger at automatisere deployments og testing. Samtidig har et team lov til at reagere på manglende eller misvisende krav, da teamet kontinuerligt indsamler feedback fra kunden og forretningen, for at sikre, at der er værdi i det der udvikles. Det er uundgåeligt at kompleksiteten vokser i takt med at projektet vokser og har man ikke haft fokus på deployments, som DevOps advokere for, så bliver projektets deployments med tiden proportionelt mere og mere uoverskuelige og kan tilmed skabe en velbegrundet frygt hos teamet for at den nye version fejler. Samtidig bliver flowet fra kundens behov til at udviklingsteamet leverer værdi nemt dårligere og dårligere.

Der er to måder at anskue DevOps på.

1) En tekniske vinkel, hvor DevOps giver mening, da organisationen bliver hjulpet til at blive meget mere effektiv og komme flyvende igennem udviklingsprocesser pga. automatiserede processer. Samtidig sikrer metoden, at man hurtigt kan identificere og lokalisere fejl/bugs og dermed hurtigt få dem fixet, - inden de ender ude i produktion.

2) Den anden vinkel for virksomheden er, at muligheden for at innovere bliver langt større, da udviklingstiden og flowet til og fra kunden bliver optimeret. Det er en kæmpe fordel i et marked præget at stor konkurrence i nærmest alle brancher. Det centrale i dette perspektiv er, at arbejde med en MVP (Minimum viable product) for på den måde hurtigt at kunne visualisere arbejdet og at der løbende er fremskridt med løsningen, da alt tages i små bidder og ikke i kæmpe vandfaldsmodeller. Man designer ydermere til genbrug, så man nemt kan integrere med løsningen og videreudvikle på tværs af teams. Med disse vinkler i mente, er det tydeligt at DevOps ikke kun er relevant for softwareudviklingsfirmaer, som mange måske fejlagtigt tænker…

DevOps er dog ikke bare noget, man gør. Man er nødt til at have ledelsen med. Det kan bl.a. gøres ved at nedsætte et light-house-team, som arbejder med metoden ’ice-cream scooping’. Ice-cream scooping betyder, at der identificeres et område, typisk af et større projekt, som der kan udvikles på særskilt og at man på det afgrænsede projekt begynder at arbejde med DevOps processerne (se illustration herunder). Når udviklingen på lighthouse projektet er startet, er det vigtigt, at der fra ledelsens side, er tildelt et klart mandat, således at lighthouse-teamet kan interagere med ejerne af de processer, der eksisterer i virksomheden, med fokus på at få dem automatiseret.

På den måde får man skabt et agilt team, der kan påbegynde ændringerne med virksomhedens processer, som skal ændres fra manuelle processer til automatisering.

Lighthouse-teamet, der starter kulturændringen i organisationen, kan på sigt transitionere over i et centralt team, som har ejerskab for de automatiserede processer. Men pas på, at det ikke blot bliver en ny IT-afdeling, deres opgave er i stedet, at vise andre teams hvad metoden kan give af værdi og få udbredt den til flere andre projekter og erstatte ’plejer’ i udviklingsarbejdet, med den nye samarbejdsform.

How to

De vigtigste trin i processen og kulturændringen mod at arbejde på DevOps måden:

• Executive Sponsorship skal være på plads

• Fokus på intern kommunikation og at skabe ”hype” i udvikler-community fra første færd

• Start med mindre applikation først (MVP step)

• Derefter større projekter og flere teams

• Etablér et Cloud Center of Excellence (CoE) team til at drive Cloud-udrulning

• CoE teamet bør ikke være for stort til at starte med. Tænk "lean-&-mean" og fokusér på det rette skill-mix og villigheden til at lære

• Udvid på tværs af organisationen

Microsoft har undersøgt resultatet ved at arbejde med DevOps, for at anskueliggøre værdien, som man kan opnå ved en DevOps tilgang og kulturændring og har indsamlet data om resultatet før og efter implementeringen af DevOps:

Organisationer der lykkes med at arbejde med DevOps går 2.555 gange hurtigere fra commits til produktion end andre organisationer.

Samtidig er der færre interne stridigheder, hvilket giver en bedre arbejdsplads og -kultur. Arbejdet bliver hurtigere færdigt og man reducerer mængden af ikke planlagt arbejde, hvilket giver et langt bedre fokus. Oveni alle disse positive outputs, reducerer man også tiden der bruges på at adressere sikkerhedsproblemer.

Forandringsprocessen i organisationen er illustreret herunder ved de fire faser, med start fra venstre. Det er vigtigt for at lykkes at ledelsen er med og at man starter i det små hvorefter kulturændringen og organisationsforandringen langsomt kan brede sig til hele organisationen.

Held og lykke med arbejdet, forandringsprocessen (illustreret ovenover) og kulturændringen, som I står overfor.