Episode 4: Fra vannfall til smidig

Det snakkes om agile prosesser. Om DevOps, om scrum, om XP og Kanban og hva vet jeg. Fellesnevneren kaller vi smidig. Men hva er egentlig smidig og hvordan blir man det?

Hei, Martin her, og du lytter til Fimbul!

Man kan knapt gå på en teknologikonferanse i dag uten at det snakkes om buzz-ord som alle er variasjoner over det samme temaet: smidig. Ord som scrum, kanban, XP, lean og mye annet er gjengangere.

Når jeg selv holder foredrag og deler mine erfaringer, er et av de vanligste spørsmålene jeg får hvordan blir man egentlig smidig?

Det finnes ikke noe kort og enkelt svar, fordi det ikke finnes noe slikt som en standardisert bedrift. Ingen bedrifter er like, ingen behov er like, ingen ansatte er like. Allikevel vil jeg trekke frem noen punkter jeg mener er sentrale i hvordan man beveger seg fra en vannfallsprosess til å bli smidig.

Aller først vil jeg snakke om hva som kjennetegner en vannfallsprosess, som er motstykket til smidig. Kjenner du deg igjen i hele eller deler av beskrivelsen, er sannsynligheten stor for at du arbeider i en slik prosess.

En vannfallsprosess er, enkelt forklart, drevet av langtidsplaner, typisk med en horisont på minst et kvartal, altså tre måneder, men ofte ser man årsplaner. Det kommende året kunne vi tenke oss å lage følgende funksjonalitet. Dernest fordeles funksjonaliteten ut i tid, før den estimeres og settes opp i et diagram som viser hvilken funksjonalitet som lages i hvilken rekkefølge det kommende året. Det ser bra ut og er perfekt å presentere for ledelsen på en PowerPoint. Dette har man kontroll på. I hvert fall tilsynelatende.

Så har man releaser. En release vil si prosessen med å ta funksjonalitet man har laget ferdig og gjøre den tilgjengelig i produksjonsmiljøet for ekte brukere og ekte kunder. I en typisk vannfallsprosess har man månedlige eller kvartalsvise releaser. Det vil si at estimatene til funksjonaliteten man ønsker å lage må passe inn i releaseplanene, for releaseplanene er ofte forhåndsbestemt. Har du tre funksjoner som til sammen tar fire måneder å lage? Synd for deg, da blir det bare to dette kvartalet og den siste må vente til neste release.

Min beskrivelse av vannfall er selvfølgelig noe overdrevet, men teorien og eksemplene med planer og releaser og estimater er reelle. Jeg har selv jobbet i slike prosjekter, og jeg vet at det fortsatt praktiseres mange steder.

Smidig, derimot, er nesten alt det vannfall ikke er. Hvis du spør meg om hvilken funksjonalitet vi tenker å lage i løpet av året, så vil jeg se på deg med et rart ansikt. Jeg har ingen anelse. De neste to-tre månedene? Ja! Men det neste året? Nei! Jeg vet ikke. Jeg vet ikke fordi verden endrer seg så raskt. Kundenes behov endrer seg og eventuelle langtidsplaner jeg måtte ha lagt vil være utdatert straks et behov endrer seg. For meg er det langt viktigere å kunne tilpasse seg endrede markedsbehov raskt, enn å kunne svare på hva vi tenker å gjøre det neste året.

Smidig tar utgangspunkt i dem som skal bruke det du lager. Hvem er kunden? Hvem skal bruke det fra dag til dag? Reelle behov kartlegges og prioriteres fremfor konstruerte behov og planer.

Fordelene med smidig er mange. Man løser ekte menneskers reelle problemer. Man leverer litt og litt verdi til disse menneskene fortløpende, i stedet for å samle dem opp og gi dem (for) mye på én gang. De får en jevn strøm av tilført verdi.

En jevn strøm av tilført verdi betyr en jevn strøm av ny funksjonalitet, for eksempel ukentlig eller daglig. Og en jevn strøm av ny funksjonalitet betyr naturlig nok mindre releaser. Og mindre releaser betyr mindre kode og mindre kode betyr mindre som kan gå galt og dermed får man også mer kontroll.

