Veileder

Innledning

Denne veilederen beskriver et styringssystem for tjeneste- og produktutvikling. Systemet er optimalisert for hurtig flyt, basert på at arbeidet gjøres av tverrfaglige team, i korte iterasjoner og at gevinster realiseres løpende. Modellen er samtidig laget for fortløpende eksperimentering og læring gjennom at teamene og brukerne sammen finner fram til enklest og best mulige løsninger. Alt i denne veilederen baserer seg på verdiene og prinsippene fra Agile Manifesto, og det kan være lurt å bruke Dette er smidig som referanse. Den våkne leser vil også finne mye samstemmighet med Lean-tankegangen her.

Denne måten å jobbe på er spesielt godt egnet for innovasjon og i det hele tatt arbeid som preges av kompleksitet og dynamikk der kreativ tenkning og utforskning vil være en suksessfaktor.

Modell

Alle nye initiativer (store og små) starter med en idé eller en visjon. Her gjelder det at den eller de som har denne ideen evner å uttrykke den slik at andre som må involveres både forstår den og tror på den. Etter at visjonen er klar får vi en relativt kort oppstartsfase der vi validerer antagelsene våre så raskt og så billig som mulig. Når vi er trygge på ideen starter tre kontinuerlige, parallelle og koblede aktiviteter – Planlegging, Gjennomføring og Gevinstrealisering. Disse løper så lenge antatt nytteverdien overstiger kostnadene. Nytte kan være knyttet til validerte antagelser, inntekter, utbredelse, markedskunnskap etc…

<b>Generisk, overordnet, smidig prosessmodell</b>

Det kommer an på …

Det er umulig å lage en allmengyldig “oppskrift” for IT-utvikling. Til det er mangfoldet, kompleksiteten og dynamikken alt for stor. Denne erkjennelsen er dypt forankret i smidigtankegangen og vil ofte resultere i at svaret på spørsmål har en lei tendens til å være “det kommer an på”. Så hvordan kan da en slik veileder fylle en funksjon og være til hjelp for alle som utvikler IT-baserte systemer? Det dreier seg om å sørge for å få feedback raskest mulig, hyppigst mulig slik at vi kan lære underveis og realisere så mye gevinst som mulig billigst mulig. (Det kan bemerkes her at akkurat hvor raskt og hvor hyppig det er mulig å lage resultater man kan få feedback på, kan variere veldig.)

Denne veilederen skal kunne benyttes om man er

  • et lite oppstartsfirma som har en lovende ide de vil teste ut på markedet.
  • en veletablert aktør i et veletablert marked og skal i gang med en oppgradering
  • en offentlig etat som skal i gang med et nytt satsningsområde
  • en innovativ virksomhet med stor portefølje som vil lansere noe helt nytt som brukerne ikke har forstått at de trenger ennå
  • etc…

Kanban, Scrum, XP, en miks, eller noe annet?

Denne veilederen er nøytral i forhold til valg av konkret metode så lenge den baserer seg på kundefokus gjennom hyppige leveranser, kontinuerlig forbedring og selvstyrte team. Allikevel vil vi benytte en del Scrum-begreper, siden disse er mest utbredt. Anbefaler her å bruke denne Scrum-håndboka som referanse.

Roller og organisering

Prinsipper

IKON_FAROLLERFå roller. Vi ønsker ikke å dyrke spesialiserte roller for mye. Dette fører lett til “silodannelser” der de ulike rollene jobber hver for seg mens helheten kommer i bakgrunnen. Ved å ha så få unike roller som mulig blir det kollektive ansvaret for helheten tydeligere. I stedet ønsker vi å dyrke teamarbeidet, der en sak kan analyseres, planlegges, gjennomføres og leveres av ett og samme team.

 

IKON_ANSVARLIGETEAM

Ansvarlige, utførende team. Arbeidet bør i størst mulig grad utføres i team med et kollektivt ansvar for helheten. Disse teamene bør ha tilstrekkelig med myndighet til å kunne ta raske, selvstendige beslutninger så lenge disse er innenfor selve visjonen. Dersom flere team jobber mot samme visjon, må hvert team være bevisst på at de må ivareta helheten og ikke bare teamets mål.

 

IKON_TVERFAGLIGETEAMTverrfaglige team. Et team bør evne å selvstendig kunne løse “et helt problem”. Innen IT-systemer kalles dette gjerne en funksjon eller en feature. Dette vil si at et sterkt team må ha kunnskapen til å designe, teste, programmere, dokumentere, validere og levere en hel feature til brukerne og å validere at den faktisk løser problemet til brukeren på en god måte. I et tverrfaglig team må medlemmene være fleksible og alle kunne gjøre mer enn en type oppgaver. Vi kan ikke være avhengige av at en person kun kan utføre en helt spesiell type arbeid. Vi trenger mennesker med både dybde og bredde, det som kalles en T-profil.

 

IKON_SELVORGANISERINGSelvorganisering. Det finnes ingen fiks ferdig oppskrift, ei heller en komplett verktøykjede for systemutvikling. Det finnes heller ingen ferdig oppskrift for hvordan et tverrfaglig team skal kommunisere, samarbeide og forene kreftene mot samme mål. Dette er en gruppeprosess som vil pågå i hele teamets levetid og som gjennom iterasjonene og små erfaringsmøter (retrospektiver) kan utvikle seg til svært produktive team.

 

