Mer smidig? del 1: Kort feedback loop

Vil du bli mer smidig? da er det mange steder man kan starte. Helt sentralt står det å ha en så kort feedback loop som mulig:

Kort feedback loop vil jeg påstå at faller seg veldig naturlig for ingeniører! Det er ikke vanskelig å få med seg de flinke fagpersonene som faktisk utvikler systemer på dette, her er det de som går foran og som har gjort det lenge. Selv jeg som ikke lærte test drevet utvikling på skolen, fikk fra første stund tilbakemeldinger fra kompilatoren. Og vi ønsker oss tilbakemeldinger fra testene våre så raskt som mulig. Enhetstester, integrasjonstester og automatiserte funksjonelle tester. Disse kjøres så ofte vi kan, og vi jobber for at vi nettopp kan gjøre dette så tidlig som overhodet mulig.

Tommel opp!

Font Awesome by Dave Gandy

En kort feedback loop, hva betyr egentlig det? Jo det betyr rett og slett at vi ser resultatet av det vi gjør raskt! Og forretningssiden er ofte utolmodige for å få ut sine ideer til sluttbrukerne, sånn sett er det heller ikke vanskelig å selge inn ideen til forretningssiden om at vi skal levere verdi til ekte kunder så raskt som overhode mulig. 

Flere tomler opp!!

Font Awesome by Dave Gandy

Men: Mange ingeniører og forretningsfolk krymper seg likevel når de tenker på å release noe tidlig (når de får tenkt litt på det). For, det er jo ikke ferdig. 

Jeg vil påstå at de aller fleste vil mye å tjene på å virkelig jobbe med å få en kortere feedback loop og muligheter for å release til ekte kunder tidlig.

Picture: Jeff Patton

 Det er nødvendig å jobbe med dette både med medarbeidere som representerer  forretning og teknologi. Og hva får du for å korte ned feedback loopen? Jo du får muligheten til å treffe blink! Og ikke bare det, du treffer også rett blink!! Du får tilbakemelding på hva som virkelig fungerer og ikke, og du får en nærhet til kunden og produktet som faktisk lages som er fantastisk og veldig motiverende. Du får et fokus på de rette tingene, og det gir en enorm motivasjon og fart.

Spørsmålet er hvordan få det til: og svaret på det vil være forskjellig fra bedrift til bedrift og fra team til team. Likevel tenker jeg at dette ofte vil gjelde:

  

·         1: Tester: Hva gjøres i dag? Hva kan gjøres med automatiserte tester? Er det unødvendig overlapp i de automatiserte testene? Kjøres de automatiserte testene ofte nok? Kan det gjøres noe for å kjøre testene med riktige intervaller og å redusere tiden de tar å kjøre? Følger teamet med på testene? Kan teamet stole på testresultatene? Er det riktig nivå av automatisert testdekning?

Jeg har flere ganger fått spørsmålet: tar det ikke uforholdsmessig lang tid å levere et prosjekt dersom man skal lage alle de automatiserte testene? 

Til dette vil jeg helt klart si "nei". (Aller helst "leverer viikke et prosjekt", men en serie av funksjonalitet ved hjelp av hyppige releaser og continous delivery, men dette blir en digresjon akkurat her). 

Automatiserte tester gjør heller det motsatte: vi får mer testing og oftere testing. Dette igjen gjør oss trygge! vi vet at vi ikke brekker noe eller introduserer nye bugs eller regresjoner (ukjente side-effekter ved introduksjon av ny funksjonalitet). 

Hver gang vi gjør endringer i kode som har dårlig test-dekning, da vet vi at dette er risikofylt og  tar ekstra tid. Å skrive selve programmerings-koden tar ikke ekstra tid, men tiden fra vi bestemmer oss for å implementere funksjonalitet til det er klart for produksjon, det er denne tiden som blir lenger, spesielt i kalendertid. Men ikke bare i kalendertid, også i tid for avbrytelser, forstyrrelser og feilsøking i flere uker fremmover etter at endringene er gjort.