Hyppige releaser har også en positiv effekt ved at release ikke er en vanskelig prosess. Release daglig blir rutine. Release kvartalsvis er stress og nattarbeid i helgen. Alt man gjør hyppig blir rutine og gir dermed redusert risiko for at noe går galt.

En jevn strøm av tilført verdi gjør det også mulig å endre kursen raskt ved behov. Eventuelle endringer i kundenes behov kan gjennomføres raskt, i stedet for å vente til neste planleggingsrunde.

Smidig gir også fornøyde ansatte. Ingen liker å lage funksjonalitet som ikke blir tilgjengelig før en gang i fremtiden. Alle liker å kunne jobbe med én ting, ta det ut i produksjon og teste det sammen med dem som skal bruke det, og forbedre det fortløpende til det er blitt bra.

Så tilbake til spørsmålet: hvordan går man egentlig fra å drive vannfall til å bli smidig? Det finnes som nevnt ikke noe kort og enkelt svar, men jeg skal nevne noen sentrale punkter jeg mener er viktig.

Det første jeg vil trekke frem er at man ikke bør forsøke å endre hele prosessen på én gang. Gjør ett tiltak. Få det til å fungere. Gjør så et nytt tiltak. Og gjenta. Smidig handler om kontinuerlig forbedring og ikke om prosessen.

Det aller første jeg ville startet med er å stille alle som utvikler og drifter løsningen hva som skal til for å release dobbelt så ofte som vi gjør i dag. Releaser vi hvert kvartal? Hva skal til for å release månedlig? Releaser vi hver måned? Hva skal til for å release annenhver uke? Eller hver uke? Releaser vi hver uke? Hva skal til for å release daglig? Eller flere ganger daglig? Start med å release dobbelt så ofte som du gjør i dag, og få det til å fungere. Så gjentar du prosessen. Gjennom å fokusere på utfallet av en release, altså å gjøre funksjonalitet tilgjengelig for folk, tvinger det seg gjennom denne prosessen også frem metoder og verktøy og teknikker vi kjenner fra smidig.

Det andre jeg vil trekke frem er behovet for å få strukturert hjelp når man skal release dobbelt så ofte. Ganske tidlig vil man se at dagens prosess med planlegging og estimering ikke passer med det å release ofte.

Med strukturert hjelp mener jeg noen fellesnevnere dine ansatte enten er kjent med fra før eller har hørt om fra andre. Et godt sted å starte er med den velkjente prosjektmetodikken scrum. Jeg har ofte kalt scrum for en avrusningsmetodikk, som et humoristisk poeng for å understreke bistanden scrum kan gi når man beveger seg vekk fra vannfall. Scrum er smidig (ish), men samtidig har scrum kjente elementer som planleggingsfaser, frister, estimater og periodiske releaser. Mange av artefaktene er således kjent for dem som skal jobbe med det, og det gir et godt utgangspunkt for å bli enda mer smidig.

Etterhvert som man har fått taket på scrum, vil man oppleve at man befinner seg i en tilstand hvor man har hyppige releaser, men ikke så hyppig som man kunne ønske seg. Typisk releaser man en gang i uken eller annenhver uke, fordi dem som utvikler løsningen ikke er dem som releaser den til produksjon og skal drifte den.

På et eller annet tidspunkt må ansvaret for releaser overføres fra dem som drifter løsningen til dem som utvikler den. Drifterne må bli utviklere, eller omvendt. Dette er det mye omtalte buzz-ordet DevOps — Developers and Operations. Drift og utvikling sitter sammen og skillet mellom ansvar og oppgaver viskes vekk.

I dag jobber jeg et sted hvor vi har fire utviklingsteam. Det er lenge siden jeg gadd å telle antall releaser per dag, men da jeg talte var det 10-15 releaser til produksjon hver dag. I dag betrakter jeg det mer som en sakteflytende elv. Sakte men sikkert kommer det kontinuerlig små og store leveranser flytende forbi, og gjør det ikke det må jeg finne ut hvorfor og fikse det. Kontinuerlige leveranser kalles tilstanden, et annet kjent buzz-ord.

Mellom vannfall og scrum og DevOps og kontinuerlige leveranser finnes det andre verktøy og metoder å støtte seg på. For meg er aldri verktøyet eller metoden viktig, det viktige er hva vi løser med det. Ellers går man seg til slutt vill i begreper som WIP og CONWIP og just-in-time og hva vet jeg. Ikke gjør det for vanskelig, alle må forstå prosessen.