IKON_BAREKRAFTIGSELVSTENDIGORGNASIASJONBærekraftig, permanent organisasjon. Det kan ta lang tid å bli et godt, velfungerende team. Team består av ulike mennesker som trenger å bli kjent med hverandre, bli trygge på hverandre og å forstå hva som kan forventes av den enkelte. Gruppedannelse foregår gjennom Tuckmann-sekvensen Forming, Storming, Norming før man endelig er i Performing. Når et team er i Performing bør de få ro til å jobbe sammen over lang tid. Det er kanskje unødvendig å splitte opp et team selv om et prosjekt er ferdig. Forsøk i stedet å la team være mer permanente og få arbeidet sitt fra ulike prosjekter – som kan komme og gå over tid.

IKON_COACHINGCoaching. Vi ønsker team med et sterkt eierskap og drivkraft mot målet, og da må teamene i størst mulig grad styre og organisere seg selv. Så i mangel av en leder som styrer og dirigerer må vi i stedet ha en rolle som kan veilede, fasilitere og gi organisasjonen et puff i riktig retning når det trengs. Smidige organisasjoner vil være i konstant endring, og det finnes ingen ferdig oppskrift på hvordan jobben skal gjøres eller hvordan team og personer skal samhandle, så dette må vi konstant ha på agendaen. I Scrum vil denne funksjonen ivaretas av Scrum Master.

IKON_SAMLOKALISERINGSamlokalisering. Det gir en rekke fordeler om de som samarbeider om å gjøre jobben sitter sammen og har svært rask og enkel tilgang på hverandre. Dette stimulerer til kreativitet, til å effektivisere arbeidsflyten og forhindrer misforståelser. Ikke alle vil ha denne muligheten, og de vil gjennom ulike samarbeidsverktøy og korte koordineringsmøter kunne få det til å fungere greit. Men ikke helt optimalt.

Struktur

Det store spørsmålet blir da, hvordan strukturerer vi organisasjonen i henhold til disse prinsippene? Det blir veldig tydelig at den tradisjonelle, med funksjonelt oppdelte avdelinger, vil by på utfordringer. Kommunikasjonen blir lett indirekte og langsom. Avdelingene har sine egne funksjonelt orienterte målsetninger og faren for friksjon og sub-optimalisering blir stor. Hierarki med mange nivåer vil også gjøre det vanskelig å være tilpasningsdyktig og å ta raske, gode beslutninger. Det blir lett slik at de som tar beslutninger også er de som har lengst avstand til begivenhetene.

Ideelt grunnoppsett med direkte kommunikasjon

Ideelt grunnoppsett med direkte kommunikasjon

Om man følger prinsippene over blir den ideelle grunnstrukturen slik at tverrfaglige team jobber direkte med brukerne (eller markedet om man vil) styrt av en ledelse med en tydelig visjon.

Større organisasjoner kan da bygges opp av ulike tverrfaglige team, eller klynger av slike team. Disse teamene må kunne ta vesentlige beslutninger både relatert til arbeidsmetodikk og til å finne tekniske løsninger.

En mulig smidig, produktorientert organisasjonsstruktur

En mulig smidig, produktorientert organisasjonsstruktur

 

I figuren ser vi en optimal modell for en smidig organisasjon, der hver verdistrøm (produktområde) utvikler, drifter og markedsfører sine respektive områder. For å optimalisere en slik organisering må hvert produktområde være mest mulig autonome, slik at de i størst mulig grad kan jobbe i sin egen flyt ut mot sitt eget marked.

Det kan være nødvendig at ett område i realiteten håndterer infrastruktur og altså ikke har en egen verdistrøm. Dette støtter de andre teamene med ekspertise og ressurser for å legge til rette for hurtige, smertefrie leveranser i hvert av produktområdene.

En konsekvens av denne modellen er at det blir unødvendig med høye hierarkier. Toppledelsen vil komme “tettere på virkeligheten” og en del mellomledere som i prinsippet jobber med administrasjon vil bli overflødige (Merk: en del av disse vil ha nyttig kompetanse å ha med seg i teamene).

Faglig utvikling

Alle de tverrfaglige teamene vil bestå av ulike fagpersoner som jo selvsagt fortsatt må ha en faglig utvikling. Derfor må vi allokere noe kapasitet til faglig aktivitet, der fagpersoner fra de ulike teamene samarbeider på ulike vis. Det er mange muligheter for organisering av slike faglige fellesskap (“communities of practice”). Det er vanlig å definere noen faste møteplasser, etablere studiesirkler, diskusjonsgrupper og felles arbeidsområder for å utveksle synspunkter og erfaringer.

Oppstart

Oppstart

Hensikten med denne aktiviteten er skaffe til veie mest mulig håndfast informasjon om hvordan en visjon kan realiseres, slik at organisasjonen kan fatte gode, informerte beslutninger. Er det riktig å skalere opp og virkelig satse, eller ikke?

Dette er den aktiviteten som vanskeligst lar seg standardisere. Det vil være rom for store ulikheter i utstrekning av og innhold i denne fasen. Men det dreier seg først og fremst om å ta en beslutning om å sette i gang “på ordentlig”. Skal vi prioritere dette området framfor andre viktige områder?

