20stue_preview
>

DevOps, Lean, Kanban og ..boligsalg?

Markus Renton Skallist 
13. april 2018

For å få gjort boligen min salgsklar fikk jeg anledning til å ta i bruk det jeg har lært om DevOps, Lean og Kanban på hjemmefronten. Entusiasmen hjemme var enorm da jeg presenterte en metodikk som skulle hjelpe oss med å vaske og rydde.

I denne bloggposten presenterer jeg aspekter ved DevOps som inspirerer meg, før jeg gjør rede for hvordan noe av tankegangen hjalp min samboer og meg når vi skulle selge boligen vår.

Markus Renton Skallist
Markus Skallist, DevOpsentusiast og boligselger

Veien til DevOps-transformasjon

For en tid tilbake ble nysgjerrigheten på DevOps pirret av stadig økende bruk av skytjenester og spesielt automatisering i prosjektet jeg jobber som utvikler i. I første omgang forsto jeg DevOps som en slags hangup på å automatisere alt mulig man kunne tenke seg. Det var først da jeg begynte å lese The Phoenix Project at jeg skjønte at DevOps handler om mye mer enn å automatisere bygg, test og deploy. I boken, som handler om hvordan en produsent av bildeler gjør grep for å rette opp et feilende, gigantisk IT-prosjekt, trekkes DevOps først og fremst frem som et tankesett som preger måten man jobber på.

Gjennom filosofisk mentoring og en slags sokratisk tilnærming, lærer organisasjonen seg å redusere risiko for at IT-leveranser skal feile. Dette oppnår de ved å blant annet å benytte verdistrømskartlegging, Kanban, flaskehalsanalyse og en rekke teknikker som kokes ned i 3 prinsipper som kalles “The Three Ways of DevOps”.

Verdistrømskartlegging (Value Stream Mapping)

Verdistrømskartlegging er en analysemetode fra Lean Management som handler om å kartlegge hvilke hendelser som skal skje for at en bestilling resulterer i et ferdig produkt. Hensikten med kartleggingen er å først forstå dagens tilstand, for så å planlegge en fremtidig, forbedret variant med mål om å fjerne unødvendig arbeid (reduce waste).

I Phoenix Project bruker helten denne teknikken for å skjønne hvilke personer og systemer som er involvert i alle ledd fra en utviklingsoppgave innen IT påbegynnes til den er rullet ut i produksjon. I tillegg ønsker virksomheten å forstå hvordan IT-tjenestene de tilbyr skaper verdi for forretningen. I denne prosessen kommer virksomheten frem til at store deler av kapasiteten til IT-avdelingen går med på brannslukking og fiksing av bugs, eller det de kaller for ikke-planlagt arbeid, fremfor utvikling av tjenester som har reell forretningsverdi. De utvikler deretter en verdistrøm som tar sikte på å skape verdi og unngå ikke-planlagt arbeid.

Kanban

Kort fortalt er Kanban et system for å organisere arbeid som stammer fra Japan og Taiichi Ohno. Ohno regnes som grunnleggeren av metodikken beskrevet i Toyota Production System (TPS), som er inspirasjonskilden til Lean Manufacturing. Ordet “Kanban”, oversettes til engelsk som “signal card” som jeg velger å oversette til “signalkort” på norsk. Konseptet fra TPS er enkelt nok - et antall signalkort svarer til kapasiteten i et system. Ett kort knyttes sammen med én arbeidsoppgave, og nytt arbeid kan bare påbegynnes når det finnes et ledig kort. Det ledige kortet knyttes til arbeidet som skal utføres, og følger det gjennom verdistrømmen. Når det ikke er flere ledige kort er det heller ikke mulig å starte på nytt arbeid, som resulterer i at nye oppgaver settes i kø. Når en oppgave er fullført returneres kortet og arbeid kan trekkes fra køen og inn i systemet.

Denne mekanismen kjennetegnes som et “pull-system”, som i motsetning til et “push-system” bare tillater nytt arbeid inn i systemet når det finnes ledig kapasitet, fremfor at arbeid dyttes inn i systemet basert på etterspørsel. Pull-systemer har som hensikt å skape et bevisst forhold til kapasitet og forhindre at det kommer til flere oppgaver enn det er ressurser til å håndtere. Dersom kapasiteten i systemet er satt riktig kan det ikke overbelastes.

