Jeg udgiver også nyhedsbrevet Digital Ugerevy
Hvis du arbejder med udvikling (eller taler med nogen, der gør), så er du uden tvivl stødt på et begreb som ‘Agile’ og formentlig også ‘Minimum Viable Product’ (forkortet MVP), der er opstået i ‘Lean Startup’-metodikken.
Et MVP er kort fortalt en meget skrabet udgave af dit produkt, der adresserer det behov/problem, du allerhest vil løse hos dine brugere. Mens de arbejder med det, sørger du for at tale med dem og få al den feedback, du kan, mens du itererer og itererer og gradvist videreudvikler og forfiner dit produkt.
Lean Startup (der henvender sig til alle, der skaber nye produkter under (ekstreme) usikkerhedder, og altså ikke kun opstartsvirksomheder/entreprenører) handler grundlæggende om, at man som team/afdeling/organisation bevæger sig igennem et loop bestående af tre elementer:
- Build
- Measure
- Learn
Du har idéer, som du bygger til et produkt, som du så måler på brugen af og får data, som lærer dig med at lære og give dig nye idéer – og så kører loopet igen. Lean Startup går i al sin enkelthed ud på at minimere den tid, rundturen i det loop tager.
Og midt i det hele ligger dit produkt, der altså starter sit liv som et MVP.
Desværre er der sket det, der ofte sker med begreber som ‘MVP’; det er blevet udvisket. Og flere steder er ‘Minimum Viable Product’ i stedet blevet morfet over til noget i retning af ‘det minimum af et produkt, vi kan tilbyde brugerne – men som stadig er et nogenlunde færdigt produkt’. Og det er forkert.
Som du kan læse i Wikipedia-artiklen om MVP (med reference til Eric Ries’ nyklassiker, ‘The Lean Startup’):
In product development, the minimum viable product (MVP) is a product with just enough features to gather validated learning about the product and its continued development.
I bogen fortæller Ries om, hvordan et af de firmaer, han har været med til at starte, eksperimenterede med ‘avatarer’ til forskellige Instant Messaging-klienter, som man kunne installere som plugins. Det fandt de i øvrigt hurtigt ud af, at de ikke skulle.
Derudover har Jeff Gothelf (forfatter til blandt andet bogen ‘Lean UX’) fornylig udgivet ‘Lean Vs Agile Vs Design Thinking’. Her søger han i essay-form at kombinere de tre forskellige retninger, som forskellige dele af en virksomhed kan bevæge sig i.
Her skriver han blandt andet om MVP:
[…] dig into what most organizations know of Lean Startup, and you’ll likely end up where most Lean Enterprises do – the MVP. Standing for Minimum Viable Product, MVP has become one of the most powerful and bastardized phrases in modern product development. As product managers strive to steer their engineering colleagues to build only what they need, the conversation inevitably nets out at what most would consider Phase 1 of the product, with the reality of a future Phase II never a sure thing. Despite Lean Startup’s core foundation on Agile principles and rhythms, few product teams work to integrate these two practices.
“Det gemmer vi til version 2…”
Det med den usandsynlige fase/version 2 er nok noget, mange af os kan nikke genkendende til. Hvem har ikke prøvet at fjerne features fra version 1 (formentlig for at nå en deadline eller hindre unødig kompleksitet) for at aftale at gemme dem til version 2 – der aldrig bliver til noget. Det kan der være flere årsager til, den hyppigste er nok, at der ikke ligefrem er mangel på punkter på ‘to do’-listen eller i pipelinen.
Men denne tilgang er endnu mere risky, hvis man ser et Minimum Viable Product som en version 1. For et MVP af afhængigt af, at der bliver itereret ovenpå det på baggrund af informationer/data om brugen af det. Det går galt, hvis vi gemmer de næste features til en spekulativ version 2.0.
Faktisk skal du igennem så mange iterationer, at jeg vil mene, det på sin vis er ligegyldigt at tale om versionsnumre – i stedet bør vi tælle vores ‘sprints’, hvor vi løber igennem Build-Measure-Learn-loopet.
Agile != Speed
En anden vigtig pointe omkring MVP (og Lean Startup og agil udvikling i det hele taget) er, at en stor del af det handler om at lære. Det er derfor, du skal have mod til at lægge et klodset MVP ud til brugerne, fordi du skal lære, og derefter gøre produktet bedre.
Men alt for ofte kommer det til at handle om hastighed (og her er det jo belejligt at barbere version 1 ned og i stedet kalde det et ‘MVP – for så er det jo smart). Gothelf skriver:
Agile is being “hired” today to drive velocity. The only goal that matters to most Agile software teams is the efficient delivery of a high quality code.
Og det er en af grundene til, at jeg i stedet for ordet ‘agil’ hellere vil bruge ordet ‘responsiv’. For i det ord ligger der, at man tilpasser sig – og man tilpasser sig ved at lære; man lærer af sine brugere og/eller man lærer sine omgivelser at kende.
Jeg kan også bedre lide ‘responsiv’ fordi det siger noget om, at man svarer hurtigt – men at man ikke nødvendigvis spæner over stok og sten og leverer hurtigt for enhver pris.
(Bemærk: Her er der forskel mellem den hastighed, Gothelf nævner og den hastighed, Ries taler om (når man bevæger sig igennem loopet). Gothelf kritiserer, at der bliver sat lighedstegn mellem Agile og et hurtigt leveret og færdigpakket produkt, mens Ries efterlyser, at man nedbringer den tid, der går imellem nyudvikling og tilføjelser til ens produkt.)
Det handler om at lære, og derfor er det paradoksalt, som Gothelf understreger i ‘Lean Vs Agile Vs Design Thinking’, at der ikke er nogen måde at vise på for eksempel en storskærm, hvordan man lærer og hvor god man er til opdagelse – det, Gothelf kalder ‘discovery’.
Selv det vildeste to-the-point burn down chart siger jo intet om, hvad man har lært undervejs. Kun at man produktionsmæssigt er ‘on track’ på vej mod sin version 1…undskyld; MVP 😉
Foto: Pixabay / Pexels
*
Denne artikel blev oprindeligt bragt på ebudvikling.dk