Et av verktøyene jeg vil trekke frem heter Kanban. Noen snakker om det som en prosess, men jeg betrakter det mer som et verktøy. Et latterlig enkelt verktøy for å merke arbeid som skal gjøres og følge det fra det oppstår til det er tilgjengelig for dem som skal bruke det du har laget. Kanban er japansk og betyr kort og godt «kort», som i et kort eller en lapp, eller «tegn» eller «signal». Opphavet kommer fra produksjonen hos Toyota på 1970-tallet og kortet det refereres til ble benyttet til å følge bildeler gjennom produksjonen til den endelige bilen var ferdig.

Konseptet er latterlig enkelt. Forestill deg en tavle hvor du tegner tre vertikale kolonner. I den første kolonnen plasserer du post-it-lapper med arbeid som skal gjøres i prioritert rekkefølge. I den andre kolonnen plasserer du lapper som er under arbeid. Og i den tredje kolonnen plasserer du det som er ferdig og produksjonssatt. Ingenting er ferdig før det er i produksjon!

Deretter gir prosessen nesten seg selv. Man arbeider kun på én oppgave om gangen og gjør den ferdig, før man starter på en ny. Kanban er således pull-basert, det vil si at ingen oppgaver påbegynnes før oppgaven foran i køen er ferdig. Så enkelt, så vanskelig. Motsetningen til pull-basert er push-basert, og er det man finner i vannfall. Man planlegger hva som skal inn i neste release eller gjøres det neste året, så pusher man det på teamet som skal lage det, med all frustrasjonen og stresset som følger med et slikt push. Selv elsker jeg Kanban og jeg bruker det til alt for komme igjennom julestria til å flytte eller planlegge ukesmenyen i familien. Eksempler på dette finner du på mitt nettsted bekkelund.net og søke etter Kanban.

Å være prosjektleder eller produkteier i et smidig miljø med Kanban som verktøy krever en slags mental tilstand hvor man aksepterer at ting blir ferdig når det blir ferdig. Spørsmålet «når blir dette ferdig?» bør man kun stille når det faktisk er noe man må rekke, hvis det er en reell frist. På den annen side er det viktig at man ikke havner i en tilstand hvor man aldri blir ferdig. Godt nok er godt nok, som vi snakket om i forrige episode om teknisk gjeld. I stedet for å spørre «når blir dette ferdig?» kan du heller spørre «hva kan du ha ferdig på fredag?». Da reduserer du omfanget av arbeidet og ikke minst stresset. Mindre oppgaver og fokus på resultatet.

En annen artefakt som kan være omdiskutert er demoer. Å vise frem det man har laget. En demo kan føles som en påtvunget oppgave, og ikke noe som er direkte relatert til selve utviklingen av det man skal lage. Det kan løses med forventningsstyring. En demo skal ikke være en påtvunget oppgave, men en del av prosessen hvor man stolt viser frem det man har laget. Klarer man ikke vise frem det man har jobbet med for eksempel en gang i uken eller annenhver uke, kan det hende oppgavene er for store og flyten for dårlig, og man bør se på underliggende årsaker til hvorfor man ikke er i stand til å vise frem det man lager.

Andre artefakter jeg vil trekke frem finner man i metodikken kalt XP. Extreme Programming. Selv om XP ikke er like nytt og fancy som DevOps eller kontinuerlige leveranser, har det en del aktiviteter knyttet til seg som jeg synes er verdifulle under arbeidet med å utvikle programvare. Parprogrammering, altså at to utviklere løser en oppgave sammen. Enhetstester, at utviklerne skriver automatiske tester av det man lager. Akseptansetester, at det som er laget møter forventningene. Standups, at man hjelper hverandre med oppgaver og fremdrift. Kundekontakt, at man faktisk tester ut det man lager på ekte kunder og brukere. Jeg anbefaler en titt på XP og plukke det som passer og se hvordan det fungerer i kombinasjon med Kanban som verktøy.

Før du vet ordet av det planlegger du julen og neste ukes middager i Trello.

Men husk: start i det små og gjør kontinuerlig forbedring.

Tusen takk for at du lytter til Fimbul, vi høres!