Digipost produktutvikling

Transkript

1 Produktutvikling

2 Digipost produktutvikling Bakgrunn Abstrakt produktutvikling, som utvikling av programvare, blir ofte forbundet med høy kompleksitet og tilhørende risiko. Ofte ser vi at desto mer omfattende en løsning skal være, desto mer omfattende blir også utviklingsprosessen. Resultatet blir g jerne en omfattende og byråkratisk prosess med lange beslutningsprosesser, treg fremdrift og kanskje også en dårlig løsning. Det kan være en løsning som ikke dekker behovet, ikke yter godt, har dårlig sikkerhet eller i verste fall en kombinasjon av disse. Basert på denne kunnskapen tilstreber Posten Norge AS i Digipost en smidig produktutviklingsprosess som dekker Postens forretningsbehov, tilfører verdi for alle som bruker Digipost, som løser våre behov for stabilitet, oppetid, sikkerhet og ytelse, samtidig som løsningen er fleksibel nok til å endres i tråd med endrede behov. Et av våre overordnede mål er å utarbeide en løsning som alle involverte parter benytter fordi de har lyst og ikke fordi de må. Dette dokumentet beskriver den smidige produktutviklingsprosessen i Digipost og hvordan vi arbeider for å nå nevnte mål.

3 Hva er Digipost? Digipost er en nettbasert tjeneste fra Posten som tilbyr alle innbyggere og virksomheter i Norge mulighet for sikker digital kommunikasjon og distribusjon av alle dokumenttyper. Posten har mer 367 års erfaring i fysisk postdistribusjon og etablering av en fleksibel infrastruktur som skalerer fra de de minste sendingene til de største. Da vi startet utviklingen av Digipost, manglet Norge en infrastruktur for digital kommunikasjon mellom offentlig sektor, privat næringsliv og innbyggere. Med lanseringen av Digipost har vi lansert en fleksibel og skalerbar tjeneste som ivaretar de varierte behovene disse gruppene har. De grunnleggende behovene som løses er: At avsender er sikker på at mottaker er den mottaker gir seg ut for å være At mottaker er sikker på at avsender er den avsender gir seg ut for å være At ingen på veien mellom avsender og mottaker får innsyn i kommunikasjonen mellom dem Gjennom en registreringsprosess sikrer vi at både privatpersoner og virksomheter blir identifisert og gis tilstrekkelig autorisasjonsnivå for sending og mottak av post. På denne måten sikrer man at både avsender og mottaker faktisk er den det utgis seg for å være. Både transportkanal og innhold er kryptert for å forhindre uautorisert innsyn i det som kommuniseres og lagres g jennom Digipost. Digipost er ikke en konkurrent til e-post, men utfyller e-post på de områdene der e-post anses som uegnet, blant annet for utveksling av informasjon som inneholder personsensitive opplysninger. Digipost reduserer således utfordringene med blant annet phishing, søppelpost, virus og avlytting av kanalen.

4 Møt menneskene Digipost er en avdeling i Posten som består av ca. 25 dedikerte personer med kompetanse innen utvikling, drift, databaser, integrasjoner, utviklingsmetodikker, interaksjonsdesign, sikkerhet, arkitektur, forretningsutvikling, økonomi, salg og markedsføring. I tillegg har vi eksterne ressurser som tar hånd om drift og infrastruktur. Disse 25 personene er inndelt i to grupper. Salg/marked har omlag 10 personer og utvikling har 15. Utviklingsteamet er et kryssfunksjonelt, selvorganiserende smidig-team som selv fordeler oppgaver, håndterer parprogrammering, testing, akseptanse og produksjonssetting. Utviklerne av Digipost snakker regelmessig på konferanser i inn- og utland. Eksempelvis var vi representert med hele fem Digipost-utviklere til å snakke på JavaZone 2012, både om utviklingsmetodikken og om teknologivalg vi har g jort.

