I Reload arbejder vi agilt, fordi vi ønsker at bevare fleksibilitet i de løsninger vi bygger. Fleksibilitet skal bevares for at kunne levere digitale løsninger, som tilfører værdi i virkeligheden og for de mennesker, der bruger dem. Vi skal med andre ord være indstillet på at gå andre veje, når det er nødvendigt, og giver mening.
Samarbejdsmodellen er det framework vi arbejder indenfor, det tager udgangspunkt i den løbende relation, og sikrer at vi arbejder målstyret og valideringsdrevet og fleksibelt med løbende forbedring og udvikling af vores kunders digitale tilstedeværelse.
Modellen muliggører også, at vi meget hurtigt kan komme i gang med at bygge og levere, samtidig med at vi også har plads til at udforske ideer til produkt- eller forretningsudvikling. Den giver os mulighed for at spille på flere strenge imens vi altid har fokus på det, som skaber mest værdi for vores kunder.
Vi tror på, at de løsninger, vi laver sammen med vores kunder, skal udvikle sig kontinuerligt og agilt, og sammen med de mennesker, der bruger dem og har gavn af dem, for at holde trit med virkeligheden. Måden vi kan opnå det på, er ved at agere som ét samlet team med vores kunder, og ved at have en holistisk tilgang. Løsningerne er levende: nogle gange kræver de udvikling i hurtigt tempo og i en komprimeret tidsperiode (mange timer på kort tid), andre gange ikke. Nogle gange med en åben og nysgerrig tilgang, andre gange med en effektiv og eksekverende tilgang.
Vi går helt væk fra planstyret og tidsbegrænset projektudvikling, og arbejder i stedet med målstyret produktudvikling, med et kontinuerligt budget
Tidligere har vi holdt styr på tingene ved at pakke leverancer ind i faser og projekter. Vi har oplevet, at der ofte har været begrænset klarhed omkring forventningerne til hvilke mål, der skulle indfries. Typisk har det været projektbudgettet, der endte med at sætte dagsordenen, snarere end omvendt. Men i en foranderlig verden, som den vi lever i, kan vi ikke vente på adskilte og projektpakketerede strategi- , design-, og udviklingsfaser. Realiteten er, at små og store behov opstår, presser sig på, og bliver irrelevante, før vi når at se os om.
Derfor vil vi udviske grænsen mellem ‘drift’ og ‘udvikling’. Vi går helt væk fra planstyret og tidsbegrænset projektudvikling, og arbejder i stedet med målstyret produktudvikling, med et kontinuerligt budget, der afstemmes efter cost/benefit betragtninger, og en fleksibilitet, der giver mulighed for prompte at tage handling på de behov, som dukker op, efterhånden som virkeligheden omkring os skifter.
Det digitale landskab er komplekst og tæt på umuligt at planlægge meningsfuldt efter. Målet er i stedet, at vi som team har et fælles sprog, så vi altid er fuldstændig klar over, hvorfor vi er i gang med at udvikle hvad, i hvilken rækkefølge det skal ske, og ikke mindst holde et skarpt øje på, om vi så også faktisk lykkes med at skabe den forventede værdi! Vi holder på denne måde gang i en læringscyklus, så der hele tiden bygges produkter, der virker i virkeligheden.
.
Vi arbejder grundlæggende ud fra en målstyret tilgang, fremfor en planstyret.
Det betyder løbende prioritering, indarbejdelse af læring, korte feedback loops og en mulighed for at lægge skinnerne mens toget kører.
Vi arbejder med sideløbende afklaring og implementering.
Vores model rummer vidt forskellige organisationers behov og forskellige niveauer af ‘digital modenhed’, og det er meget forskelligt hvad man som kunde bringer ind i samarbejdet af eksisterende viden og forarbejde. Det vigtige er, at du som kunde er villig til at dele ærligt hvad du har og ved, og gå til opgaverne og samarbejdet med den samme tilgang som os.
En kommune ønsker et nyt website om kulturtilbud i kommunen, som skal erstatte en række nuværende websites.
Kommunen kommer med ‘færdige’ feature ideer. Beskrevet ved en forholdsvis detaljeret kravspec, og et designoplæg. De har løse tanker om målsætning og kontekst, men mangler synlighed og kortlægning af relationer mellem forretningsmål og features, således at de kan foretage meningsfulde prioriteringer.
En fagforening henvender sig med en ide om, at deres medlemmer i højere grad skal kompetenceudvikle sig selv.
Fagforeningen kommer med en idé der går på at ændre deres medlemmers adfærd. De har dog ikke formuleret, hvordan det hænger sammen med deres forretningsmål og strategiske vision eller hvorfor de mener, det er det bedste de kan gøre for styrke deres position i markedet. Idéen i sig selv er heller ikke konkretiseret, og derfor svær at føre ud i virkeligheden.
En ingeniørvirksomhed ønsker at styrke deres Employer Branding og derved få flere velkvalificerede medarbejdere.
Virksomheden kommer med nogle overordnede strategiske forretningsmål for de kommende år, men er ikke klare på hvilke adfærdsændringer hos de forskellige målgrupper, der kunne have størst værdi. Skal de sætte ift. at få bredt kendskabet til dem ud blandt flere potentielle medarbejdere, eller handler det om at flere af dem, der allerede overvejer skal overbevises om at tage kontakt?
Dette er tre eksempler fra virkeligheden, hvor kunden kommer med tre forskellige indgangsvinkler, men mangler de to andre niveauer. Den første kommer med feature-ideer, men har ikke gjort sig klart hvilken adfærd der skal ændres, eller hvilke forretningsmål der reelt er i spil. Den næste har styr på en adfærdsændring, men man både at gøre hvorfor og hvordan klart. Og den sidste har godt styr på forretningsmålene, men har brug for hjælp til at identificere de nødvendige adfærdsændringer og hvordan vi får dem til at ske.
Det smukke er her, at vi i alle tilfælde kan hjælpe med at udfylde de manglende brikker i puslespillet, og derved sørge for at vi har styr på sammenhængene mellem de tre niveauer.
Vi gør en dyd ud af ikke at bruge mere tid end nødvendigt på snak, før vi smøger ærmerne op og producerer. Til gengæld tager vi os nødvendig tid for at sikre, at vi producerer det rigtige.
Før vi kan agere som fælles team, og samarbejde om udvikling af digitale koncepter og produkter, er vi nødt til at have en god forståelse for de præmisser vores samarbejde baseres på.
Vi er nødt til at forstå hvordan din (kundens) organisation virker:
Vi er også nødt til at forstå, hvordan vi organiserer et fælles produktudviklingsteam med fuldt mandat:
Når vi er skarpe på de organisatoriske rammer og præmisser vi arbejder under og har sat det rigtige team til opgaven, skal vi sikre at hele teamet har god indsigt og forståelse for den kontekst vi skal agere i. Teamet skal forstå:
Vi gør en dyd ud af ikke at bruge mere tid end nødvendigt på snak, før vi smøger ærmerne op og producerer. Til gengæld tager vi os nødvendig tid for at sikre, at vi producerer det rigtige. Det er en meget fin balancegang. Processen kan og vil være forskellig fra gang til gang, men målet er altid det samme: At skabe mest mulig værdi for pengene!
Fordi vi arbejder i en foranderlig verden, hvor præmisserne hele tiden ændrer sig, er det vigtigt hele tiden at bevare et målstyret fokus. Hvorfor er det, vi investerer i digital udvikling? Hvad er vores forretningsbehov og mål? Og hvilken værdi forventer vi, at der kommer ud af det i sidste ende?
Nogle gange oplever vi kunder, der kommer med et råt, uløst problem uden konkrete tanker om hvordan eller med hvad, det skal løses.
Andre gange kan de komme med en potentiel forretningsmulighed, eller en konkret idé til en digital løsning, men måske uden at have gjort sig rigtig klart, præcis hvilket problem det ville løse, eller hvilken værdi det ville skabe.
Det kan være vores kunde er en kommerciel virksomhed som i sidste ende ofte har et mål om at tjene flere penge, eller spare flere penge, men det kan også være mere diffuse mål, som en NGO, der vil have mere politisk indflydelse, eller en offentlig institution som gerne vil kunne give borgerne en bedre service.
Vi er nødt til at forstå, hvordan vi bedst kan skabe værdi i sidste ende. Er der uklare mål i spil, arbejder vi på at gøre dem mere klare og målbare. Er der flere mål i spil, arbejder vi på at blive skarpe på prioriteringen.
Løsninger der faktisk virker, som løser et reelt problem, eller udnytter en mulighed til at skabe reel værdi, virker sjældent i isolation. Typisk skal vi have nogle mennesker til at gøre noget anderledes for at skabe en ændring.
Vi har brug for en grundlæggende forståelse for de mennesker, der er i spil, Både en forståelse for de direkte aktører; brugerne. Hvad motiverer og/eller besværliggører deres interaktion med vores digitale produkter? Men også en forståelse for de indirekte aktører, dem som påvirkes af vores digitale udvikling, hvad kan det skabe af følgevirkninger, ringe i vandet, hvis fx ny information bliver tilgængelig, eller manuelle processer overflødiggøres.
Når vi har en basisforståelse for hvorfor vi skal udvikle vores digitale løsninger og hvem det vil påvirke, er vi langt. Men før vi kan begynde at arbejde på udvikling af digitale produkter, skal vi også være enige om grundlæggende produkt-principper, herunder tekniske og designmæssige retningslinier. Det handler både om at skabe en konsistent oplevelse, men i ligeså høj grad om at bevare fleksibiliteten og kvaliteten i et produkt, der kommer til at udvikle sig og forandre sig løbende.
Det er vigtigt at få principperne for design og udvikling klappet af allerede før vi rigtigt rykker, fordi når vi først kommer til at løse konkrete udviklingsopgaver, vil vi arbejde “problemfokuseret” som team, og vil derfor designe løsningen on the fly, samtidig med, at vi udvikler. Vi ønsker ikke at stå med et en flaskehals, hvor der mangler viden om designlinjer, eller hvor nye designs, med hver deres godkendelsesproces, lammer udviklingen med en række “mini-vandfald”s forløb, der sløver fremgang og støjer og forvirrer.
Når vi har en god forståelse for alt det, vi mener danner grundstenen for vores samarbejde med kunder (organisering, strategi og rammer), kan vi strukturere den viden i et fleksibelt roadmap, som kan danne udgangspunkt for planlægningen af vores af samarbejde både i opstarten såvel som løbende.
I forhold til vores egen ressource-planlægning og eksterne afhængigheder må vi planlægge lidt frem, typisk et kvartal ad gangen. Vi kan planlægge samarbejdet i form af discovery sprints eller delivery sprints. Begge dele er i virkeligheden afgrænsede tidsperioder (time boxes), hvor vi arbejder med både design og udvikling. Det er samme team (dog typisk med vægtet timefordeling).
Man skal dog gøre sig klart, at formålet og mindsettet vi arbejder ud fra, er vidt forskelligt for de to typer sprints:
I Discovery sprints arbejdes der divergent, problemer foldes ud. Vi forsøger at forstå virkelighedens mange facetter, vi dræber idéer, udvikler idéer og skaber alternative veje frem med skitser, prototyper og rigtige mennesker.
Output: Svar på high level spørgsmål.
Outcome: Større sikkerhed for at vi vælger den rigtige vej frem.
I Delivery sprints arbejder vi konvergent - vi går i eksekverings-mode. Vi strukturerer, systematiserer, udvikler og leverer færdige, digitale løsninger, der virker, og som har en reel impact i virkeligheden.
Output: Færdige løsninger
Outcome: Reel forretningsværdi
I nogle perioder kan det give mening at køre fuldt på med både discovery og delivery parallelt, og i andre perioder kan der være mere fokus på læring og mindre på eksekvering, og nogen gange kan udviklingen ligge helt i dvale og kun et minimum tid bruges på mere triviel drift og vedligeholdelse.
Lige meget hvilken tilstand, så er det vigtigt, at vi mødes med jævne mellemrum, får en update på virkeligheden, og kigger på det hele ovenfra og ned. Vi skal regelmæssigt genbesøge de antagelser vores roadmap er baseret på, og justere ind i forhold til evt. ændrede forhold i organisation, marked, brugere, eller i teknologien.
En forklaring er nok på sin plads. Vi arbejder vi efter det, vi kalder Dual Track princippet. Her har vi to kontinuerlige sprint-spor kørende. Et Discovery-spor og et Delivery-spor.
Det forklarer vi langt mere om i "Reloads agile proces".
Når vi som team har opnået en grundlæggende indsigt og forståelse for den kontekst vi arbejder i skal vi omsætte vores viden til et konkret roadmap med eksekverbare to-dos, som samtidig sikrer at vi hele tiden holder et målstyret fokus. Vi bruger metoden Impact mapping til at bygge det roadmap, som vores løbende samarbejde tager udgangspunkt i.
Som kunde investerer du ikke i et samarbejde med os, uden at forvente at få noget igen. Øget forretningsværdi, enten i kroner og ører, eller i en mere diffus form for værdi. Det er også et faktum, at hverken kodelinier eller produktet ændrer noget i sig selv. For at produktet skal lykkes med at opnå mere værdi, er der i sidste ende nogle mennesker, som skal agere anderledes end de gør i dag.
Et Impact Map har netop til formål, at kortlægge sammenhænge mellem præcis hvilke forretningsmål og værdi vi arbejder henimod, med præcis hvilke konkrete adfærdsændringer som kan skabe den værdi, og igen med præcis hvilke features/digitale løsninger, der kan understøtte disse adfærdsændringer. I virkeligheden skaber vi impact map strukturen ved at spørge “Hvorfor?” og “Hvordan?” tilpas mange gange.
Vi kortlægger de tanker og vores konkrete viden om de behov og idéer, som er i spil, så vi sammen kan vurdere risici, og opdage eventuelle svagheder i bagvedliggende antagelser.
OBS: Det er altså IKKE formålet at finde alle de gode idéer og validere alle antagelser up front. Men blot at få indsamlet og struktureret relevant viden, og derigennem få kortlagt, hvordan landet ligger lige nu: Er der valide idéer med klare formål, som er mere eller mindre klar til at blive ført ud i virkeligheden, eller står vi overfor en mere åben proces, hvor de gode idéer først skal frem i lyset, eller hvor vi skal bruge mere indsigt til at validere dem?
Det er en øvelse som vi genbesøger jævnligt. Typisk en gang i kvartalet vil vi insistere på at få en highlevel update på vores grundlæggende forståelse: Er der eksterne forandringer vi skal være opmærksomme på? Hvad har vi lært siden sidst, og hvordan performer de løsninger vi allerede har sluppet ud i verdenen?
Et impact map hjælper os til at arbejde eksplorativt. En digitalt produkt skal typisk løse en række situationer, og består typisk af en lang række del-løsninger, måske kaldet “touchpoints” eller “features”. Frem for at strukturere arbejdet i projektfaser, der afgrænser hvornår vi er i “discovery mode” og hvornår vi er i “delivery mode” med hele produktet på en gang, så kan vi arbejde mere fornuftigt med undersøge de ønsker og idéer nærmere, som kalder på det, mens vi går i gang med at udvikle andre.
Vores kunder kommer til os med vidt forskellige tilgange og styrker. Nogle kommer til os mens helt overordnede behov og problemer stadig står alene, uden overvejelser om mulige digitale koncepter og løsninger. Discovery arbejdet er derfor helt forventet.
Andre kommer til os med tæt på færdige koncepter beskrevet med en række krav og ønsker. De slipper ikke for Impact-mapping processen. Kan vi kan se, at det er idéer med rimelig valide bagvedliggende antagelser, så er det bare at komme i gang med at udvikle. Nogen gange kan der også være en “time to market faktor” som betyder man er villig til at satse i forhold til diverse antagelser, mod at få løsningen hurtigt ud på markedet.
Ikke sjældent ser vi dog en række meget konkrete løsningskrav og idéer, men med uklare forventninger til ændret adfærd og værdi, og med uklar prioritering. Selv hvor alle elementerne er til stede og på overfladen ser fornuftige ud, kan Impact mappet alligevel blotlægge idéer der er bundet op på antagelser, som er fyldt med risici, og at vi simpelthen brug for nogle discovery sprints til at undersøge nærmere hvad der er den rigtige vej frem, så vi ikke risikerer at spilde en masse penge.