Det vil ofte dreie seg om å finne finansiering, enten man er ute etter internt budsjett, eller å selge ideen til en investor.

Det kan være smart om man her har et svært bevisst forhold til usikkerhet. Om man vil forsøke å lansere en helt ny og ganske uprøvd tjeneste, bør man angripe dette iterativt med bevisst “prøving og feiling” og være åpen for at selve ideen må endres – eller forkastes. I slike tilfeller kan hovedhensiktene med aktiviteten være å falsifisere antagelser så raskt og billig som mulig.

Skal man i gang med ny funksjonalitet man er trygg på at brukerne virkelig ønsker seg kan det være riktig å kjøre et litt mer tradisjonelt løp i starten – så lenge man ikke bruker alt for mye tid og penger på å komme i gang.

Ulike utgangspunkt for oppstart

Denne fasen vil bli sterkt preget av enkelte rammebetingelser gitt av det utgangspunktet organisasjonen har. Grovt sett kan vi dele det inn i tre hovedgrupper

  1. Allerede veletablert, fleksibel utviklingskapasitet: Satsningen gjennomføres i egen organisasjon med etablerte team
  2. Noe utviklingskapasitet eksisterer: Satsningen gjennomføres ved å styrke etablert organisasjon med innleide fagfolk
  3. Lite intern utviklingskapasitet: Satsningen gjennomføres ved å utlyse anbud og overlate utviklingen til et leverandørstyrt prosjekt.

I smidige IT-satsninger vil man bestrebe seg på å involvere utviklere tidlig, helst lenge før hele problemstillingen er fullstendig klarlagt og forstått. De vil kunne bidra med å gjøre gode tekniske valg, lage prototyper og minimale produktinkrementer som brukerne kan få prøve ut og ellers bidra med kunnskap.

På dette området vil utgangspunkt 3 by på utfordringer sammenlignet med 1 og 2. Anbud baserer seg vanligvis på at problemet er analysert og beskrevet slik at leverandørene kan konkurrere om å gjennomføre prosjektet. Men dette er jo uforenelig med smidig, siden vi hele tiden må være åpne for å lære underveis. Dessuten er det problematisk at selve prosessen både er dyr, arbeidskrevende og konsumerer mye verdifull kalendertid. Så hvordan kan anbud organiseres enklere, raskere og uten å låse løsningen for tidig? Her kommer noen prinsipper man kan følge

  1. Husk at suksessfaktor nummer 1 alltid vil være menneskene som gjør jobben. Erfarne, kompetente, dedikerte fagpersoner som jobber godt sammen er det som gjelder – selv om arbeidet utføres av ekstern leverandør.
  2. Utlys anbud tidlig, med tanke på å utnytte leverandøren i oppstartsfasen. Gi opsjon på gjennomføring.
  3. Krev smidigkompetanse og ikke minst erfaring. Gjennomføre en smidigevaluering.
  4. Hold spesifikasjoner og framdriftsplaner unna kontrakten.
  5. Husk at alle involverte må være i samme båt og styre mot den endelige verdiskapningen sammen.
  6. Husk at kunden må være aktivt involvert gjennom hele løpet og bidra med innsikt, behov og ikke minst prioritering slik at kreftene brukes på det som gir mest mulig verdi.
  7. Vær forberedt på at læringen vil kunne komme til å utfordre hele satsningen: Sørg for at ikke avtaler er til hinder for å stoppe helt eller delvis opp.

Visjon

Helt i starten gjelder det å drøfte selve ideen både i bredde og dybde. Er vi sikre på at vi har et problem som er verd å løse? Er vi trygge på at kundene virkelig trenger dette? Er de villige til å betale (nok) for dette? Her kan det være aktuelt å intervjue brukere, kanskje lage enkle modeller / skisser som brukerne får uttale seg om. Så det aller første må være å identifisere kundesegmentene eller brukergruppene. Det neste blir å søke å forstå disse så godt som mulig, slik at vi kan tilby dem løsninger som gir dem mest mulig gevinst.

Metodetips:

Husk at denne visjonen må gjøres kjent og gjerne “eies” av mange ulike roller internt (og kanskje eksternt). Så dette må uttrykkes på en gjennomtenkt, kortfattet måte uten å bruker alt for tekniske termer.

Utnytt utviklerne

Utviklingsteamene kan med fordel kobles inn tidlig. Her finner vi designere, utviklere, arkitekter, testere og så videre som kan ha gode innspill og som gjerne først som sist kan utvikle et eierskap til denne nye satsningen. De kan lage prototyper, og eksperimentere med ulike løsninger.

Det kan være lurt at et solid, erfarent team faktisk setter i gang og lager noen produktinkrementer allerede i oppstartsfasen. Man vi typisk kjøre 3-5 2-ukers iterasjoner. Dette kan gi et uvurdelig beslutningsgrunnlag gjennom at man allerede tidlig får gjort en solid validering av ideen, tekniske løsninger og teamets hastighet.

Antagelser

Det er uunngåelig at vi baserer ideen vår på visse antagelser. Dette kan være alt mulig fra at vi antar at vi har forstått kundenes virkelige behov, til at vi antar at vi har kompetanse eller andre ressurser tilgjengelig. Det kan også dreie seg om skalerbarhet og ytelse i valgt teknologi.

