MVP, MMF, PSI, WTF? Første del: Forståelse af MVP
Når jeg arbejder med nye Product Owners, oplever jeg ofte, at vi bliver fanget i et hav af TLA’er (Three Letter Acronyms), når det er tid til rent faktisk at begynde at omdanne deres Backlog af ideer til udgivelsesværdige inkrementer af værdi.
Tanken om at bryde arbejdet ned – at bryde vores store, planlagte produktudgivelser ned i mindre værdiforøgelser – er der, hvor mange nye produktejere kæmper. Hvordan tager vi denne produktkøreplan og omdanner den til noget, som mine Scrum-teams faktisk kan levere på en kort, regelmæssig kadence? Hvordan kan jeg forvandle denne enorme liste over meget vigtige funktioner (VIF’er) til et iterativt sæt af muligheder for at lære, levere værdi og faktisk give vores kunder noget i hænderne? Med andre ord….
“Hvad er vores MVP?”
“Er det vores MMF?”
“Kan vi frigive denne PSI som en MVP, eller skal der laves flere historier, før vi har en MMF?”
Also….hvad???
Hvad betyder disse TLA’er? Hvordan er de forskellige fra hinanden? Hvordan er de relateret? Hvorfor skulle jeg være interesseret?
Med udgangspunkt i MVP (Minimum Viable Product) vil denne serie i tre dele hjælpe begyndende agilister med at forstå, hvad disse TLA’er betyder. Hvordan er de forskellige fra hinanden? Hvordan er de relateret? Hvorfor skal jeg være interesseret? Den vil også hjælpe dem, der har arbejdet agilt i et stykke tid, med at minde dem om, hvorfor disse begreber er grundpillerne i agilitet.
For folk, der lige er begyndt at lære om Scrum, kan de henvende sig til Scrum-guiden … og hurtigt lære, at Scrum-guiden er tavs om hvordan man omdanner et produkt til en samling af små, frigivelsesvenlige værdiforøgelser.
Den manglende information om dette vigtige emne kan være virkelig frustrerende for nye produktansvarlige. Forhåbentlig vil resten af denne artikel tydeliggøre MVP’er, og der er altid Certified Scrum Product Owner-klasser at tjekke ud for at få flere oplysninger. Lad os nu dykke ned i Minimum Viable Product.
MVP
Du har lavet din research, du har gennemgået kundefokusgrupper gennem et par runder af Buy a Feature, og du har truffet nogle beslutninger om, hvordan din næste udgivelse kan se ud. Faktisk har du engageret dit marketingteam, og du er i gang med at iterere idéer til, hvordan du kan gøre et stort indslag – annoncer i fagblade, promoverede Tweets, Facebook-opslag …
Men der er stadig nogle nagende spørgsmål, du har omkring nogle af de funktioner, du arbejder på. Du har tænkt over dem, du har analyseret dem, men der er denne stemme i dit hoved, der bliver ved med at spørge: “Men hvordan ved du det?”
Det er her, MVP’en kommer ind i billedet – ikke Steph Curry, men det (måske fejlagtigt navngivne) Minimum Viable Product.
The Lean Startup Conundrum
I sin bog “The Lean Startup” omdefinerer Eric Reis på forvirrende vis begrebet “Minimum Viable Product”, hvilket han forklarer i et interview i 2015. Kort fortalt:
“Nogle forbehold lige med det samme. MVP handler, på trods af navnet, ikke om at skabe minimale produkter. For det andet betyder definitionens brug af ordene maksimum og minimum, at den decideret ikke er formelagtig.”
Så, hvis verden af Product Ownership og det agile samfund har omdefineret Minimum Viable Product til hverken at handle om at skabe et minimum eller produkter, hvad er det så?
All About the Learning
Denne nagende stemme i baghovedet, der spekulerer på, om der er en vej ud af den analyseparalyseringsfælde, du befinder dig i, og som forsøger at finde en måde, hvorpå du rent faktisk kender svarene på nogle af dine spørgsmål, i stedet for at analysere dig selv ind i en dybere følelse af falsk sikkerhed? Det er her, Minimum Viable Product kommer ind i billedet.
Hvor et PSI (Potentially Shippable Increment) handler om at skabe mulighed for potentielt at sende noget af værdi, og MMF (Minimum Marketable Feature) handler om at kombinere disse stykker af værdi i en samling af funktioner, der løser kundeproblemer, handler MVP’et om at udføre den minimale mængde arbejde, som dit team kan udføre for at lukke et valideret læringsloop.
I Lean Startup-metoden til produktopdagelse er en af de vigtigste vaner at få ind i en vane at validere hypoteser og skabe eksperimenter. I mere traditionelt risikovillige organisationer fører troen på, at risikoen skal analyseres ud af dit produkt før lanceringen, til lange gennemløbstider og, frustrerende nok, databaserede antagelser om kundernes ønsker og behov. Hvis vi er rigtig gode til statistisk analyse, og hvis vi har rigtig gode data om en statistisk signifikant del af vores kunder, kan vi gøre et ret godt stykke arbejde med at formulere et kvalificeret gæt om, hvad vores kunder ønsker.
Men i sidste ende er det stadig et gæt.
Når vi skaber MVP’er, bygger vi med vilje lige præcis nok funktionalitet til at stille de rigtige spørgsmål til vores kunder – ville du købe dette produkt? Giver disse ikoner mening? Frustrerer denne arbejdsgang dig, eller hjælper den dig med at finde din næste yndlingsrestaurant?
På dette tidspunkt kigger vi på papirprototyper, wireframes til websites, UI mock-ups; vi går over på den anden side af gaden til indkøbscenteret for at vise vores design til de nærmeste mennesker, vi kan, bare for hurtigt at bekræfte, at vi er på rette vej.
Magien i at skabe en god MVP ligger dog ikke i værktøjerne eller teknikkerne; den ligger i disciplinen, når man ønsker at analysere data fra et website heat-map for at finde ud af, hvilket farveskema der fungerer bedst, til i stedet at gribe nogle markers og papir, skitsere et par low-fidelity-løsninger og spørge nogen: “Hvilken af disse kan du bedst lide?”