Det er vanlig at disse kortene vises på tavler, såkalte “Kanban boards”, eller Kanban-tavler på norsk. Når vi snakker om Kanban innenfor smidig systemutvikling bruker vi gjerne virtuelle tavler, og istedenfor at det finnes et antall kort som bestemmer kapasiteten bruker vi kort til å representere arbeidsoppgaver. Kapasitet bestemmes av en grense for pågående arbeid, en “work in progress”-grense (WIP-grense). På en slik tavle er det typisk et antall kolonner, der hver kolonne relateres til oppgavens tilstand. Et klassisk eksempel er en kolonne for “Klar”, en for “Pågående” og en for “Ferdig”. Det er vanlig at en Kanban-tavle inntar den formen som til enhver tid passer best til teamet som bruker den, og gjerne speiler verdistrømmen.

kanban
Figur 1: Eksempel på Kanban-tavle med tre stadier

Flaskehalsanalyse

Dersom man kjenner verdistrømmen og har denne definert i en Kanban-tavle, lar alt arbeid som utføres i verdistrømmen vises som signalkort på tavlen og har en øvre grense for hvor mye arbeid som kan være pågående samtidig har man fått et verktøy som gjør det mulig å finne flaskehalser. Flaskehalsen i et system er det punktet med minst gjennomstrømningskapasitet. Det heter at “optimalisering andre steder enn flaskehalsen er en illusjon”.

Den følgende figuren (Figur 2) viser en Kanban-tavle for systemutvikling, der oppgaver flyter fra “Klar” til “Pågående” og skal innom “Akseptansetest” før oppgaven godkjennes og er “Fullført”. På figuren ser vi at systemets kapasitet er maksimalt utnyttet, fordi alle leddene i verdistrømmen som har begrensning for pågående arbeid (WIP-grense) er fullt utnyttet. Som vi kan se er “Akseptansetest” flaskehalsen i dette systemet slik tilstanden er nå, og det hjelper lite om oppgavene i “Pågående” fullføres. Mer arbeid kan ikke overføres til akseptansetest før det er ledig kapasitet, som fører til at det ikke er mulig å flytte flere oppgaver til “Pågående”.

flaskehals
Figur 2: Flaskehals

First Way

Kort oppsummert handler First Way, “første prinsipp”, om å:

  • Gjøre arbeidet synlig
  • Begrense pågående arbeid (WIP)
  • Redusere størrelsen på arbeidspakker
  • Begrense antall avleveringer
  • Identifisere og utnytte flaskehalser
  • Eliminere tunge prosesser og bortkastet arbeid

Kanban-tavlen bidrar til å synliggjøre planlagt, pågående og fullført arbeid. Når arbeidet er synlig er det enklere å kunne si noe om når en planlagt oppgave sannsynligvis kan leveres, fordi vi enkelt kan måle hvor lang tid oppgaver gjennomsnittlig bruker på å bevege seg fra venstre (klar) til høyre (ferdig). Ideelt sett reflekterer Kanban-tavlen verdistrømmen, det kan gi oss innsikt i hvor oppgaver har en tendens til å hope seg opp.

Når vi setter en begrensning for tillatt pågående arbeid tilrettelegger vi for å lage et pull-system, som fører til at vi ikke tar på oss flere oppgaver enn vi har mulighet til å løse. Noen hevder at det optimale er maks WIP-grense på én enhet, slik at vi har det som kalles “single piece flow”.

Store arbeidsoppgaver tar lengre tid å løse enn små, og når vi opererer med flere aktører som er avhengig av at det er ledig kapasitet, bidrar små arbeidspakker til at flyten blir bedre. Dersom det tar kort tid for en systemutvikler å programmere en oppgave og kort tid å teste den for testeren vil det ta kortere tid før utvikleren får tilbakemelding på om oppgaven er godkjent eller ikke, og utvikleren kan rette eventuelle feil mens oppgaven fortsatt er friskt i minne. Likeledes er det lettere å gjøre code review på tjue linjer kode enn på tusen. I Phoenix Project er dette et virkemiddel som også brukes til å oppnå hyppigere utrullinger til produksjon som har lavere risiko for å feile, som igjen fører til mindre brannslukking og bugfiksing.