Assumptions is the mother of all f**ups

Det store spørsmålet blir da ” Hvordan kan vi raskest og billigst mulig få validert antagelsene våre?” Svaret er “bruk en iterativ tilnærming”

Iterativ Oppstartsfase

En smidig tilnæring til oppstart vil på en eller annen måte være iterativ. Hver iterasjon har som formål å få testet ut en hypotese. Eller sagt på en annen måte: å raskest og billigst mulig få validert en antagelse

 

Antagelser kommer i mange ulike former og forkledninger. De er ikke alltid så lett å få øye på, men vil alltid være ganske bestemmende for om vi lykkes eller ikke. Det er særlig viktig i de tidlige fasene å være ydmyke for at selv den sterkeste hypotese kan vise seg å ikke holde vann.

De aller mest grunnleggende antagelsene vil være knyttet til selve idéen eller Visjonen. Opphavsmannen til en idé vil lett forelske seg i denne og raskt få en klokketro på at han denne gangen virkelig har kommet på noe bra som det er verdt å bruke tid og krefter på. Om denne opphavsmannen er av den entusiastiske og kanskje karismatiske typen vil han antageligvis få med seg en del andre på denne ideen. I en slik situasjon kan det være lurt å sette på bremsen og insistere på å finne ut hva brukergruppen vi går etter synes. Er de enige med oss – eller ikke? Har vi her et problem som er verd å løse – eller skal vi bruke tid og krefter på noe annet?

Hvis brukerne ikke gir oss de svarene vi helst ville ha gjelder det da å tillegge brukerne tilstrekkelig vekt. Nå finnes det selvsagt situasjoner der brukeren ikke helst forstår sitt eget beste – men det kan man trygt betrakte som unntaksvis.

I oppstartsfasen bør vi følge de smidige prinsippene for roller og organisering, særlig det om å jobbe i ansvarlige, tverrfaglige team. Vi må plassere brukerne i sentrum og tillegge brukernes preferanser og tilbakemeldinger stor vekt. Fagsammensetningen vil her naturlig nok tendere mot en overvekt av eksperter på brukeropplevelse og design.

Antagelser kan også være av mer teknisk karakter. Hvis man har en hypotese om at en teknisk løsning innehar alle de nødvendige egenskapene (det kan være ytelse, sikkerhet, skalerbarhet etc) så kan man på liknende måte kjøre igjennom noen iterasjoner for å teste ut hypotesen før man låser seg til en bestemt løsning.

Vi skal her se på noen ulike iterative, utforskende rammeverk. Felles for dem alle er at de dypest sett bygger på Walter A. Shewarts Plan-Do-Study-Act.

Bygg-mål-lær

Lean Start-up kan være et godt rammeverk å ty til for iterativ oppstart.BML

Ideen her er å “gå ut på gata” og treffe brukere og å gjennomføre samtaler/intervjuer, gjerne ledsaget av en prototype av systemet, for å få validert ideen. Er man i tidlig utforskningsfase kan det være nødvendig å gå en god del runder i denne syklusen for å trygge at vi gir oss i kast med et problem som er verd å løse.

Syklusen går her på at man lager et produkt som da representerer en potensiell løsning på brukernes problem. Dette produktet kan godt være en veldig enkel prototype, eller et ferdig men enkelt, produktinkrement. Dette kalles Minimal Viable Product som betyr det minste produktet som kan være egnet til å få validert en antagelse. Så er det å på en eller annen måte måle responsen fra brukerne slik at vi da kan diskutere om vi er på rett spor eller ikke basert på fakta heller enn ren synsing. I denne diskusjonen vil vi lett få nye ideer som vi kan teste ut i neste syklus.

Vær forberedt på at slike runder med tett kundekontakt kan gjøre at noen får nye ideer og at den opprinnelige visjonen forlates til fordel for andre, bedre ideer. Det er kritisk å kjenne brukergruppen og snakke med representative brukere, og det er viktig å evne å skaffe pålitelig fakta om hvordan ideen faktisk blir mottatt.

Designtekning

Design Thinking er en kreativ prosess for å komme fram til best mulig løsning på et problem. Prosessen baserer seg på tett, tverrfaglig samarbeid, visualisering av ulike løsninger i tett samarbeid med brukere der man gradvis nærmer seg et mål.

designthinking

De som designer løsninger må her virkelig komme inn under huden på brukerne og forstå dem best mulig.

 

BLT: Behov – Løsning – Test

Denne iterative tilnærmingen til innovasjon har blitt populær i Norsk offentlig sektor og gå i korte trekk ut på å systematisk fokusere på brukernes behov før man i det hele tatt begynner å tenke løsning. En mulig løsning lages på enklest mulige måte før den da skal testes ut sammen med brukeren.

blt

Sjur Dagestad forklarer modellen i denne videoen.

 

Lage eller kjøpe – eller leie?

Man må gjøre diverse vesentlige vurderinger i denne fasen. Skal vi lage ting fra grunnen av? Finnes det rammeverk eller standardkomponenter vi kan basere oss på, så vi kan starte hele utviklingen på et høyt abstraksjonsnivå? Eller finnes det gode miljøer i skyen vi kan leie oss inn i for å gjøre de tidlige iterasjonene billigst og raskest mulig? Kan vi utnytte ferdige API-er?

