Episode 26: Demo

Er du stolt av arbeidet ditt? Viser du det frem så ofte som du burde?

Hei, Martin her, og du lytter til Fimbul!

I følge bokmålsordboka betyr demo en prøve eller en smakebit på en større produksjon, et eksemplar til fremvisning eller demonstrasjon, det vil si en presentasjon, av hvordan noe fungerer eller skal gjøres.

I teknologisammenheng har demo historisk sett blitt brukt i forbindelse med sprint-baserte utviklingsmetodikker som for eksempel Scrum. En sprint starter med en kort planleggingsfase der man blir enige om hva man skal lage, så lager man det, og på slutten av sprinten holder man en demo for å vise frem resultatet.

Gjort feil blir en demo noe man kan grue seg til, eller som man ikke ser verdien av. Hvorfor trenger jeg å bruke tid på å lage en demo? Eller, hvorfor trenger jeg å delta på denne demoen? Du som inviterer til demo har en svært viktig jobb med å styre forventningene til alle som er involvert, både dem som skal vise noe frem og til dem som skal få noe presentert. Det skal være klart for alle hva som er hensikten. Dem du viser noe frem til skal være en relevant forsamling mennesker som primært representerer interessentene, altså dem fra forretningssiden som styrer produkt- og forretningsutviklingen og således er kravstillere, men også dem som skal selge og markedsføre det som er laget så de forstår hva de selger. En demo er også en hyggelig markering for å feire at noe nå er ferdig. Jeg har vært med på demoer fra de korte og enkle på ti minutter, til de store og omfattende med kake og fest! Har du sett en Docker-logo på en kake?

Selv tilhører jeg dem som mener at det å gjennomføre en demo er viktig og nødvendig. Det er viktig ikke bare i sprint-baserte utviklingsmetodikker, men spesielt viktig også i miljøer hvor man jobber med kontinuerlige leveranser uten sprinter.

En demo markerer slutten på ditt arbeid. Det er produktet av det du har jobbet med i en periode, og det du skal vise frem er forhåpentligvis noe du er stolt av. Og hvis du ikke er stolt av det, hvorfor er du ikke det? Ser brukergrensesnittet elendig ut? Er koden strikk og binders? Fungerer ikke det du har laget skikkelig? Går det tregt? Feiler det? Hvis du ikke er stolt av arbeidet ditt vil du kanskje gjøre noe med det, før du viser det frem til en større gruppe mennesker. En demo tvinger frem din yrkesstolthet og kvalitet.

Enten du jobber i sprint-baserte utviklingsmiljøer, eller miljøer med kontinuerlige leveranser, er en demo en viktig indikator på om utviklingsoppgavene eller arbeidsoppgavene er større enn de burde være. Ideelt sett skal utviklingsoppgaver ikke gå over for lang tid. Med en utviklingsoppgave mener jeg et stykke arbeid du kan gjennomføre og ta ut i markedet og som alene vil tilføre ditt produkt ekstra verdi, selv om det kanskje ikke er så mye. Du tar én oppgave som gir litt verdi, og tar den ut i produksjon. Så tar du en ny oppgave og gjør det samme. Og slik fortsetter du. Litt og litt og litt verdi. En demo er en indikator på om du jobber med oppgaver som er for store og som vil ta lang tid før de gir verdi. Og om en oppgave tilfører verdi finner du ikke ut før den faktisk er tilgjengelig i produktet. Store oppgaver vokser eksponensielt i kompleksitet og tidsbruk, derfor er det viktig å dele store oppgaver — såkalte epics — inn i mindre oppgaver som isolert og alene kan settes i produksjon og tas ut i markedet. Raskt, med lav risiko, redusert kompleksitet og tilhørende lav kostnad og tidsbruk. Dersom du jobber på en oppgave hvor du ser at du er i en tilstand der du uke etter uke fortsatt ikke klarer å gjennomføre en demo av det du jobber med, er det en indikator på at oppgaven kan være for stor og det er en erfaring du tar med deg videre for å sikre at senere oppgaver ikke blir like store.