I hviskeleken finnes det et forhold mellom antall deltakere og hvor mye av den opprinnelig setningens mening som holder seg gjennom hele runden. I første prinsipp ønsker man å begrense antall avleveringer for å sørge for at kunnskap ikke går tapt på veien fra utvikling til produksjonssetting. Et eksempel som mange sikkert har hørt handler om at utviklere “kaster” ferdig software over en usynlig vegg til driftsavdelingen som må gjøre sitt beste for å skjønne hvordan programvaren skal installeres og vedlikeholdes. Ved at utviklere selv initierer utrulling flyttes noe av ansvaret nærmere dit programvaren opprinnelig kommer fra.

WallOfConfusion_Release
Kasting av software. kilde: dev2ops.org/2010/02/what-is-devops

Når man kjenner til hvor flaskehalsen finnes er det mulig å optimalisere. Om jeg fortsetter på analogien med utviklere og driftsavdelinger, vil en måte å optimalisere på være å nettopp automatisere utrulling til produksjon slik at driftsavdelingen ikke manuelt må utføre arbeid. Dersom utviklingsavdelingen stadig trenger nye kjøremiljøer eller ønsker å gjøre om på eksisterende, vil det være en optimalisering at dette kan ordnes automatisk fremfor at driftsavdelingen manuelt må konfigurere servere. Dersom testing er flaskehalsen er det mulig å se på hvordan testkjøring kan automatiseres. Da jeg forsto dette med flaskehalser skjønte jeg også hvorfor DevOps og automatisering gjerne dukker opp i samme google-søk.

Til slutt tar første prinsipp sikte på å eliminere tunge prosesser og redusere bortkastet arbeid. Dette gjøres ved å anvende alle de foregående punktene, samtidig som man etablerer en kultur som oppfordrer til kontinuerlig forbedring.

Second Way

Der første prinsipp fokuserer på flyten fra høyre til venstre, handler Second Way, “andre prinsipp”, om å sørge for at tilbakemeldinger flyter motsatt vei. Tilbakemelding fra alle ledd av verdistrømmen skal bidra til at feil dukker opp tidligere. Dukker feil opp tidligere er de gjerne mindre, enklere og billigere å reparere, samtidig som konsekvensene er mindre. I tillegg fører tilbakemeldinger med seg læring gjennom delene av organisasjonen som er med i verdistrømmen. Når først uhellet er ute, ses det på som en mulighet for å lære, fremfor at det medfører straff.

I Phoenix Project gjøres flere tiltak for å oppdage feil tidlig, og det er mest fokus på automatisert bygg, test og integrasjon av kildekode. Dersom noen av disse feiler er det tydelig tilbakemelding på at noe ikke stemmer. Prinsippet om at “bygget skal alltid være grønt” baserer seg på at koden som til enhver tid finnes i det delte kildekodesystemet skal bygge uten problemer og passere automatiserte tester. Når feil oppstår er det alles plikt å slippe det de holder på med for å identifisere og fikse feilen. Dette er en teknikk som kalles swarming, og brukes også i Lean Manufacturing, der arbeidere på en arbeidsstasjon gjerne har en fysisk snor de kan dra i om det oppdages feil. Når denne snoren, som kalles en “andon cord”, dras i stoppes hele produksjonen opp og starter ikke før problemet er løst. Dette bidrar til at defekter oppdages tidlig og ikke sendes videre nedover verdistrømmen.

Monitorering av kjøremiljøer trekkes også frem. Informasjonen om produksjonsmiljøets tilstand (ressursbruk, feilrate, responstid osv.) er tilgjengelig for alle interesserte og er med på å bygge tillit i organisasjonen - det er bedre å vise feilene enn å dekke over de.


Third Way