5 Utviklingsprosessen På overordnet nivå g jennomgår en funksjon flere faser i produktutviklingen, helt fra den oppstår som idé til den er produksjonssatt og tilg jengeligg jort for brukeren. I Digipost har vi identifisert disse som følger: Nye ideer Nye ideer kan komme fra flere aktører, blant annet Brukere Kunder Partnere Interne (utviklere, medarbeidere) I Digipost har vi flere kanaler for å kommunisere med disse aktørene, for eksempel via Posten Beta, Facebook, Twitter og Posten kundeservice. En ny idé kan også bli definert som et forbedringsforslag av en eksisterende funksjon. Et slikt forbedringsforslag kan være planlagt som en påfølgende release som ikke inngikk i den initielle versjonen, eller være en helt ny idé. Selv om videreutvikling av ideer ofte

6 avdekkes i analysefasen, ser vi at det over tid også kommer opp nye ideer underveis i utvikklingsprosessen. Analyse I analysefasen analyseres alle ideer. Som et første steg vurderer vi hvorvidt en idé er relevant for vår forretningsmodell, våre forretningsmål og vår forretningsstrategi. Ofte forkaster vi gode ideer fordi de ikke passer inn i vår forretningsmål, oppfyller våre forretningsmål eller forretningsstrategien. Andre ganger parkeres ideer dersom vi tror de kan bli relevante på et senere tidspunkt. I denne fasen er det også viktig å anerkjenne at ikke alle ideer er gode, og dermed blir forkastet. Dersom en idé blir vurdert til å være i samsvar med (allignment) vår forretningsmodell og våre forretningsmål vurderes verdien av ideen. En verdivurdering trenger ikke være økonomisk, men økonomi er også en del av verdivurderingen. Verdi kan også være funksjonalitet som er nyttig for dem som vil bruke løsningen, uten at det nødvendigvis vil være betalingsvilje. Vi vurderer hvem ideen gir verdi for. Følgende aktører kan få tilført verdi av en idé:

7 En optimal idé gir verdi er indikert med «Sweet Spot» hvor alle aktører får tilført verdi g jennom ideen, men det skjer svært sjelden. Oftest arbeides det med funksjoner som tilfører minst én av aktørene verdi. Utfordringen består i å vurdere hvor mye verdi en idé tilfører. Slike vurderinger skjer etter forskjellige metoder. Enkle ideer krever mindre arbeid å analysere og kan avg jøres utelukkende basert på erfaring og kompetanse. Mer komplekse ideer er g jenstand for metodisk evaluering, det blir utarbeidet business case og konseptutredning g jennomføres. I denne prosessen involveres som oftest både produkteier, en forretningsutvikler, teknisk arkitekt og en utvikler. Felles for alle ideer er at det utarbeides en spesifikasjon når man er enige om hvordan ideen skal realiseres. Spesifikasjonen er grunnlaget utvikleren arbeider etter når ideen utvikles i Digipost. En slik spesifikasjon g jøres så enkel som mulig, både for å spare tid og redusere kompleksitet. Utvikleren har g jerne bidratt i deler av analysefasen og har derig jennom god forståelse av hva som skal utvikles. Når spesifikasjonen utarbeides fastsettes det alltid et scope, det vil si en avgrensning av oppgaven som skal utføres. Vi vektlegger å g jøre oppgaven så liten som mulig, og ser på hvor liten den kan være samtidig som den gir verdi. Relaterte oppgaver vi ønsker å g jøre, men som er utenfor scope, defineres som nye ideer. Hvorfor lansere noe som er uferdig? Resultatet er at vi ofte lanserer noe som oppleves som uferdig. Ikke fordi det ikke fungerer etter hensikten eller har feil, men fordi den initielle versjonen av en funksjon ikke har all funksjonalitet tilg jengelig fra starten av. Alternativet er å utvikle alt «ferdig» før lansering. Fordelen med vår tilnærming er at vi får produksjonssatt og testet ut funksjonaliteten tidlig med ekte brukere, slik at vi kan samle tilbakemeldinger og utføre eventuell feilretting tidlig og med lavere risiko. I tillegg gir funksjonen umiddelbar verdi for en lang rekke brukere, selv om ikke alle får fullt utbytte av den umiddelbart. Derfor er vi også fokusert på å kommunisere dette til de som skal benytte funksjonen, slik at de vet at det kan komme utvidelser over tid. Samtidig anerkjenner vi at enkelte funksjoner er av en størrelse som krever utvikling over lengre tid. Tilsvarende kan det være at vi ønsker å produksjonssette funksjonalitet uten å g jøre den tilg jengelig for brukerne. Derfor har vi utviklet funksjonalitet for «feature toggling», slik at vi kan skru funksjonalitet på kun for utvalgte brukere.

