Smidig utvikler

Og med å være smidig mener jeg primært:

• Ha muligheten til å fokusere på en ting av gangen, slik at jeg slipper å forholde meg til mange forskjellige kontekster samtidig, men kan danne meg et helhetlig bilde av det jeg skal lage, og kan konsentrere meg om å få en ting helt ferdig.
• Ha muligheten til å få tilbakemelding på alt jeg gjør så tidlig som mulig, slik at jeg kan endre min forståelse av problemet, eller endre hva jeg lager, eller endre hvordan jeg lager det.

Problemet er: Det er mye ved måten vi jobber på som gjør at jeg ikke føler meg spesielt smidig. Det er for mye friksjon og hindringer. Og det er ikke min skyld! Eller, er det det? Kan jeg gjøre noe med det?

Opprinnelsen til begrepet smidig

Først litt historikk. Begrepet smidig i vår industri har sin opprinnelse i Manifestet for smidig programvareutvikling. Det ble skrevet i 2001 av 17 teknologer. Det består av 4 hovedpunkter og 12 prinsipper. Hovedpunktene er:

• Personer og samspill fremfor prosesser og verktøy
• Programvare som virker fremfor omfattende dokumentasjon
• Samarbeid med kunden fremfor kontraktsforhandlinger
• Å reagere på endringer fremfor å følge en plan

Det inneholder ikke noe som sier at man skal bruke spesielle metoder, rammeverk eller verktøy!

Smidig er død

Tre av personene som utformet manifestet for smidig programvareutvikling har aktivt gått ut og erklært smidig for død:

• Ron Jeffries har en artikkel som heter “Developers Should Abandon Agile” (2018). 
• Dave Thomas har et foredrag om det samme temaet: "Agile is Dead" (video fra 2015). 
• Robert C. Martin har også et foredrag om temaet: "The Land that Scrum Forgot" (video fra 2011).

Mitt inntrykk er at såkalte “smidige” rammeverk er laget primært for å tjene penger. Selge kurs, konferanser, bøker og sertifiseringer. Jeg tror også mange føler at de ikke jobber særlig smidig selv om de følger rammeverket til punkt og prikke.

Friksjon og hindringer

Som nevnt så opplever jeg ofte friksjon som hindrer meg i å være smidig.

Vi ønsker å fjerne mest mulig friksjon i utviklingsprosessen. Det høres ut som en selvfølge. Og med det tenker man ofte på å automatisere unødvendige steg. For eksempel å automatisere bygging og installasjon av en ny versjon.

Men det rare er at vi har elementer i utviklingsprosessen som vi ikke ser på som friksjon, men som jeg opplever som hindringer.

Et eksempel er kodegjennomganger. Kodegjennomgang i form av en “Pull Request” i et kodearkiv. Hvor kodegjennomgangen skjer skriftlig og asynkront. Dette fører ofte til at man må vente på at noen gjør kodegjennomgang. I mellomtiden er det lett å starte på en ny oppgave, og bytte kontekst. Det er mentalt kostbart.

Et annet eksempel er det overveldende fokuset på fart. Vi er indoktrinert med idéen om at det det å gjøre mange ting i parallell gir fart. Og at forskjellige personer skal gjøre hver sin lille del av oppgaven. Men det fører ofte til overlevering og hopping mellom oppgaver. Med risiko for misforståelser og kostbar bytting av kontekst som resultat.

Det siste eksemplet handler om industrien som forventer 100% utnyttelsesgrad av sine “ressurser”. Alle skal være produktive, det vil si skrive kode, hele tiden. Dette er ikke bra. Vi trenger slakk for å kunne skifte modus fra problemløsning til refleksjon. Å se mer helhetlig på løsningen vi lager. Vurdere hele konteksten. Lager vi riktig ting? Har vi laget tingen på riktig måte? Hvor mange ganger har du stått i dusjen eller gått tur og kommet på at løsningen du har laget har en feil eller en mangel, eller faktisk er feil løsning på problemet? Når vi mister muligheten til å reflektere over det vi utvikler, vil det det ofte føre til at en feil eller mangel må rettes opp, lenge etter at løsningen har kommet i produksjon. Og det er kostbart. Av og til veldig kostbart.

Hva kan du gjøre?

Sett at du er i et team som jobber etter en “smidig” metode, men du føler ikke at du jobber spesielt smidig. Du opplever stadig friksjon. Hva kan du gjøre? Her er tips til noen grep du kan ta initiativ til.

Les manifestet for smidig programvareutvikling

Hovedpunktene og prinsippene i Manifestet for smidig programvareutvikling er kilden til begrepet smidig i vår industri. Les dem (eventuelt på nytt), og ta dem på alvor. Du trenger ikke kurs eller sertifisering for å gjøre det.

Fokus og tilbakemelding

Jeg mener det vi trenger aller mest er to ting: Fokus og tilbakemelding.

Fokus er det motsatte av å bytte mellom oppgaver: Ett fokus til løsningen er i produksjon. Hvis det oppstår ventetid, har man en god anledning til å tenke gjennom helheten i løsningen, eller gjøre forberedelser til den kommer i produksjon: Er det noe som bør dokumenteres? Trenger man å lage spørringer eller alarmer for å overvåke løsningen? Må man oppdatere tekniske tester?