Her er det ingen fasit-svar, men generelt vil et smidig tankesett lede til beslutninger som ikke låser oss mer enn nødvendig. Vi er tross alt i tidlig fase, og vi må for all del unngå å satse alt på en hest og male oss inne i et hjørne.

Tidlige arkitektur-vurderinger bør også fokusere på hvordan vi kan skape oss autonomitet og muligheten til å lage funksjonalitet med minst mulig forstyrrelser og avhengigheter av andre vi ikke har kontroll på. Løst koblede komponenter som tillater teamene å jobbe med en høy grad av autonomitet er et godt ideal.

Planlegging i Oppstart

Release planlegging

Basert på det vi har funnet ut gjennom arbeidet med visjonen kan vi begynne å lage en grov plan.

En smidig plan vil i hovedsak bestå av en sekvens av leveranser eller inkrementer av den endelige løsningen. Så det store spørsmålet blir da “hva skal vi fokusere på først”? Hvilket lite inkrement skal vi lage og analysere aller først?

Utgangspunktet for en slik plan vil være en “produktkø”, som i prinsippet er en liste med de elementene produktet er tenkt å bestå av. En slik kø skal ikke være “komplett” men inneholde arbeid for en en stund fram i tid. Elementene skal i størst mulig grad være “funksjonalitet” som alle interessentene kan forholde seg til.

Releaser

Produktkø med 4 planlagte releaser

Det er ulike måter å angripe dette på. Her er noen hint:

  • Start med helt enkel basisfunsjonalitet – det som brukerne MÅ ha for å få gjort noe som helst. Tenk Minimal Marketable Feature her.
  • Start med en smal kundegruppe. Forsøk å velge en gruppe som du kan anta er nysgjerrige på nye ting (“early adopters”, superbrukere etc..).
  • Start med det som vil kunne bety aller mest for å oppnå visjonen
  • Start med det mest risikable. Viktig her å være trygg på at dette er viktig, så vi ikke risikerer å bruke mye tid på å validere noe som er vanskelig, men kanskje ikke er tvingende nødvendig.

Bemerk at denne modellen er uavhengig av iterasjoner. I starten er det veldig vanskelig å gjette på hvor mye et team vil være i stand til å levere per tidsenhet. Det er avgjørende å ha et realistisk forhold til usikkerheten og være åpen for at de første iterasjonene må brukes for å vinne erfaring med både teamets kapasitet, antagelser og selve ideens realisme.

Bemerk også at det her i starten kan være riktig å lage prototyper som gjøres litt “fort og gæli” altså med en svak Definition of Done. I så tilfelle må vi ikke glemme at dette arbeidet antageligvis må gjøres om igjen hvis vi får en positiv validering.

Metodetips

Bruk brukerhistorier (User Stories) for å komme fram til produktkøelementene. Dette er historier uttrykt av brukerne, så her gjelder det å få ekte brukere til å delta. Dette gir også et godt, lettfattelig format på produktkøelementene der vi tar med oss gevinsten denne brukeren skal oppnå. Det kan også anbefales å sjekke brukerhistoriene opp mot huskeregelen INVEST.

Bruk Impact Mapping for å drøfte hvilke tiltak som vil kunne ha mest mulig betydning for å nå visjonen. Gjør tiltakene målbare og samle data underveis.

Bruk User Story Mapping for å gå igjennom komplette brukerhistorier og for å identifisere “Minimal Marketable Features”. Dette kan gi en verdifull pekepinn på hva enkelte brukere vil kunne finne interessant nok til å prøve det ut og å gi feedback.

Uerfarne team finner det ofte vanskelig å se hvordan en brukerhistorie kan splittes i små nok biter. Det krever trening å beherske denne kunsten, men ofte dreier det seg om å akseptere prinsippet og å lage noe helt basic og mangelfullt i første omgang, for så å suksessivt utvide med gradvis mer sofistikerte funksjoner etter hvert. Bruk gjerne Hamburger metoden til Gojko Adzik som inspirasjon for å komme i gang.

Road Map

Det kan være lurt å lage en overordnet, grov langtidsplan slik at alle impliserte kan se hvordan produkteier ser for seg framdriften. En slik plan kan gjerne inneholde noen hovedmålsetninger, samt noen tilhørende releaser eller produktinkrementer.

RoadMapEn slik roadmap må hele tiden være oppdatert og konsistent med produktkøen.

Scrum Produktkø

En produktkø i Scrum består av en rekke elementer som ligger i en bestemt rekkefølge. Alle elementene er grovestimerte, slik at vi vet noe om det innebyrdes størrelsesforholdet elementene imellom.

PyramidePå denne måten blir en produktkø det viktigste hjelpemidlet vi har for planlegging. De elementene vi er ganske sikre på at vi skal lage, vil vi naturlig nok investere noe mer tid på. Vi bryter de ned i små brukerhistorier og estimerer hver og en av dem. Dette arbeidet kaller grooming eller Product Backlog Refinement i Scrum.

En slik produktkø kan med fordel gjøres tilgjengelig for interessentene slik at de kan følge med på hvordan denne planen utvikler seg over tid.

Klar til gjennomføring?