8 Labs I Digipost benytter vi Digipost Labs, vårt laboratorium for dialog med våre brukere. Her kan brukerne komme med forslag og ideer, og vi kan diskutere våre ideer med brukerne. Konklusjonene trekker vi rett inn i Input Board dersom vi velger å g jøre noe med et forslag. Vi har også egne alfa- og betaversjoner av Digipost, tilg jengelig på henholdsvis digipost.no/alfa og digipost.no/beta. Disse kan skrus av og på ved behov, slik at vi kan slippe på brukere for å teste funksjonalitet i perioder vi selv ønsker det. BETA Sikkerhet Sikkerhet er et av Digiposts viktigste verdiforslag. Digipost tilbyr en sikker kommunikasjonskanal fra avsender til mottaker, samt sikker oppbevaring av post. For å ivareta denne sikkerheten i utviklingsprosessen, blir risikoanalyse og sikkerhetsvurdering foretatt for hver eneste idé i analysefasen. I Digipost arbeides det med et styringssystem for sikkerhet etter standardene ISO/IEC og ISO/IEC Dette arbeidet definerer akseptable nivå for risiko, hvor vi tåler feil og hvor vi er intolerante for feil. Universell utforming Universell utforming er et annet aspekt av spesifikasjonsarbeidet. Med hele Norges befolkning og bedrifter som målgruppe, er det spesielt viktig med en løsning som er universelt utformet og tilrettelagt for brukere med spesielle behov, for eksempel blinde og svaksynte. I analysefasen vurderes hvilke hensyn som må tas spesielt for universell utforming. Prioritering Når en idé er ferdig spesifisert er den g jenstand for prioritering. I Digipost avholdes det ukentlig et grooming-møte, hvor ideer prioriteres opp mot hverandre og opp mot forretningsstrategien. Det er produkteier som arrangerer grooming og er ansvarlig for prioritering. Ideer diskuteres og prioriteres kontinuerlig, mens grooming-møtene fungerer som overordnet arena for diskusjon mellom leder av Digipost, produkteier, teknisk arkitekt, tech lead for utviklingsteamet og en forretningsutvikler. Resultatet er