Tilbakemelding trenger vi på alle trinn i utviklingsprosessen. Og prosessen starter lenge før kodingen starter. Tilbakemelding vil vi ha så tidlig som mulig i utviklingsprosessen. For eksempel tilbakemelding på at vi har forstått et problem riktig (fra de som eier problemet), eller at løsningen vi har valgt er god (fra en annen utvikler eller tester). Det gjøres best i sanntid, ansikt til ansikt, ikke gjennom kravspesifikasjoner eller oppgaver i et oppgaveverktøy.

Ikke fokuser på fart

Merk at jeg ikke sier “Sett ned farten”. Fart kan komme som et resultat av at man jobber smidig, men bør ikke være det primære målet. At man går i riktig retning er viktigere. Og programvare som virker er målet, ikke å få den fortest mulig ferdig. 

Kevlin Henney har foredraget "Agility ≠ Speed" (video fra 2018) om dette temaet. Og skrevet en artikkel (2021) med samme navn. En tankevekkende analogi/gåte fra foredraget: “Why do cars have brakes?”. Svaret kan overraske deg. Både “Cars have brakes so you can slow down” og “Cars have brakes so you can go fast” kan være riktig.

Begrens mengden “under arbeid”

Å sette en grense på antall oppgaver under arbeid er ett enkelt grep. Men det forutsetter at teamet faktisk overholder grensen. Det er erfaringsvis vanskelig. 

Grensen for “under arbeid" er totalt antall oppgaver som jobbes med i teamet uansett status (for eksempel utforsking av problem, under utvikling, til gjennomgang, til test, klart til installasjon, osv). Hvis man liker å jobbe sammen i par, kan grensen være halvparten av antall teammedlemmer. Da vil hvert par ha ett fokus inntil det de utvikler er i produksjon.

Poenget med dette er å forhindre bytting mellom for mange oppgaver. Og at man gjør helt ferdig én og én oppgave av gangen. Ikke ha masse halvferdige løsninger når det er tid for å installere en ny versjon. Kan også oppsummeres som “Stop starting, start finishing”.

En annen fordel med å begrense mengden “under arbeid” er at man kan levere (deler av) programvaren tidligere, men ikke nødvendigvis (alt) fortere. Se figuren under.

Gjør mindre endringer av gangen

Gjør mindre endringer i kodebasen av gangen. Bygg og installer en ny versjon i produksjon. Evaluér resultatet og juster kursen. 

Egentlig det samme som Dave Thomas sier i foredraget sitt, "Agile is Dead" (2015):

1. Finn ut hvor du er
2. Ta et lite steg videre mot målet
3. Juster din forståelse (av hva du skal lage) basert på hva du har lært
4. Repetér

Les også gjerne artikkelserien “Many Much More Smaller Steps” (2021) av GeePaw Hill.

Fordelen med å gjøre mindre endringer av gangen er mindre risiko og tidligere produksjonssetting. Som igjen gir tidligere tilbakemelding på at det vi lager er riktig.

Unngå asynkron kodegjennomgang

I Open Source-miljøet, hvor “Pull Request” er populært, har man i utgangspunktet ikke tillit til de som bidrar. Man kjenner dem ikke, og har behov for kontroll på hva som kommer inn i kildekoden.

I et team som jobber tett sammen er det dumt å ha mistillit som utgangspunkt for å samarbeide. I stedet er tillit i kombinasjon med ansvar et bedre fundament for effektivt lagarbeid. Det betyr ikke at man aldri gjør kodegjennomgang, av og til er det nødvendig. For eksempel hvis det er store endringer (noe som imidlertid ikke er spesielt smidig) eller hvis man har en ny person på teamet.

Å unngå forsinket tilbakemelding på kodegjennomganger kan gjøres på flere måter, for eksempel:

• Flette inn små endringer som er godt testet med automatiske tester, uten kodegjennomgang (baserer seg på tillit).
• Skrive koden sammen (baserer seg på synkront samarbeid).
• Gjøre kodegjennomgang etter at koden er flettet inn på hovedgreina, men før den er installert i produksjon (baserer seg på ansvar).

Se også artikkelen Ship/Show/Ask (2021) av Rouan Wilsenach.

Avsluttende ord

Utvikling av programvare er en sosial aktivitet. Ikke en fabrikk med samlebånd, hvor hver enkelt gjør en liten del av oppgaven. Utvikling av programvare krever samarbeid. Kontinuerlig og i sanntid.

Men i programvareindustrien er det ikke alltid vanlig med samarbeid i sanntid. Kodegjennomganger, bestillinger og skriftlig overlevering mellom de forskjellige fagområdene er ofte normen. Alt dette skjer asynkron, med venting, lang tid før tilbakemelding og fare for misforståelser. Og det gjør at man hopper mellom oppgaver, noe som krever en god del mental innsats. Mental innsats som kunne vært benyttet på en bedre måte.

For eksempel til å lage programvare som virker.