OK, vi har gjort forarbeide, tatt beslutninger, samlet data og validert antagelser. Vi har laget en initiell produktkø, og vi har kanskje allerede laget et par produktinkrementer. Blir det GO eller NO-GO?

Hvor raskt trenger vi å jobbe for å oppnå målsetningene? Kan vi klare oss med et tverrfaglig team på 5 erfarne teamdeltagere, kanskje? Eller skal vi allerede sette på to eller tre team slik at vi får nok hastighet på plass fra starten av?

Tips: Sett i gang med ett erfarent team allerede i oppstarts-fasen. Kjør 3-5 2-ukers iterasjoner der teamet bygger produktinkrementer, og der vi finner teamets hastighet (velocity med Scrum-terminologi). På denne måten skaffer vi et svært godt beslutningsgrunnlag for hvor mye vi skal investere i dette produktet. Er det riktig å skalere opp og sette på tre team, eller holder det med ett? Eller blir det for dyrt/vanskelig slik at det er bedre å skrinlegge hele satsningen?

 

Planlegging

planlegge

Hensikten med denne aktiviteten er å sikre at vi hele tiden prioriterer å lage de produktinkrementene som antas å skape mest verdi for brukerne. På den måten sikrer vi å bruke innsatsen best mulig og unngår å lage funksjonalitet som brukerne ikke bryr seg om.

Proaktiv, langsiktig planlegging

Alle smidige virksomheter vil nødvendigvis ha ganske kontinuerlige innovasjonsprosesser gående. Dette kan både fokusere på å finne nye, strategiske satsningsområder, og det kan være prosesser for å dynamisk videreutvikle eksisterende produkter. I det siste tilfelle har vi allerede kontakt med noen (forhåpentligvis) interesserte brukere og andre interessenter. Dette bør utnyttes slik at vi på denne måten evner å bruke kundene som motor i videreutviklingsinnsatsen. Vi må også her utnytte at vi har ett eller flere permanente utviklingsteam som både vil kunne bidra med ideer, men også gjøre det mulig å raskt teste ut ideer og på den måten finne ut om man skal gå videre eller stoppe opp.

Selv om tverrfaglighet er et ideal, vil det her være naturlig at noen roller på forretningssiden ligger i forkant og gjør visse analyser av potensielle langsiktige gevinster. Samtidig må vi unngå at roller holder på for lenge “i vakum” før det gjøres ordentlige valideringsforsøk.

En måte å se dette på er at vi faktisk gjennomfører små varianter av oppstartsfasen med ujevne mellomrom. Dette kan planlegges inn i teamenes arbeid, slik at alle i virksomheten involveres tverrfaglig.

Tips: Det kan være lurt å ha dedikerte innovasjonsseanser - ofte kalt hackaton - med en viss frekvens. Her vil alle ansattes kreativitet kunne få utløp og overraskende, lovende ideer komme til overflaten. Blant disse ideene vil vi kanskje finne et lite antall som er verd å sette i gang en liten oppstartsfase på.

Løpende raffinering av produktkø

Vi planlegger løpende under hele utviklingen av produktet, så det kan være lurt å gjøre dette til en rutine. En gang i uken kan være en god syklus.

I henhold til Scrum vil her produkteier sitte sammen med utviklingsteamet og splitte store elementer opp i mindre biter og å estimere disse. Her er det lurt å velge estimeringsmetoder som sikrer en rask tverrfaglig gjennomgang av elementet slik at alle får en felles forståelse av det som skal lages. Planning Poker vil her være et godt valg.

Når elementene på denne måten får innbyrdes forskjellig størrelse vil produkteier med litt erfaring lett kunne plukke ut et omfang for neste iterasjon til teamet.

Planning Poker kan også benyttes for å estimere verdien av et element, med akkurat samme reglene. På den måten vil han nå også enkelt kunne gjøre kost/nytte vurderinger. Små elementer med antatt høy verdi vil da kunne foretrekkes. Når det er sagt, det vil ofte være nødvendig å se prioritering i et større perspektiv og stadig tenke Minimal Viable Product eller Minimal Marketable Feature. Og det kan her være fint å komplettere bildet ved alternative metoder for prioritering som for eksempel Kano analyse.

Planlegg for gevinst

Enkelte produktideer er innlysende og skal bare gjøres. Gevinsten er opplagt. Andre ideer er veldig uklare og ulne, men kan allikevel vurderes til å være såpass lovende at det er verd å bruke ressurser på. Bruk gjerne Kano analyse for å kategorisere produktkvaliteter. En av disse kategoriene er exciters – slike ting som kan få folk til å si “WOW!” når de står med den mellom hendene. Disse sakene har naturlig nok stor usikkerhet, høy pris, samtidig som oppsiden er stor. Kanskje er det nødvendig å koste på seg en exciter for å stikke seg og i mengden og å få brukerne med på laget?

Og så er det saker som vi kan forsøke å kvantifisere gevinsten av. Kvantifisering og måling kan være et veldig godt hjelpemiddel i forbindelse med både prioritering og oppfølging. Hvordan vet vi om vi har lykkes? Og ikke minst hvordan måler vi om vi beveger oss i retning av å lykkes? Vi må her advare litt mot å bruke bunnlinja som måleparameter. Denne informasjonen vil være avhengig av svært mange forhold (også ting vi ikke har kontroll på)  og den kommer rett og slett for sent. Derfor er det lurt å komme fram til parametere som er mer umiddelbare og som gir en indikasjon (men kanskje ikke fastisvar) på at vi beveger oss i riktig retning.