9 en backlog som er g jenstand for kontinuerlig prioritering, hvor ideer kan flyttes til og fra eller opp og ned i backlog-en hvis prioriteringene endrer seg. Utvikling En av de viktige konseptene i utviklingsarbeidet er hvordan vi benytter pull i stedet for push. I stedet for å dytte en oppgave på en utvikler eller utviklingsteamet, er det utvikleren selv som plukker den høyest prioriterte oppgaven fra backlog-en idet utvikleren er ledig for nye oppgaver. Utvikleren følger oppgaven helt fra backlog-en g jennom utvikling, testing, verifisering, akseptanse og produksjonssetting. Dette gir en jevn flyt g jennom utviklingsprosessen og reduserer stress i teamet. På denne måten samler vi heller ikke opp oppgaver i en stor release, for eksempel slik man g jør i Scrum, men produksjonssetter idet oppgaven er ferdig. Leveranse Med en slik utviklingsprosess med kontinuerlige leveranser, betyr det også hyppig produksjonssetting. Denne smidigheten hadde ikke vært mulig dersom vi måtte ta løsningen ned hver gang vi produksjonssetter ny funksjonalitet. Derfor har vi utviklet Digipost til å kunne produksjonssette ny funksjonalitet uten å ta løsningen ned, noe vi har skrevet mer om i bloggen. Håndtering av risiko Det er flere måter å måle risiko på, for eksempel arbeidet som følger ISO-standardene ISO/IEC og ISO/IEC 27002, som tidligere beskrevet. Men risiko kan også måles i langt mer subjektive oppfatninger. Er det en risiko for at brukerne ikke liker tjenesten vi har laget? Er det en risiko for at det vi lanserer ikke er i overensstemmelse med brukernes forventninger? Er det en risiko for at bugs ødelegger brukeropplevelsen? Listen over feil man kan begå er nærmest uendelig når man bedriver programvareutvikling. Under avsnittet «Hvorfor lansere noe som er uferdig?» beskriver vi hvordan vi bevisst arbeider med å lansere små mengder funksjonalitet om gangen. Jo mindre som settes i produksjon om gangen, jo bedre kan vi konsentrere oss om at den faktisk fungerer etter hensikten. Vi liker å sammenlikne det med vann som renner i en elv: lar man vannet renne fritt og uhindret finner det selv veien det alltid har g jort, uten å g jøre skade. Men demmer man

10 opp vannet over tid, for plutselig å slippe ut alt på én gang, er det større risiko for at vannet på sin videre vei g jør utilsiktet skade som krever ekstra fokus for å utbedre. Tilsvarende fungerer også produktutviklingen i Digipost: vi samler aldri opp større mengder funksjonalitet som produksjonssettes på én gang, men vi produksjonssetter det heller når utviklingen er ferdig og funksjonaliteten holder tilstrekkelig kvalitet. Et annet viktig grep vi g jør for å redusere subjektiv risiko er å prototype svært tidlig. Som oftest har vi med en interaksjonsdesigner i de innledende samtalene om ny funksjonalitet, hvorpå interaksjonsdesigneren utarbeider en prototyp. Dette skjer g jerne direkte i utviklingsmiljøet med HTML, CSS og JavaScript, slik at vi får en bedre virkelighetsforståelse av hvordan det faktisk vil oppleves. Gjennom dette arbeidet ser vi ofte hvordan den foreslåtte funksjonaliteten kan ta en helt annen retning enn det vi opprinnelig hadde tenkt oss. Bruk og utvikling av fri programvare Digipost er for det vesentligste utviklet med og av anerkjente frie programvarekomponenter. Fri programvare gir flere fordeler vi anser som vesentlige: Økt sikkerhet Økt stabilitet Økt ytelse Transparens i programvaren Anledning til å tilpasse programvaren til egne behov Kortere utviklingstid og raskere leveranser Eierskap til egen løsning Spesielt sikkerhet, stabilitet og ytelse er viktige argumenter for vår strategiske satsing på bruk av fri programvare i Digipost. Fri programvare gir full tilgang til kildekoden programvaren Digipost er bygget opp av, hvilket lar oss etterprøve at programvaren utfører de funksjoner den hevder at den skal, og at den i tillegg ikke utfører utilsiktede eller uønskede handlinger. I tillegg har denne programvaren god og etterprøvbar sikkerhetshistorikk. Tilsvarende er god stabilitet og ytelse vesentlig for en tjeneste som Digipost, som krever spesielt høy grad av tilg jengelighet og rask responstid for alle involverte brukere, enten det er avsendere eller mottakere av post. Det benyttes anerkjente komponenter som over tid fungerer stabilt med lite behov for løpende vedlikehold.