Når du holder en demo skal du ikke bruke et presentasjonsverktøy. Ingen bilder, ingen slides, ingen PowerPoint eller Keynote eller Google Slides. Du skal vise frem det du faktisk har laget. På denne måten blir det synlig for deg selv og andre at det du har laget faktisk er ferdig, at det fungerer som tilsiktet og at alle kan se hvordan det fungerer og komme med eventuelle tilbakemeldinger. Vis det frem, enten du viser et brukergrensesnitt i programvaren, eller om det er kode fordi det du har laget ikke har et brukergrensesnitt, eller hardware dersom det er det du lager. Fortell hva som skjer. Det du viser frem trenger ikke å være i produksjonsmiljøet, men det må være i en tilstand der du kan ta det fra utvikling eller test og til produksjon i løpet av timer eller få dager. Men vil du ha rockestjernestatus så sier du at «dette ligger allerede i produksjon», da forteller du dem som hører på at du allerede har levert fra deg noe som gir verdi.

En annen viktig grunn til å holde demo er at det kanskje ikke er like tydelig for hele organisasjonen hvem som jobber med hva. «Åh, driver de med det NÅ? Da må vi kjappe oss og bli ferdige med det vi driver med her hos oss!»

Du som inviterer til demo skal være tydelig overfor alle som deltar at en demo er et sted hvor man viser frem resultatet av den siste tids arbeid, og at det ikke er en arena for prioritering av videreutvikling eller ny funksjonalitet. I en demo vil man ha innspill knyttet til det som er laget, som tips til forbedringer eller innspill man kanskje ikke har tenkt på. Innspillene tar man med seg til teamet og diskuterer dem der. Akkurat dette er viktig, for hva gjør du hvis konsernsjefen gir deg et innspill som kanskje er et dårlig innspill? Ikke alle ideer er gode, og ikke alle tilbakemeldinger skal hensyntas.

Du som viser frem det du har laget må som nevnt være trygg på at det du har laget er av tilnærmet produksjonskvalitet. Du skal være trygg på hvordan det du har laget fungerer og du må kunne snakke overbevisende om hvilken verdi det du har laget tilfører produktet. Vis det frem, uten for mange detaljer. Ideelt sett krever en demo minimalt med forberedelser, fordi dem som viser det frem allerede er så inne i materien at få forberedelser er påkrevd. Hold demo ofte nok, så holdes også skuldrene lave. Hvor ofte avhenger av hva du lager. Tar det deg i snitt tre uker å bygge verdiskapende funksjoner, så holder du demo hver tredje uke.

Hvis du velger å IKKE avholde demoer kan det lett avstedkomme usikkerhet andre steder i organisasjonen. Når kommer funksjon X? Hvor lang tid skal de egentlig bruke på funksjon Y? Hva driver de egentlig med nede i team Z? Går det ikke tregt med team N? Demo bidrar til å holde skuldrene lave og opprettholde tillit på tvers av organisasjonen. Men pass samtidig på at demoen som nevnt ikke blir en kollokviegruppe av mennesker som ikke trenger å være der.

Trenger du hjelp til å orkestrere arbeidet hos din arbeidsgiver, så kan jeg hjelpe deg med det. Jeg har lang erfaring med smidige arbeidsmetodikker og det å arrangere demoer. Kontakt meg på telefon 93055510 eller nivlheim.no.

Men nå trenger jeg DIN hjelp! Jeg trenger hjelp til å dele erfaringene i Fimbul. Jeg trenger DIN hjelp til å dele Fimbul med minst én venn! Én venn hvor du tenker: «Dette tror jeg du vil ha nytte av!» Be dem om å besøke fimbul.tech.

Tusen takk for at du lytter til Fimbul, og for at du deler! Vi høres!