Du som er opptatt av smidig utvikling har sikkert hørt dette spørsmålet: Når iterasjoner over hyppige tilbakemeldinger fra kunder er så viktig – hvordan klarer Apple med sitt hemmelighetskremmeri og sine grandiose lanseringer å møte markedet med nyskapende produkter, gang på gang?
Smidig-skeptikerne elsker dette argumentet.
De tar det som et endelig bevis på at vi ikke trenger hyppige, inkrementelle leveranser. Kanskje føler de seg som Michael Palin i den surrealistiske Monty Python-sketsjen hvor han og John Cleese har en engasjert diskusjon om hvorvidt de har en diskusjon. I et forsøk på å unnslippe et sviende nederlag, har Cleese det ultimate svar når Palin triumferende påpeker at han diskuterer på overtid: «I might be arguing on my spare time»...
«No you’re not». «Yes I am». «No you’re not». «Yes I am» …
Det finnes like surrealistiske diskusjoner i programvareutviklingens forunderlige verden. Det er alltid noen som ønsker å levere programvare til produksjon i små inkrementelle steg, og det er alltid noen som ikke ønsker å gjøre det.
Hva med Apple? Itererer de på fritiden? Kanskje vi som liker hyppige, inkrementelle leveranser skal anerkjenne det Apple gjør, og gi skeptikerne et poeng. Da slipper vi også å pine oss selv med disiplinen et inkrementelt utviklingsforløp krever. Masete deployments som skaper masse støy i hverdagen. Masete dialoger med krevende brukere, som bare vil ha mer og mer. Vi er de begavede utviklerne, kodesmedene – craftsmen – hvorfor skal vi ikke la oss styre av visjonen og instinktene? Vi er da ikke noe dårligere enn Steve Jobs!?
Jeg møter denne forestillingen både innenfor og utenfor smidig-miljøet. Den begrunnes ofte med at brukere mangler fantasi. De vet ikke hva de trenger, og tenker ikke utenfor boksen når de ber om nye løsninger, som i beste fall ender opp med å bli en marginal forbedring av det systemet de bruker allerede. Henry Ford oppsummerte det greit: «Hadde jeg spurt folk hva de ville ha, hadde de svart raskere hester».
Her blir det imidlertid vanskelig. På en måte har skeptikerne rett, og på en annen måte tar de feil.
Det er riktig at brukere kan mangle fantasi, for ikke å snakke om kunnskap om programvareutvikling, og be om løsninger som er langt fra optimale. Skeptikerne tar imidlertid feil når de bruker dette som argument for å unndra seg hyppige leveranser.
Det faktum at brukere ikke vet hva de vil ha, er ingen grunn til ikke å levere hyppig.
Vi bør fortsatt ha tett interaksjon med brukerne våre, og det mest effektive er å benytte programvaren som medium. Vi trenger fundamental forståelse av brukerne og deres situasjon. Vi må ha empati med brukerne, og forstå dem bedre enn de forstår seg selv.
Vi stiller dem ikke spørsmål om funksjonalitet. Istedenfor spør vi hva de føler når de logger seg på maskinen. Hva er deres favorittprogram? Hvorfor bruker de produktet vårt?
Slike dialoger gir oss innsikt, og innsikten gir oss idéer. Tonnevis av idéer. Her melder iterativ utvikling seg til tjeneste.
Istedenfor å slenge gullbarren ned i én kurv full av egg, bygger vi oss en kort og effektiv tilbakemeldingsløkke der vi på kortest mulig tid lanserer fragmenter av en idé. Hensikten er å lære noe om brukernes adferd og respons. Vi tolker dataene og får så nye idéer om idéen. Vi legger ut en liten forbedring og måler effekten. Vi lager to enkle versjoner av en forbedring, og måler hvilken som blir mest brukt. Vi trekker tilbake en funksjon vi lagde for en stund siden, og ser hva som skjer. Denne runddansen, bygg-mål-lær, gjør at vi lærer så fort at vi ikke lenger har tid til å velge feil kurs. Brukerne må finne seg i å være forsøkskaniner, fordi dette gir det beste og rimeligste produktet både på kort og lang sikt.
Det interessante med denne tilnærmingen er at verken smidig-ekstremistene eller -skeptikerne er enige.
For dem er du henholdsvis ikke i kontakt med brukerne, eller for mye i kontakt med brukerne. Enten hører du ikke på hva brukerne ber om, eller så lar du brukerne diktere produktet ditt. (Takk til Kent Beck for dette perspektivet). Det de ikke ser er at du lærer, og utnytter lærdommen din, fortere enn dem.
Fra Eric Ries bok The Lean Startup: We really did have customers in those early days – true visionary early adopters – and we often talked to them and asked for their feedback. But we emphatically did not do what they said. We viewed their input as only one source of information about our product and overall vision. In fact, we were much more likely to run experiments on our customers than we were to cater to their whims.
I Scrum-verdenen diskuterer man mye hva som er en god definisjon av det å være ferdig. Jeff Sutherland har en lang liste med steg som må gjennomføres for at en oppgave er ferdig. Det er vel og bra, men allikevel går han glipp av hovedpoenget: Du er ikke ferdig med en funksjonalitet før du har lært hvordan den blir benyttet av betalende brukere.
Fokusgrupper, brukersamtaler, og brukbarhetstesting med eller uten lab kan være kilder til forståelse, men denne lærdommen kan være misvisende. Sannheten ligger ikke det brukerne sier, det ligger i det de gjør – daglig. Kruttet finner du i serverloggene.
Dette kan vi utnytte ved å lage mekanismer for raske eksperimenter der vi henter inn bruksdata, meninger og annen kilde til kunnskap. (Når du først er i gang med A/B-testing kan det forøvrig være lurt å repetere statistikken fra studietiden, og er du så heldig å ha programvare i konsumentmarkedet kan verktøy som usertesting.com være nyttig.)
Jeg tror ikke Apple hadde fått sin suksess uten iterasjoner.
De har imidlertid et image som krever mer subtil omgang med markedet. Kanskje må de ha lengre iterasjoner enn mange andre – men det er en ulempe for dem, og en fordel for oss. Utnytt den! Det er i alle tilfeller utenkelig for meg at de med hell har lansert så mange produkter uten å jobbe iherdig og metodisk for å skaffe seg innsikt om kundene.
Diskusjonene i programvareutviklingens verden burde ikke handle om hvorvidt vi skal lansere i inkrementer. De burde være om hvordan vi gjør det. Om du ikke er der allerede, vil jeg oppfordre deg til å starte en diskusjon med teamet ditt om kilder til kundeinnsikt, verktøy for å hente inn datagrunnlag og hva slags iterativ strategi som kan understøtte dette.
Dere blir nytenkende før dere vet ordet av det.
