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.
.
"Det er en helt anden proces, hvor man er meget mere involveret i det". Hør vores kunde LokalBolig fortælle om, hvordan de har oplevet vores tilgang.
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.
Vores kunder i LokalBolig fortæller om, hvordan vi i Reload holder kunden informeret om alt der foregår på projektet gennem rapportering.
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 arbejder typisk i sprints, som har to typer af opgaver; discovery og delivery. I nogen perioder er der langt mere discovery arbejde - altså arbejde af afklarende karakter. I andre perioder der er mere delivery arbejde - altså opgaver af implementerende karakter. Oftest er det en blanding - og teamet er det samme, så det er grundlæggende en fordeling af opgaver og hvilket mindset vil tilgå vores arbejde med.
Man skal dog gøre sig klart, at formålet og mindsettet vi arbejder ud fra, er vidt forskelligt for de to typer af opgaver:
Med Discovery opgaver 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.
Input: Spørgsmål.
Output: Svar (på spørgsmål).
Outcome: Større sikkerhed for at vi vælger den rigtige vej frem.
Arbejdet med Delivery opgaver er 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.
Input: Validerede udviklingsideer
Output: Fungerende 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, markedet, brugere eller i teknologien.
En forklaring er nok på sin plads. Vi arbejder med en variant af det som er kendt som Dual Track princippet. Her har vi et kontinuerligt spor kørende, men med to typer af opgaver: Discovery- og Delivery-opgaver.
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 mere discovery arbejde til at undersøge nærmere hvad der er den rigtige vej frem, så vi ikke risikerer at spilde en masse penge.
Ved at gøre antagelserne eksplicitte kan vi altså bedre vurdere, om vi er nødt til at arbejde mere for at minimere risikoen for at arbejde ovenpå gale antagelser. Dette vil jo medføre kostbare fejl i hvordan vi investerer i udviklingen af løsningen. Ofte er det dog først når løsningerne er ude over rampen, at vi bliver helt klare over om vores antagelser så faktisk holdte. Derfor advokerer vi næsten altid, at enhver nye idé skæres helt ind til benet til første release, men til gengæld, at vi har løbende budget til løbende at trimme og udvikle løsningen ud fra reel feedback.
Herudover giver Impact mappet os også en struktur til løbende at holde øje med om de skibe vi sætter i søen også gør deres job. Medmindre vi har med en e-shop eller lign. at gøre, kan det måske være svært at bevise direkte sammenhæng mellem de digitale løsninger vi udvikler og den værdi vi skaber. Men når vi eksplicit har formuleret, hvad det er for en ændret adfærd vi mener vil lede til mere værdi, kan vi i det mindste holde øje med om den ændrede adfærd så faktisk sker.
Se en kort video (3:33 min), hvor Rasmus og Alice forklarer, hvordan Impact Mapping grundlæggende fungerer, og hvordan vi bruger det i Reload.
I stedet for at bundle en række mere eller mindre urelaterede features i et mere eller mindre tilfældigt “projektbudget”, kan vi i stedet begynde at arbejde mere intelligent med “målbaserede budgetter”.
Den værdi du som kunde antageligt kan indfri ved at vi opnår et givet mål, bør sætte budgetrammen for hvor meget vi vil arbejde for det mål.
Det gælder alt det arbejde som skal gøres for at nå i mål. Dvs. både Discovery items (spørgsmål) og Delivery items (User stories), som relaterer sig til et givet mål, bør derfor estimeres, og holdes op imod den værdi, som forretningsmålet de relaterer til repræsenterer, så cost / benefit betragtningen hele tiden er i fokus.
Hvordan bruger vi bedst det budget vi har at bruge af for at løse en givent forretningsmål? Og hvordan skal vi balancere discovery/delivery arbejdet? Er det billigere at prøve at bygge noget, evt. noget der håndholdes manuelt, og se hvad der sker, frem for at forsøge at analysere os frem til et svar?
Eller skal vi trykprøve vores antagelser lidt mere først, måske med en prototype? Måske ved at blive klogere på det reelle indtjeningspotentiale eller ved at blive klogere på brugernes oplevelse? Det giver mening hvis det er en betydelig investering at bygge - eller måske fordi der er risiko for at ødelægge en allerede god oplevelse.
Det er svært at lave hårde regnestykker altid, men vi kan sikre os, at vi aktivt tager stilling til de input, vi har at arbejde med.
I den agile vej frem advokerer vi ofte for at prøve os frem, ud fra en anerkendelse af, at vi sjældent kan forudsige ret meget alligevel. Til gengæld er det absolut afgørende at vi gemmer den energi (budget), som vi ellers ville have brugt på at validere antagelser upfront, til at opsamle og udnytte feedback, til at tilrette de initielle versioner af nye features/tiltag, så de performer i virkeligheden!
Overvejelser vi må gøre os:
Ovenstående er spørgsmål der skal hjælpe os med at afdække hvilken tilgang vi tager. Skal vi forsøge at afklare vores antagelser inden vi bygger - eller skal vi bygge og få svaret bagefter?
For at opsummere, så handler Reloads samarbejdsmodel om at bevare fleksibilitet, så der er plads til at levere digitale løsninger, der tilfører værdi i virkeligheden og for de mennesker, der investerer i dem og for de mennesker der bruger dem.
Modellen gør det muligt at komme hurtigt ud af starthullerne, og levere værdi løbende på trods af, at markedet eller omverden ændrer sig.
Løsninger lavet sammen med Reload efter denne model er levende og har hele tiden øje på helhedsbilledet. Det betyder også, at vi tør gå helt andre veje, og gøre op med klassiske projektmodeller, projektstyring og de sædvanlige (smertefulde) analyse-, design- og udviklingsforløb.
Virkeligheden kan meget sjældent skæres pænt i kanterne og hældes i isolerede, afgrænsede projekter. Realiteten er meget mere flydende og organisk. Små og store behov opstår, larmer pludselig, eller bliver pludselig irrelevante, før vi når at komme ordentligt i gang.
Derfor tager vi altid udgangspunkt i hvordan der kan skabes værdi bedst muligt i den givne situation. Og vi lykkes ved at vi som team sikrer et fælles sprog, så vi altid er fuldstændig klar over, hvorfor vi er i gang med at udvikle hvad, og i hvilken rækkefølge det skal ske. Vores model fordrer en konstant læringscyklus, så der hele tiden er øje på forretningsmålene. Det handler i sidste ende om at organisere samarbejdet på en måde, så der hele tiden kan leveres produkter og services, som virker i virkeligheden.
Skal vi komme igang? ?