11 I tillegg til å benytte fri programvare i utstrakt grad, leverer vi også Digipostkomponenter som fri programvare. Dette er komponenter som avsendere eller mottakere av post fritt kan laste ned fra Digiposts nettsider, og som er ferdig programvarekode som kan integreres i avsenders eller mottakers fagsystem. Dette er g jennomtestet og ferdig kode klar til bruk, som reduserer påkoblingstid, risiko og kompleksitet i integrasjon mot Digipost. Da vi startet utviklingen av en Android-app for Digipost, ble det besluttet å g jøre hele utviklingen som et rent fri programvareprosjekt. All kode, både for Android og andre Digipost-komponenter, er tilg jengelig på Digiposts GitHub-konto, github.com/digipost. Bugs vs. ny funksjonalitet En hver utviklers ultimate mål er en løsning fri for bugs. Digipost er intet unntak. Imidlertid er bugs en uunngåelig konsekvens av programvareutvikling. Et viktig tiltak for å redusere mengden feil er som tidligere nevnt en strategisk beslutning om bruk av fri programvare (open source) så langt det lar seg g jøre. Gjenbruk av eksisterende, velprøvd kode gir raskere leveranser med høyere kvalitet enn om vi skulle skrevet alt selv. Et dilemma alle produkteiere kjenner godt er hvordan man prioriterer bugfiksing opp mot utvikling av ny funksjonalitet. Ny funksjonalitet tilfører produktet mer verdi, men også flere bugs og dermed større teknisk g jeld. Bugfikser, derimot, reduserer teknisk g jeld men tilfører ingen ny forretningsmessig verdi. Det finnes ikke et godt svar på hvordan man fordeler tilg jengelige ressurser på bugfiksing eller nyutvikling det avhenger både av alvorlighetsgraden på bugs og verdien på ny funksjonalitet i backlog. I perioder arbeider hele teamet med nyutvikling, men da sørger vi alltid for å følge opp med en periode umiddelbart etterpå hvor vi reduserer teknisk g jeld. En viktig tommelfingerregel er uansett at vi skal ha kontroll på teknisk g jeld. Gror teknisk g jeld for stor blir den ukontrollerbar og man benytter langt mer ressurser på å ta den ned enn om man kontinuerlig vedlikeholder den. Kanban Boards Når man til enhver tid har flere hundre ideer i prosess, enten det er ideer parkert i påvente av fremtidig realisering, eller ideer som er klare for produksjonssetting, er det viktig med et godt verktøy som bygger opp under smidigheten i utviklingsprosessen

12 samtidig som verktøyet ikke impliserer mer arbeid enn nødvendig. Til formålet benytter vi i Digipost elektroniske boards, kjent fra Kanban. Vi har flere forskjellige boards, avhengig av hvor en idé befinner seg i utviklingsprosessen, som reflekterer prosessene omtalt over. Alle ideer, enten det er nye ideer eller forbedringsforslag, puttes inn i et board vi kaller «Input Board». Dette boardet består av en kolonne kalt «Nye ideer», samt flere kolonner hvor hver kolonne representerer verdi for aktørene omtalt tidligere. Alle nye ideer dumpes i «Nye ideer», deretter er det produkteiers oppgave å håndtere dem videre for vurdering, analyse og prioritering. Alle ideer blir liggende på Input Board inntil de blir prioritert for videre arbeid. Når en idé tas videre, flyttes den fra Input Board til «Produkt-board». Her ligger også flere kolonner for analyse, backlog, pågående utvikling, testing og akseptanse. Det er her det endelige spesifikasjonsarbeidet fullføres, før ideen flyttes til prioritert backlog. Deretter tar en utvikler tak i høyest prioritert idé straks utvikleren er ledig.