Det som kanskje er aller viktigst å beherske er kunsten å bruke kreftene på det som gir størst effekt – og altså helt eksplisitt unngå å lage funksjonalitet som ikke bidrar positivt til gevinst. Enkelt sagt vil en god produkteier prioritere de forholdsvis billige inkrementene med høy antatt verdi. Konkret vil dette innebære at enkelte produktkøelementer aldri vil nå opp i konkurransen med andre elementer. På denne måten unngår vi også å ende opp med produkter som er unødvendig store og komplekse – som jo i lengden vil være dyre å vedlikeholde.

Release-planlegging

Selv om vi jobber smidig og lærer iterasjon for iterasjon må vi også kunne gi styrings- og beslutningsgrunnlag til ledelsen. Dette kan gjøres på en enkel og intuitiv måte basert på Burn-up charts

Burnup1

 

Planlegging av totalt omfang opp mot dato. Her har vi basert oss på hastigheten til teamet etter tre iterasjoner og ekstrapolert tidspunktet (antall iterasjoner) når et visst omfang vil kunne leveres. Antagelsene her er både at teamets hastighet vil være noenlunde stabil, samt at det ikke vil skje endringer underveis.

 

Burnup2

Det går ikke alltid helt som planlagt. Vi mennesker er notoriske optimister og vi undervurderer vanskeligheter ganske systematisk. Og uventede ting kan dukke opp.

I figuren ser vi at teamet av en eller annen grunn har fått lavere hastighet i de neste to iterasjonene. Vi må med andre ord justere planen så den igjen harmonerer med virkeligheten slik den ser ut nå.


Vi kan nå velge mellom to onder.
Skal vi holde fast på omfanget og få en utsettelse på 2 sprinter, eller skal vi BurnUp3redusere omfanget og holde fast på leveransetidspunktet? Dette er vurderinger som må gjøres fra gang til gang. Vær forberedt på at dette må gjøres ofte. Det foretrukne valget vil med smidige prinsipper til grunn være å redusere omfang. På den måten vil vi kunne holde fast på leveransetidspunktet, men enda viktigere: vi vil fjerne
den delen av omfanget brukerne kan klare seg foruten. Kanskje det er noe i dette omfanget som vi faktisk ikke trenger å lage? Det vil i så tilfelle være svært nyttig å finne ut dette så tidlig som mulig!

Husk også å holde en overordnet Road Map oppdatert for å ikke miste det langsiktige perspektivet.

Fortløpende læring

Skal vi lykkes med kunnskapsarbeid må planlegging kombineres med læring.

Hver gang vi fullfører et produktinkrement vil vi få en anledning til å sammen med brukerne reflektere over resultatet og å benytte dette til å få ideer og å justere planen. Å justere planen vil i praksis bety å modifisere produktkøen gjennom å

  • justere på enkelte elementer
  • erstatte elementer med andre
  • fjerne elementer
  • legge til elementer

I ytterste konsekvens vil analysen av et inkrement kunne få dramatiske konsekvenser. Kanskje vi oppdager at viktige antagelser ikke er tilstede? Kanskje vi må justere selve visjonen? Kanskje vi må skrinlegge hele satsningen og heller bruke kreftene på andre lovende saker i porteføljen?

Gjennomføring

Gjennomføre

Hensikten med dette er å realisere planlagte løsninger og å lære av resultatene.

Når man lager IT-systemer med smidige metoder er det store krav til høy håndverksmessig standard. Både utviklings- og drifts-miljøet må legges til rette for hyppige leveranser. Dette innebærer at

  • kontinuerlig integrasjon må være på plass og i størst mulig grad være “ende-til-ende”
  • enhetstest må automatiseres
  • testdrevet utvikling (TDD) er foretrukket
  • clean code er et godt ideal
  • systemnivå tester (som akseptansetest) må også i størst mulig grad automatiseres
  • drift og utvikling kan ikke leve i hver sin virkelighet og må i størst mulig grad jobbe tett sammen (gjerne “DevOps”)

Martin Fowler beskriver her et godt utgangspunkt for å adressere disse tingene.

Smidig utvikling krever også at arkitektur- og designarbeidet pågår kontinuerlig og at vi tillater at også strukturen på systemet utvikler seg over tid. Refaktorisering av både kode, design og arkitektur bør være en naturlig del av utviklingshåndtevrket.

Høy teknisk gjeld kan være et svært stort hinder for å lykkes. Vi må altså hele tiden være sikre på at utviklingsteamet både har kompetanse nok og ikke minst tid nok til å holde en høy standard på arbeidet som gjøres. Selv om tidspresset har en tendens til å bli svært følbart innen IT-utvikling må man klare å holde hodet kaldt og være tålmodig nok til at vi ikke ofrer det solide, gode håndverket. Med Scrum skal teamene ha en Definition of Done, som er en kortfattet beskrivelse av tilstanden til et produktinkrement når teamet er ferdig med den. Denne vil da tjene som en slags definisjon av håndverket til dette teamet, og vil gjøre produkteier i stand til å beslutte om et inkrement skal idriftsettes eller ikke ut fra rene forretningsmessige hensyn.

