Kunsten å planlegge det ukjente
Dette er en fortsettelse av forrige post, Kunsten å kjøpe det ukjente. Vi antar nå at vi har fått anledning til å kjøre smidig utvikling av et nytt produkt, og at den utfordringen vi står overfor er å planlegge på en slik måte at vi gradvis bygger opp mest mulig verdi for brukerne.
Den første gangen vi gjør noe slikt føler vi oss på usikker grunn. Vi vet altså ikke helt hva vi skal lage, bare hva vi vil oppnå med det. Hvordan skal en plan for et slikt utviklingsløp egentlig se ut? Hvordan sikrer vi et godt resultat? Hvilken strategi skal vi velge?
Om vi velger Scrum er visse ting gitt
- Kjernen i planen er bare en liste med grovestimert funksjonalitet, kalt Produktkø
- Produktet bygges “sten på sten” i iterasjoner (Sprinter) av fast lengde (typisk 2-3 uker).
- Produktkøen skal ikke være “komplett” i starten, men må ha nok substans til at vi kommer godt i gang (arbeid for 3 sprinter bør være ganske veldefinert)
- Vi skal i størst mulig grad være styrt av lærdom (empirisk prosesskontroll) så her gjelder det å raskest mylig lage et produktinkrement som er kjørbart og analyserbart som gjør at vi er trygge på at vi er på rett vei.
- Jobben gjøres i utgangspunktet av ett tverrfaglig team
- Når produktet er vel oppe å kjøre – dog med begrenset funksjonalitet – gjelder det i tett kontakt med brukerne å levere verdifull funksjonalitet så hyppig som mulig.
- Utviklingen er kontinuerlig, uten fastlagt sluttermin – vi gjør løpende kost/nytte vurderinger og vurderer arbeidet opp mot andre ting i porteføljen.
- Om vi trenger å øke hastigheten på utviklingen kan vi øke teamstørrelsen (maks 9) eller sette på flere team.
- Vi regner ikke med at ting fungerer perfekt fra starten av (dette er urealistisk), men derimot at vi tar små skritt og forbedrer arbeidsprosessene gradvis mens vi jobber.
Planleggingsstrategi
Hvilke kriterier vi bruker for å optimaliserer produktutviklingen vil avhenge av mange ting, som for eksempel “nyhetsgraden” av det produktet vi skal lage. Om vi ligger i front å tenker å starte fra scratch med noe kundene ikke har skjønt at de trenger ennå, bør vi legge opp til et løp som benytter Lean Start-up tankegangen. Om vi på den annen side bare skal legge på ny funksjonalitet på et eksisterende produkt med en etablert kundebase, gjelder det å alliere seg med noen representative brukere og å la disse få stor inflytelse på prioritering og utforming.
Men uansett: Planlegging av innovasjon dreier seg om å teste hypoteser. Det som er viktig er å lære mest mulig, billigst mulig. Vi må unngå å låse oss for tidlig, før vi har fått validert vår antagelser om hva brukerne gjerne vil ha. Vi trenger en dynamisk og levende kø av arbeid.
Levende kø
Det som til enhver tid ligger på toppen av køen må være brutt ned i ganske små biter og være godt forstått av teamet som skal gjøre jobben. Dette betyr at hver gang en ny iterasjon starter er det enkelt å plukke ut en realistisk mengde arbeid.
Når arbeid tas ut fra toppen blir det plass til mer, hvilket jo betyr at noen av de litt større elementene lenger nede må brytes opp i midre biter og får plass i den øverste delen.
Vi kan gjerne ta vare på større produktideer og hypoteser i en slik kø, men de må bearbeides en del før de innvilges plass lengre oppe.
Budsjettering
Det eneste fornuftige er å unngå å låse budsjettet til en spesiell sum per år. Vi vet at vi kommer til å få verdifull ny informasjon etter noen gjennomførte iterasjoner, og denne informasjonen bør vi benytte oss av! Dessuten må vi være forberedt på at uforutsette ting (både muligheter og trusler) kommer til å påvirke vår prioritering. Så vi må være forberedt på å revurdere finansieringen løpende gjennom hele dette produktets levetid – minimum hvert kvartal.
Scenario
La oss si at vi bestemmer oss for å finansiere ett kvartal med utvikling og utviklerne anslår at det bør være mulig å få på plass en stabil plattform med en del kjørbar funksjonalitet etter ca 3 måneder (6 to-ukers sprinter) med et lite team på 5 fulltids utviklere. Her vil det være mulig å vurdere sunnheten til dette initiativet etter hver Sprint (Sprint Review).
OK, etter 6 Sprinter har teamet oppnådd mye og har vist at plattformen duger, og at de kan demonstrere enkel basisfunksjonalitet og at brukerne liker det de ser. Da kan vi velge å øke hastigheten (samt kostnadere selvfølg
elig) ved å sette på 3 til i teamet. Vi bestemmer å kjøre i nye tre måneder med denne bemanningen. Igjen må vi være forberedt på å revurdere denne satsningen etter hver Sprint.
Etter 6 nye Sprinter (totalt et halvt år) har vi fått i gang en aktiv, men liten brukergruppe. Vi ser at teamet nå leverer ny funksjonalitet rutinemessig hver andre uke og at potensialet er der, men vi trenger å skalere opp for å ta markedsandeler. Da kan vi for eksempel velge å sette på 4 utviklere til og dele opp i to 6-manns team. Vi vil tape noe hastighet på å ha to team jobbende på den samme koden, men overheaden behøver ikke være særlig stor.
Etter Q3 har det kanskje dukket opp andre muligheter som gjør at vi må prioritere denne satsningen noe ned, og går ned til det opprinnelige nivået på 5 teammedlemmer. I figuren ser vi hvordan kostnadsutviklingen følger dette forløpet.
Nyttige verktøy for løpende planlegging
Produktkøraffinering: Dette er en løpende aktivitet der interessentene og de som gjør jobben sitter sammen og bearbeider køen av arbeid. Erfaring fra Scrum viser at det er lurt å gjøre dette en gang i uken, til fast tid og sted. Opp mot 10% av teamets kapasitet kan være nødvendig. Her splittes store elementer opp i mindre biter, og teamet grovestimerer bitene.
Visjon: Uttrykk en samlende visjonen klart og tydelig. Det kan være formålstjenelig å både uttrykke en langsiktig visjon som er svært ambisiøs og omfattende, og en kortsiktig visjon som retter seg mot et begrenset produktinkrement. Den kortsiktige er da underforstått et steg på veien mot den langsiktige. Visjonen bør definere interessentene, hvilke behov disse har og hvordan forretningsmodellen ser ut. Det bør også være klart hvordan man har tenkt å måle at man er på vei mot målet. Risiko bør også innbefattes i visjonen.
Måling: Vi må sørge for å skaffe oss solid feedback på det vi leverer. Det er nyttig å få direkte feedback fra brukere på en demontrasjon (Sprint Review i Scrum) men den ultimate valideringen får vi fra markedets respons – som da må sees opp mot den gevinsten vi håpet å få. (Eksempler på målinger: Raskere saksbehandlingstid, flere betalende kunder, øker konverteringsgrad, antall besøk på en web-side, bedre brukervennlighet, høyere kundetilfredshet etc..)
Planleggingsstrategi: Rekkefølgen vi velger å realisere funksjonalitet i vil være svært avgjørende for suksess. Det anbefales sterkt å begynne med å skaffe seg en stabil, men ikke komplett plattform å bygge produktet på. Deretter å lage funksjonalitet beregnet på en liten del av markedet og da prioritere funksjoner dette segmentet ønsker seg. Bruk her gjerne MMF eller MVP. Om det er noen absolutte milepæler i kalenderen vil dette være styrende.
Veikart (Road Map): Det anbefales å vedlikeholde et overordnet veikart som til enhver tid reflekterer hvordan framtiden ser ut. Dette kartet er kun en plan basert på den informasjonen man har på et gitt tidspunkt, og kan ikke betraktes som noe løfte.
Et veikart kan være funksjonsorientert som i figuren, men det kan være formålstjenelig å inkludere andre detaljer slik som avhengigheter, teknologiske milepæler, eller for eksempel opplæringsplan.
In: Planlegging, produkteier, prosjektledelse, Scrum · Tagged with: kundeverdi, ledelse, prosjektstyring, Scrum, Smidig, Styring