13 Når utvikling, test og akseptanse er ferdig, flyttes ideen til et nytt board for produksjonssetting. Her er det kolonner for hvert versjonsnummer av Digipost. Som oftest produksjonssettes det flere ideer samtidig, i snitt to ganger i uken. Utprøvde metodikker I det innledende arbeidet med Digipost ble det benyttet Scrum som prosjektmetodikk. Imidlertid gikk vi vekk fra Scrum, ettersom sprintene som Scrum medfører krever mer planlegging enn hva som er ønskelig. Det krever et stykke arbeid for å planlegge hva som skal inn i en sprint, og bommer man på estimatene er resultatet frustrasjon, enten over å ikke rekke sprinten eller frustrasjon over å ikke estimere riktig. I arbeidet med å forbedre prosessen ble det vurdert alternative metodikker, hvor Kanban hadde interessante elementer vi ønsket å benytte i utviklingsprosessen. Sammenlikning med andre metodikker Utviklingsmetodikken i Digipost har mange fellestrekk med kjente prosjektmetodikker som Scrum, Kanban og CONWIP. Her lister vi noen essensielle elementer fra Scrum og Kanban, og sammenlikner disse med hvordan Posten løser det i utviklingen av Digipost. Time-boxing I Scrum opererer man med time-boxing, mens det er frivillig i Kanban. I Digipost opererer vi ikke med time-boxing, da det tilfører utviklingsprosessen et byråkratisk planleggingselement. Det er ikke ønskelig å bruke tid og ressurser på å planlegge alt som skal inngå i en sprint (time box). I stedet ønsker vi å bruke ressursene på fortløpende utvikling og produksjonssetting straks en funksjon er ferdig. En begrensende faktor fra Scrum er at det ikke skal legges til oppgaver i en pågående sprint. Fra Kanban benytter vi i Digipost prinsippet om at oppgaver påbegynnes straks det er ledig kapasitet. Estimering og planlegging I Scrum benyttes fremdrift i utviklingen for planlegging, hvor estimering er obligatorisk, mens Kanban benytter ledetider og estimering er frivillig. I Digipost er estimering frivillig, men ofte opereres det med grovestimater for hver funksjon, som kan benyttes i planleggingsarbeidet. For større oppgaver som henger sammen med andre oppgaver er dette viktig.

14 Organisering av team Scrum beskriver kryssfunksjonelle team som obligatorisk, mens det er frivillig i Kanban. I Digipost opereres det med kryssfunksjonelle team, men med spesialiserte fagområder innen blant annet sikkerhet, drift, ytelse, forretningsutvikling, interaksjonsdesign og arkitektur. Størrelse på funksjonalitet I Scrum skal funksjoner alltid brytes ned i biter som er små nok til at de kan leveres i én sprint, mens Kanban ikke stiller krav til slike størrelser. Ettersom Digipost ikke opererer med sprinter eller time-boxing, er det naturlig nok ingen krav til at en funksjon skal passe inn i en sprint. Imidlertid fokuserer vi på å bryte ned hver funksjon til en minimumsenhet som gir verdi for den som skal bruke funksjonen, som beskrevet tidligere. Burndown Charts Scrum beskriver obligatorisk bruk av Burndown Charts tilknyttet sprinter for å måle hvorvidt man treffer estimatene for inneværende sprint. Dette er også en medvirkende årsak til at vi i Digipost ikke benytter sprinter, da det vil gi merarbeid for å vedlikeholde Burndown Charts og enda mer arbeid for å bryte ned funksjoner i små nok biter til å passe inn i en sprint. WIP WIP (Work In Progress) er et prinsipp fra Kanban, hvor man begrenser WIP ut fra hvilke oppgaver man tilfører arbeidsprosessen. I Scrum begrenses WIP til hver sprint. Ettersom vi ikke opererer med sprinter eller time-boxing i Digipost, tilstreber vi alltid å begrense WIP til færrest mulig oppgaver. Alle utviklere arbeider ideelt sett kun med én oppgave om gangen. Straks en utvikler blir ledig, plukker utvikler en ny oppgave fra «Ready to pull». Prinsippene har fellestrekk med CONWIP. Backlog vs. Kanban Boards I Scrum opereres det med Backlog som eies av et team, mens det i Kanban opereres med Boards som kan deles av flere team eller enkeltpersoner. I Digipost opererer vi med forskjellige boards som alle eies av produkteier (Product Owner). Alle forslag til nye ideer