Vi har sett på hvordan arbeid flyter fra venstre til høyre, og hvordan tilbakemeldinger beveger seg motsatt vei. Third Way, “tredje prinsipp”, handler om å skape kultur for kontinuerlig læring og eksperimentering. Når vi som individer hele tiden lærer å bli bedre fører dette til at organisasjonen som helhet også lærer kontinuerlig. At vi ønsker å bli bedre kan virke innlysende, samtidig er det ikke gitt at alle virksomheter har forbedring av måten arbeid gjøres på som en integrert del av kulturen. Det sies at “vi verdsetter daglig arbeid høyt, men vi verdsetter forbedring av daglig arbeid enda høyere”.

Andre prinsipp er så vidt innom at kultur uten skyld er avgjørende for tilbakemeldinger. På samme måte ønsker man at det skal føles trygt å komme med innspill til endringer i eksisterende prosesser. Ikke bare skal det føles trygt, det skal applauderes.

Institusjonaliseringen av forbedring av daglig arbeid stammer også naturligvis fra TPS og er kjent for de som jobber med Lean. Dette er kjernen i det som kalles “kontinuerlig forbedring” på norsk og “Kaizen” på japansk og Leansk (og kanskje etterhvert DevOpsk?). Et annet poeng som gjøres er at læringen som kommer fra daglig forbedring må deles, slik at lokal forbedring blir til læring for hele organisasjonen.

I programvareindustrien er én måte å forbedre daglig arbeid på å betale ned teknisk gjeld. Å ignorere teknisk gjeld trekkes frem i Phoenix Project som en av de sikreste måtene å få mengder av ikke-planlagt arbeid på, fordi det til slutt ikke er rom for å gjøre annet enn å jobbe rundt problemer og kjempe for å avverge katastrofer.

DevOps er mer enn automatisering

Så, fra å si at DevOps er automatisert bygg, test, deploy og monitorering forstår jeg at dette snarere skjer som følge av helt andre ting - at man ønsker å gjøre utvikling av programvare mest mulig forutsigbar, med høyere sannsynlighet for å lykkes første gang man lager noe, at man lærer underveis og bruker det man har lært til å forbedre prosessen. Hvis det ikke kom tydelig frem, så er Phoenix Project er en bok jeg kan anbefale. Den er skrevet av de som kom på DevOps-begrepet.

Hvordan hjalp DevOps-prinsippene på boligsalget?

23stue_preview

Med tankene fulle av single piece flow, små batcher med arbeid og kontinuerlig læring og forbedring var det at jeg ble stilt overfor en litt annen type utfordring. Min samboer og jeg bestemte oss for å selge leiligheten vår. Leiligheten befinner seg på Lambertseter, og bakgrunnen for salget er et ønske om å bo midt i midten av Oslo sentrum før vi blir gamle og/eller får barn som skal vokse opp på økologisk, langsomtvoksende, organisk gressplen uten e-stoffer, beboerparkering og dieselavgift.

Vår erfaring er at det å skulle klargjøre en bolig for salg er en slags reise gjennom de ulike stadiene av sorg, blandet med redsel for alle oppgavene som man utsatte da man flyttet inn fordi man vender seg så fort til ting.

Det var åpenbart at vi trengte et system for å få kontroll og organisere arbeidet som lå foran oss. Valget falt selvsagt på Kanban.

Konseptet med arbeid som beveger seg fra venstre til høyre uten å bevege seg tilbake, med best mulig flyt appellerte til arbeidsoppgaver som ikke primært assosieres med entusiasme og moro. Vi ønsket å få oversikt over alt arbeidet som skulle gjøres og måle progresjon gjennom hele prosjektperioden. Ettersom arbeidet for det mest skulle utføres på kveldstid etter hektiske arbeidsdager passet det også ypperlig å bryte ned alt som skulle gjøres i mindre oppgaver som kunne fullføres på en halv til en time. Så fremfor å “vaske leiligheten” i et jafs delte vi det opp i mindre, konkrete arbeidspakker.

Det er en påstand at det også er et psykologisk element her - det er tilfredsstillende å trekke en oppgave fra klar til pågående til ferdig. Hjernen opplevde belønning med høyere frekvens når denne øvelsen ble gjentatt ofte. (Min universitetsutdannede samboer stilte seg ikke 100% bak denne ikke-vitenskapelige formuleringen).