Hvordan man gjennomfører selve utviklingsaktivitetene vil ikke denne veilederen gå i detalj på. Det som er viktig her er å skape gjennomsiktighet, slik at interessentene hele tiden er oppdatert på hvordan progresjonen er.

Bruker man Scrum vil produkteier til enhver tid være oppdatert på hva teamet jobber med i inneværende iterasjon, hva som sannsynligvis kommer i de neste sprintene og kunne vise en langtidsplan gjennom en oppdatert road map. Her er en enkel håndbok i Scrum.

Bruker man Kanban, vil man typisk ha en tilsvarende rolle som produkteier som vil ha den samme informasjonen. Den største forskjellen på Scrum og Kanban er at kanban ikke har like veldefinerte roller og at iterasjonene (tidsboksene) ikke er like tydelige. I Kanban vil man hele tiden bestrebe å stadig komme raskere igjennom ende-til-ende prosessene.

Gevinstrealisering

Realisere

Hensikten med denne aktiviteten er som navnet tilsier å realisere de planlagte gevinstene. Men smidig gjennomføring vil nødvendigvis disse gevinstene komme gradvis og løpende. Det dreier seg om å evne å ha en tett, god dialog med brukerne og spisse innsatsen mot det som gir antatt størst gevinst.

Tilgjengeliggjøring

ShipItEn iterasjon bør i størst mulig grad ende opp med et produktinkrement som på alle tekniske måter er leveranseklart. Ideelt sett skal produkteier selv kunne trykke på den knappen som automatisk leverer inkrementet ut til brukerne.

De mest avanserte organisasjonene har laget seg muligheter til å levere til et utvalgt kundesegment, slik at de kan analysere mottagelsen i en begrenset del av markedet først. Deretter kan man vurdere om disse likte det såpass godt at det er verd å levere det ut i full bredde. (Her kan det være lurt å vurdere Feature Toggles og A/B testing)

Husk at alle smidige team vil forsøke å levere så ofte som det er mulig å få det til. Dette må vurderes opp mot arbeidsmengde, risiko og hva kundene ønsker – men i utgangspunktet er Kontinuerlig leveranse (Continuous delivery) et ideal.

Bruker man Scrum vil man akkumulere opp et helt produktinkrement som da blir den endelige leveransen fra en iterasjon (Sprint). Det er ikke nødvendig å se på dette som en begrensning i forhold til leveransefrekvens. Mange Scrum team vil levere mange små inkrementer underveis i en iterasjon.

Gevinstmålinger

Gitt at Gjennomføringen går som planlagt og endringer har materialisert seg for brukerne. Da gjelder det å forsøke å finne svaret på slikt som “likte de det?” og “bringer dette oss nærmere det langsiktige målet?”.

Hvis en vesentlig del av visjonen (det langsiktige målet) for eksempel er “øke andelen elektroniske innsendinger” vil vi måtte finne ut hvordan vi kan måle at vi beveger oss i riktig retning. Vi må finne ut hva som er tilstanden i dag, hvilken målsetning vi har, og ikke minst hva slags data vi kan bruke og hvordan vi skal samle disse. På dette området kan metodene til Tom Gilb være til stor hjelp. Dette handler om å kvantifiser og bryte ned mål, samt å styre mot størst mulig verdi. Disse metodene har vært viktige for Gojko Adzic når ha utviklet Impact Mapping. Med impact mapping vil man få hjelp til å identifisere de viktigste interessentene og hvordan man kan bryte ned overordnede mål i konkrete leveranser og målinger.

Om man bryter ned målet om å øke andelen elektroniske innsendinger, kommer man ganske sikkert til et delmål om at tjenesten må være intuitiv og brukervennlig. Så spørsmålet da blir jo “hvor intuitiv og brukervennlig oppfatter brukerne den i dag?” Dette kan måles på ulike måter. En måte er opplagt å forsøke å spørre brukerne i brukerundersøkelser. En annen måte er å logge brukeradferd og finne ut om hvor mange klikk de behøver og hvor mange som gjør det på en optimal måte og ikke minst hvor mange som går seg vill og gir opp.

Bemerk: Mange ting lar seg måle på en fornuftig måte, men vi må være forsiktige så ikke slik målstyring fører til at vi bruker for mye tid og energi på dette. Og vi må være trygge på at det vi måler faktisk er det som betyr mest. Historien er full av eksempler på at overdreven målstyring får utilsiktede konsekvenser. Ofte fordi vi skaper fokus på det som er målbart – som ikke nødvendigvis er det som er viktigst. Kvalitet er ofte vanskelig å måle, og vil lett komme tapende ut fordi vi fokuserer for mye på lett målbare ting som tid og penger. Når det knyttes belønning til måloppnåelse er det virkelig fare på ferde. Om ansatte på et call-senter måles på saksbehandlingstid klarer de ganske lett å presse ned tiden – med den konsekvensen at saken ikke blir skikkelig avsluttet og dukker opp på nytt og fører til misfornøyde kunder og ytterligere belastning på systemet.

 

 

Leave a Reply

Your email address will not be published. Required fields are marked *

*