15 puttes inn i Input Board, hvor produkteier kategoriserer og prioriterer alle innkommende forslag fortløpende i egne kolonner. Når en idé vurderes klar til utvikling, trekkes den opp til Product Board for detaljert analyse, spesifisering, konseptutredning og eventuelt utarbeidelse av business case. Dersom resultatet av dette innledende arbeidet viser seg å ikke gi ønsket resultat, forkastes ideen. Dernest flyttes oppgaven videre til en prioritert kolonne «Ready to Pull», hvor en utvikler tar tak i oppgaven straks hun eller han er ledig. Straks oppgaven går fra «Ready to Pull» til «Doing» er det utviklingsteamet som eier oppgaven helt til den blir produksjonssatt. Her inngår også verifisering og akseptanse. Det benyttes et eget board for produksjonssetting for håndtering av versjonsnummer. Der en sprint backlog i Scrum nullstilles ved slutten av hver sprint, arbeider vi i Digipost etter Kanban-prinsippet om at alle boards er persistente, og at det kun er oppgaver som flyter kontinuerlig g jennom boards som beskrevet over. Roller Scrum beskriver tre roller, Product Owner, Scrum Master og Team, mens Kanban ikke beskriver noen roller. I Digipost opererer vi med Product Owner og Team. Releaseplanlegging og prioritering I Scrum opererer man med prioritert backlog og en releaseplan som speiler denne, mens vi i Digipost opererer som Kanban om å prioritere etter JIT-prinsippet (Just in time). En oppgave spesifiseres først fullt ut idet den blir prioritert for utvikling. Tilsvarende stilles det i Digipost ingen krav til å ha alt ferdig spesifisert før oppstart av en oppgave, det kan endre seg underveis i utviklingen. I eldre og mer tradisjonelle prosjektmetodikker operer man med en releasekalender som utarbeides før man går inn i et nytt år. Kalenderen skal gi alle involverte parter informasjon om når man skal produksjonssette ny funksjonalitet i løsningen. I Digipost operer vi naturlig nok ikke med verken releasekalender eller langtidsplanlegging av hvilken funksjonalitet som skal inn i en gitt release langt frem i tid. Vi opererer på forretningssiden med langsiktige prioriteringer, men de påvirker aldri utviklingsteamet.

16 Hack Days Hack Days er et konsept vi har adoptert fra andre miljøer. 25 mennesker som daglig arbeider tett på et produkt får ofte ideer som de ikke finner anledning til å realisere. Derfor arrangerer vi i Digipost uregelmessige Hack Days hvor både utviklere, forretningsutviklere, salg og marked arbeider på egne ideer og prosjekter relatert til Digipost. Resultatet av slike Hack Days er aldri produksjonsklar kode, men kode som fungerer godt nok til at det fungerer som en Proof of Concept. Mye av statistikkskjermene vi benytter i Digipost er utviklet på Hack Days, det samme er Android-app-en og flere fri programvarebiblioteker. Vi har også en fullt fungerende klient for å synkronisere Digipost-arkivet med mapper på lokal datamaskin, omtrent som Dropbox.

17 Oppsummering Å følge en metode er ikke et mål i seg selv. En metode er et verktøy for å nå andre mål. Det er ikke så viktig om man følger metoden, så lenge det gir ønsket resultat. Det viktige er å ha smidighet som raskt lar organisasjonen realisere mål med tilstrekkelig kvalitet, i tillegg til å ha en prosess som er g jenstand for kontinuerlig forbedring. Eller som Henrik Kniberg i Spotify, en av våre kilder til inspirasjon, sier: «So, the important thing isn't your process; the important thing is your process for improving your process» En av de få sikre tingene her i livet er at verden er i konstant endring. Omfatt endringer som noe positivt og bruk mulighetene endringer byr på til å forandre verden. Martin Bekkelund Direktør for produkt- og forretningsutvikling Posten Norge AS mrtn.at/posten