Vi ble enige om å forsøke å ha lav WIP, helst bare én oppgave hver om gangen. Dette viste seg å være ganske effektivt når det kom til vaskeoppgaver. Jeg kan trekke frem at single piece flow var avgjørende for at vindusvasken ikke lot seg avspore av andre ting som også gjerne skulle hatt vann og såpe-behandling. WIP ble etterhvert utvidet til 3, fordi omkring 50% av husholdningen er istand til å multitaske. 

For å komme i gang med oppgavene, var det første vi gjorde å identifisere noen hovedkategorier for arbeid:

  • Arbeid for å få tak i en megler
  • Arbeid som må være gjort før fotografering
  • Arbeid som må være utført før visning

Deretter laget vi så mange oppgaver vi kunne komme på innenfor de ulike kategoriene og la de opp i en Trello-basert Kanban-tavle. På slutten av en intens lørdag så Kanban-tavlen vår slik ut:

value-stream
Figur 3: Verdistrøm

Vi valgte å gå for en klassisk “Klar, pågående, blokkert, ferdig” verdistrøm der vi brukte farger til å illustrere viktigheten av oppgavene. Viktigheten bestemte vi ut i fra hvilken kategori oppgaven passet til og hvor mye den hastet. I starten var grønn synonymt med “før fotografering” og gul var “før visning”:

Figur 4: Prioriteringer
Figur 4: Prioriteringer

Et bevisst valg vi gjorde var å prioritere oppgaver vi var usikre på hvor lang tid kom til å ta. På den måten økte også vår egen evne til å kunne estimere omfanget av gjenstående arbeid med tiden. Fra vi startet å jobbe til bilder skulle tas hadde vi 10 dager på oss. I løpet av den perioden fikk vi etterhvert så god kontroll at flere av oppgavene som skulle være klare til visning var klare til fotografen kom (mind-blowing, eller hva?)

Det blir umulig å ikke si noe om tillitskultur. I en salgsprosess er det mye tillit som skal settes på prøve. Ens egen tillit til at valget man har tatt er fornuftig, tilliten til at man klarer å gjennomføre, tilliten til at megleren vet hva han driver med og vil ditt beste og tillit til at markedet er villig. I vår “organisasjon” har vi en innarbeidet kultur for høy tillit og god kommunikasjon. Vi tar med oss videre at det ikke var trivielt å innføre konstruktiv kritikk og applaudere at noen rapporterte inn mangler ved utført arbeid.

Feedback-loopen vår baserte seg først og fremst på egen følelse av stress, men også litt på meglere, takstmenn og en hyggelig fotograf som sa det tilhørte skjeldenheten at hun ikke måtte endre på noe av stylingen før foto. Snikskryt mener noen - i DevOps/Lean-prosjekter er det viktig å reflektere over alle typer feedback og ta med seg de seirene man får og parkere janteloven. Avsporing.

Det vil være en overdrivelse å si at vi har hatt høyt fokus på kontinuerlig forbedring underveis. Vi har heller ikke eksperimentert veldig mye. Verdt å merke seg er at Three Ways of DevOps krever en viss modenhet av organisasjonen som implementerer prinsippene. Vi har nok litt å gå på før vi når høyeste modenhetsnivå, men vi har tro på at vi får nye muligheter.

At vi ikke fikk solgt etter første visningsrunde men allikevel fikk positiv respons av interessenter tolker vi dithen at måten vi samlet inn feedback på har rom for forbedring. Vi har også lært at det ikke er alle aspektene ved et salg man rår over, selv om man har Kanban og flotte prinsipper å støtte seg på. Kanskje er det også derfor man har innleid ekspertise til å håndtere de mer merkantile delene av boligsalg - dette er diskusjonstema i neste retrospektiv.

Takk for følget og tålmodigheten

TL;DR

Det er smart å planlegge arbeid som skal utføres, og det å redusere antallet oppgaver som er pågående om gangen bidrar til økt fokus og redusert risiko.

For rent vitenskapelige formål kan sluttresultatet sees her: https://www.finn.no/116706478