·         2: Backlog/Minimum viable product (MVP): Hva er det absoultt minste som det er mulig å få released? Det vil si det tidligste tidspunktet det kan gi bare bittelitt verdi å levere til en ekte sluttkunde? –Dette høres kanskje lett ut, men når svaret kommer, hvordan kan du skrelle bort enda mer? Og enda mer? Og enda mer? Gå gjennom hver eneste feature, og spør deg selv: er dette en showstopper? Ja eller nei? Hvis du bare skulle velge en eneste feature, hva hadde du levert da? En endeløs backlog (eller enda værre: kravspek fra tre år tilbake på tusen sider), er waste.  

·         3: Releaser: Den hele verdikjeden blir først testet ut når vi releaser. 

Mitt store forbilde er Mary Poppendieck, hennes bøker er vel verdt å lese, og jeg har også vært så heldig at jeg har truffet henne flere ganger. Hun har et utrolig godt bilde på hva som skjer ved kort feedback loop: Hvis du ser for deg at prosjektet er et vann eller en elv, så vil det under overflaten være gjemt mye som man ikke ser. Når man releaser ofte senker man vannstanden, slik at problemene kommer til syne, akkurat som steiner under vannet. Jo mer vann man fjerner, jo mer kommer tilsyne av utfordringer, og man kan håndtere dem og skape bedre flyt. (En variant av "å feie noe under teppet")

Bildet er lånt av fotografen: http://kjiver.no/index.htm

Og hvis sluttkunden ikke er interessert i å få en release hver time, hvem er det som er interessert? Begynn med å release til dem! Få en krets av «early adoptors» først internt, deretter eksternt. Kjør alpha og beta programmer. Og hvis det finnes definisjoner internt med kriterier som må oppfylles for å kunne gjøre dette, så finn på noe lurt: kall det for pre-Alpha og pre-Beta. I slike termer kan du legge det du vil (og det skal føles litt ukomfortabelt for alle i prosjektet, dere venner dere til det :)

I realiteten krever dette en hel del. Hvorfor?

Når du senker vannstanden får du rett i fleisen alle de tingene som ikke fungerer. Og alle de tingene som fungerer dårlig. Og alle de tingene som ikke er på plass som burde vært det. Heldigvis får du også alle de tingene som du ikke visste om, som du får mulighet til å gjøre noe med på et veldig tidlig tidspunkt. Alle de andre vanskelige, kjedelige tingene som faktisk var kjent, men ikke løst, var uløste for en grunn og disse årsakene er ikke borte.

På toppen av det hele må prosjektet levere også, ikke bare lage verktøy og fikse tester eller gjøre andre løft for hygienefaktoren. Og det som må til for å kunne release ofte krever en god del å få på plass. Og forretningssiden og alle som har et eierskap til sluttproduktet er ikke så interessert i å forsinke prosjektet, kanskje ønsker dere å være tidlig ute med noe nytt og spennende, eller dere må ta igjen konkurrenter, dere må kapre nye kunder, eller levere det de eksisterende kundene krever. Og utviklerne, de har noen skjelett i skapet som de ikke gleder seg til å ta ut.... 

Så da er det bare å innse at «Rom ikke ble bygget på en dag»:

Bildet er lånt fra: commons.wikimedia.org

Ta de letteste tingene/viktigste først, lage noen milepæler som er realistiske å nå, og ta det videre derfra. Men vær klar over at ingenting skjer av seg selv. Det er som med all endringsledelse. Det krever minst en som driver prosessen, denne må ha en kritisk masse av supportere, teamet eller organisasjonen må kjøpe ideen. Man må være på hugget,  kassere inn de første seirene, og håntere alle setbacks. Og set-backsene vil komme, spesielt siden dette er laget for å synliggjøre alt som er vanskelig, utfordrende og til hinder for hyppige releaser.

Vaner må endres, og teamet (og kanskje bedriften også) må og pushe seg selv ut av komfort-sonen og det som føles som "trygt". Sannheten er at det aller tryggeste man kan gjøre er å release ofte, det gi en mulighet til å omfavne usikkerhet som allerede finnes, og som ikke lenger skyves under teppet. Det er mer komfortabelt å levere noe som er «ferdig». Men det kan man venne seg av med  :)