I denne serie, ser vi nærmere på hypotese-drevet udvikling som en manglende brik i det agile puslespil. Hvad er hypotese-drevet udvikling? Hvorfor er det overhoved relevant? Og hvad kan i som organisation, få ud af at arbejde med hypoteser? Min hypotese er, når du har læst denne serie, er du klogere på alt dette og meget mere.
Læs også følgende i serien:
– Hypotese-drevet udvikling og dit agile mindset
– Hypotese-drevet udvikling og psykologisk sikkerhed
I følger Scrum, SAFe eller et andet rammeværk. Alle krav og ønsker er grundigt dokumenteret i User Stories og I kører jeres events efter bogen – alligevel virker det ikke som om det har ændret det store.
Forstå mig ret, det virker som om I leverer hurtigere nu, hvor I har en fast kadence på 2 uger, men I er ikke sikre på om I rent faktisk er blevet bedre til at levere det kunden virkelig-virkelig gerne vil have… og det er i øvrigt stadig ”forretningen” der føder jer med krav og viden om hvad kunderne i virkeligheden vil have.
Hvis du kan relatere til ovenstående scenarie, er der en risiko for, at det empiriske og evidensbaserede mindset, er gået jer forbi – og at i reelt set blot har installeret nogle agile rammeværker, roller og events, men langt hen ad vejen har bevaret de traditionelle governance- og beslutningsstrukturer. Der er en risiko for, at I ikke skaber ny viden om, hvad kunderne virkelig vil have og derfor ofte er et skridt bagud – Med andre ord, I eksperimenterer ikke.
Vi eksperimenterer tidligt og ofte, for vi kan ikke regne den ud på forhånd – det kan I heller ikke.
Vi har alle forskellige forestillinger om hvad der er virkeligt og sandt – antagelser. I regi af produktudvikling kan antagelser tage mange forskellige former. Vi kan have antagelser om:
- Hvad brugerne vil have
- Hvad brugerne vil betale for og hvor meget
- Hvordan vi bedst håndterer den nye lovgivning
- Hvilken teknisk løsning der er mest optimal
- Hvordan vi arbejder bedst sammen som et team
- Hvordan vi organiserer os bedst, for at levere mest mulig værdi
Pointen er, vi ved det ikke før vi har testet vores antagelse af. Agile rammeværker har forskellige måder at italesætte dette på:
- “ We learn rapidly by experimenting frequently ” – Modern Agile
- ” Improve collaboratively, evolve experimentally ” – Kanban
- ” Pivoting… a structured course correction designed to test… hypothesis about the product, strategy and engine of growth ” – Lean Startup
- “ Empiricism asserts that knowledge comes from experience and making decisions based on what is known ” – Scrum Guide
- ” In complex environments, you can’t follow recipes or conduct detailed analysis to understand the situation. Rather you must experiment (probe) ” – Cynefin
At de agile rammeværker understøtter og udtrykker vigtigheden af at eksperimentere for at lære, er ingen overraskelse eller tilfældighed. Det agile manifest udtrykker ligeledes dette, i den første sætning:
- ”We are uncovering better ways of developing software by doing it and helping others do it.
Det at eksperimentere, er altså helt fundamentalt i det agile mindset og i de agile rammeværker.
Eksperimenter og Hypotese-drevet udvikling
Hypotese-drevet udvikling er at tænke på udvikling af nye idéer, produkter, services – selv organisatorisk forandring – som en serie af eksperimenter
for at fastlægge hvorvidt et ønsket outcome kan opnås. Processen itereres indtil det ønskede outcome er opnået eller det konkluderes ikke hensigtsmæssigt at forfølge.
Det traditionelle User Story format, fokuserer på at beskrive krav for hvad vi ønsker at bygge, til hvem og hvorfor.
- Som en < rolle >
- Vil jeg < mål >
- Med det formål at < fordel >
Når vi anser vores arbejde som et eksperiment, er det traditionelle story format ikke tilstrækkeligt. Som i den videnskabelige metode (beskrevet her), er vi nødt til at definere de skridt vi vil tage for at opnå et ønsket outcome, samt definere hvordan vi vil måle om eksperimentet har været succesfuldt eller har slået fejl. Det handler om at skabe et feedback-loop, hvor vi uanset resultatet, bliver klogere. Derfor ser formatet for Hypotese-drevet udvikling (HDD) ud som følger:
- Vi tror at < denne evne eller egenskab >
- Vil medføre < dette outcome >
- Vi er trygge ved at fortsætte når < vi ser dette målbare signal >
Vi tror at < denne evne eller egenskab >
Beskriver hvilken funktionalitet vi vil udvikle for at teste vores hypotese. Ved at definere en testbar evne/egenskab af det produkt vi forsøger at bygge, identificerer vi ligeledes den funktionalitet og hypotese vi vil teste.
Vil medføre < dette outcome >
Beskriver hvad der er det forventede outcome af eksperimentet. Hvad er det konkrete resultat vi forventer at opnå, ved at bygge denne testbare evne/egenskab.
Vi er trygge ved at fortsætte når < vi ser dette målbare signal >
Beskriver hvilken indikator der skal måles på for at vurdere om det vi har bygget, er effektivt eller ej i forhold til hypotesen.
Lad os tage et eksempel:
- Vi tror at < en tidsbegrænset rabat i indkøbskurven >
- Vil medføre < øget konvertering fra indkøbskurv til gennemført salg >
- Vi er trygge ved at fortsætte når < vi ser 2% stigning i antallet af konverteringer fra kurven >
Eksperimentér med Hypotese-drevet udvikling
Nu har du den simpleste skabelon for at arbejde med hypotese-drevet udvikling. Så uanset om du er teammedlem, Product Owner, Scrum Master, Agil Coach, leder eller porteføljemedarbejder kan du eksperimentere med at implementere denne i din kontekst. På den måde kan du være med til at bringe empirisme, den videnskabelige metode, eksperimenterne og fokus på organisatorisk læring tilbage i jeres ’Agile’ kontekst.
- Jeg tror at < øget fokus på hypotese-drevet udvikling >
- Vil medføre < revitalisering af jeres ’’Agile’’ til stor fordel for jeres kunder og medarbejdere >
- Jeg er tryg ved at fortsætte < når jeg ser øget fokus på organisatorisk læring og psykologisk sikkerhed til at fejle >
(i stedet for fokus på rammeværker, events og rollebeskrivelser)
Læs med i tredje og sidste afsnit af denne serie, som netop handler om, hvordan Hypotese-drevet udvikling kan være med til at skabe en kultur med psykologisk sikkerhed og fokus på organisatorisk læring. Næste afsnit udkommer 15. september 2020.
2 Comments
Leave A Comment
You must be logged in to post a comment.
Hej Stefan,
Tak for virkelig interessante artikler – det har givet mig et godt greb til at arbejde mere hypoetese drevet 🙂 Et afklarende spørgsmål til hiarkiet mellem Epics og User Stories: En epic udgør hypotesen (Vi tror x, vil medføre y, og vi er trygge ved at fortsætte når z”) , og så er User Stories de udviklingselementer, der skal til for at teste hypotesen? Eller har du et andet perspektiv?
Vh. Line
Hej Line, tak for din kommentar og dit spørgsmål. Det er nok meget kontekst-afhængigt. I rigtig mange tilfælde kan du og vil det give god mening, at arbejde med det, på den måde du beskriver. Hvor det er på Epic eller Feature niveau at man drøfter hypotesen, mens stories anvendes som inkrementelle skridt mod den overordnede hypotese. Det er nok den mest udbredte måde at gøre det på.
Nogle gange kan det give mening også at gå skridtet videre – og drøfte hvordan den enkelte story bidrager til den overordnede hypotese. Så hvordan tror i, at denne story vil tage jer et skridt videre den overordnede hypotese? Hvad man kan man se og måle af ændringer når denne story er færdig? Og hvordan bekræfter det os i, at vi er på rette vej eller ikke?
God fornøjelse med hypotese-drevet udvikling 🙂