Værdien skabes af ændret adfærd

Ingen digitale løsninger skaber dog værdi i sig selv, det er den menneskelige adfærd, som løsningen understøtter, der skaber værdien. Hvis vi vil skabe mere værdi, skal vi altså ændre adfærd hos nogle mennesker. Derfor fylder fokus på menneskelig adfærd og interaktion meget i vores proces. Før vi sætter udvikling af en feature i gang, skal vi først være helt skarpe på præcis af hvem og hvordan, vi forventer den feature skal bruges, samt hvordan det i sidste ende skaber værdi - og er investeringen dét værd for os. Bliver vi i tvivl om, hvorvidt der kunne være billigere eller bedre løsninger, eller om de antagelser vi baserer vores cost / benefit betragtninger på holder, så tager vi os tid til at blive klogere, før vi træffer en beslutning. 

Vi bliver klogere undervejs - sammen

Typisk bliver vi så meget klogere undervejs, at vi ender med løsninger, der er markant anderledes end først forventet. Kun hvis hele organisationen er med til at skabe og trimme løsningen, kan vi skabe det værktøj som understøtter jeres digitale virke på bedst mulig vis. Det kræver, at I kan stille med en Produkt ejer, som kan arbejde uafhængigt og på tværs af siloer, som har fuldt beslutningsmandat inden for de aftalte projektrammer, og har den nødvendige tid til at være en aktiv part i processen. Hvis Produkt ejeren ikke tidligere har været med til at udvikle større digitale løsninger i en agil proces, anbefaler vi træning/undervisning forud for samarbejdet.

Vi håndterer risiko ved ikke at aftale alt på forhånd

Vi tror altså ikke på, at løsninger, som er færdigspecificeret og aftalt på forhånd, ender med det bedste resultat. Derfor arbejder vi ikke med aftaler som låser os fast på konkrete funktionalitetsleverancer. Det er angstprovokerende at gå ind i et forløb uden at vide, hvad man kommer ud med på den anden ende. Det forstår vi. Det kan virke som en stor risiko, men risikoen for at vi simpelthen ikke fokuserer rigtigt, hvis vi skulle fastlåse løsningen på forhånd, er i vores optik langt større. Dels fordi løsningens præmisser typisk er forældede, før nogen får glæde af den, og dels fordi, at fastlåser vi både økonomi og funktionalitet, så er den eneste parameter, vi har at skrue på, når noget uforudset viser sig, kvaliteten!

Før vi kan træde til som partnere og rådgivere i udviklingen af en ny løsning, skal vi dog have en dybere forståelse for vores kunders virke, og hvordan de er organiseret. Vi skal forstå, hvilken viden der allerede er, som vi kan bygge videre på, og hvilke forhold, vi skal lære mere om.

Vi skal have kortlagt de behov og forventninger der er i spil til jeres løsning, og herudfra evt. skitsere overordnede  koncept tanker. Vi kan have brug for at tegne nogle streger, der sikrer sammenhængen i en god løsning.

Nedenfor er skitseret hvilke fokusområder, vi skal igennem. Hvordan vi præcis tilrettelægger workshops, arbejdsmøder, analyse og designarbejde afhænger meget af temperament, samt hvor gennemarbejdet og opdateret et vidensgrundlag, I allerede har. Udgangspunktet er, at I præsenterer eksisterende viden indenfor området for os, hvorefter vi sammen løbende vurderer behovet for løbende afklaring.

Team og proces
Grundig gennemgang af proces, roller og forventninger til os selv og hinanden samt et socialt arrangement, hvor vi kan lære hinanden lidt bedre at kende.

Hvem er I? 
Gennemgang af jeres organisation, vision, og de strategisk tanker, der ligger til grund for en ny løsning. 

Strategi og målgrupper
Gennemgang af kendte målgrupper og centrale brugerscenarier for jeres nye løsning

Roadmapping
Gennemgang af (high level) feature ønsker og heraf en Impact Mapping som tager højde for betragtninger om strategi og brugeradfærd, samt illustrere prioriteringen af behov, ønsker og idéer.

Tekniske afhængigheder
Analyse af det tekniske setup herunder særligt fokus på centrale integrationer og særligt komplekse features.

Koncept og principper
Som udgangspunkt for design af en ny løsning udvikles typisk et koncept der beskriver de overordnede principper for arkitektur, applikationsdesign, informationsarkitektur, navigation, interaktion og look & feel.

Konceptet sikrer, at udvikling og specifikation af løsningens forskellige indholdsområder og funktionaliteter tager afsæt i en overordnet ambition og prioritering, som hele tiden tager udgangspunkt  den bærende idé og principper og derfor giver en meningsfuld og konsistent brugeroplevelse.
 
Alle de ovenstående ting er en blød start på det vi kalder vores “discovery spor”. Introduktion til det kan du læse om i vores samarbejdsmodel.

To spor

I Discoverysporet fokuserer vi på, hvordan vi kan bygge “det rigtige”. Det kan være en eksplorativ og kreativ proces hvor vi prøver ideer af, interviewer folk i målgruppen eller kigger på eksisterende data. Vi skaber viden. Backloggen (opgavelisten) består af research spørgsmål, leverancen er svar og det er oftest en iterativ proces hvor vi løbende retter vores hypoteser til. Vi ender med nogle svar som i sidste ende sikrer, at vi fravælger de mindre gode idéer og sende de gode videre som velspecificerede userstories med validerede bagvedliggende antagelser.

Ét team

I Deliverysporet fokuseres på kvalitet, performance, scalability og lign. Userstories fungerer som udviklings-specifikationer, og leverancen er produktionsklare features klar til at blive deployet og taget i brug. 

De to separate spor er dog ikke at forveksle med to separate teams. Vi er ét team, alle os der arbejder sammen om jeres nye løsning, og vi arbejder med én proces, den har bare to spor. Det er vigtigt for os at alle inddrages så vidt muligt i, hvad der arbejdes på i begge spor. Det er vores erfaring, at det er en nøglefaktor i forhold til at skabe den gensidige team-ansvarsfølelse der blandt andet skal til for at opnå et high performance team.

Design foregår hele tiden

Designarbejdet i traditionel forstand hugges til over på midten og har derfor en vigtig rolle at spille i begge spor. 

I Discoverysporet designer vi for at lære, og for at skabe en fælles forståelse for løsningsrummet. Vi skaber muligheder, prøver ting af, og finder ud af hvad der virker. 

I Deliverysporet designer vi for kunne levere et færdigt produkt. Det er her designarbejdet former og indarbejdes i  den tekniske løsning og der er fokus på systematik, konsistens og genbrugelighed af komponenter i brugergrænsefladen.
 

Discoverysporet består typisk af 14-dages-sprints. Inden sprintet starter, så har vi afholdt et grooming møde, hvor vi tager fat i de vigtigste behov og features, vi kan identificere i vores Impact Map. Vi vurderer her risikoen for, at vi mangler viden, og vores antagelser derfor ikke holder. Dvs. hvis vi er stensikre på vores business case og vores kendskab til målgruppens brugssituation, skal vi selvfølgelig ikke bruge mere krudt på at analysere og iterere over design elle koncept. Men er der områder, hvor vi er mindre sikre, giver det mening at grave lidt mere i det.  

Det er selvfølgelig virkelig svært for os på dette tidspunkt at vurdere, hvor meget tid vi skal bruge på analyse og specificering af krav og ønsker for at kunne skære scopet rigtigt. 

Det svære ved den slags arbejde er, at man aldrig kan blive færdig. Man kan altid sikre sig lidt bedre, undersøge lidt mere, prøve lidt flere visuelle muligheder osv. af inden vi føler os klar til udvikling. Så ligesom vi skal være knivskarpe på ikke at agere efter antagelser der burde valideres bedre, skal vi den anden vej rundt være lige så skarpe på, at den tid vi bruger her, går fra tid vi kunne bruge til udvikling. Vi skal altså kun undersøge forhold, vi ikke ved nok om, og hvor det er tiden værd.
 

Udgangspunktet er igen, at I præsenterer behov og relevant viden for den givne feature, her giver det typisk mening at trække på forskellige ressourcepersoner som ved noget om det område. Ud fra en risikobetragtning beslutter vi, om eksisterende viden skal følges op af analyse (hvor stor risiko er der for, at vores viden er forkert eller forældet? Og hvor stort et problem har vi egentlig, hvis det viser sig at være sagen?).  

Selve analysen i sprintet kan altså bestå af meget forskellige aktiviteter. Målet er at besvare de spørgsmål, vi kan have ift. om vores idé og forventet cost/benefit holder. Typisk er det en balancegang mellem analyse processer og kreative processer at finde frem til den rigtige løsning. 

I Discoverysporet starter vi sprintet med et planning-møde, hvor vi estimerer “hvor lang tid det tager at besvare et givent spørgsmål” og udvælger de mest relevante opgaver at arbejde på. Resultatet af det arbejde vi laver her er svar. Svar som ender med at skabe viden og ultimativt bliver til en backlog af udviklingsopgaver, som med meget høj sandsynlighed vil blive brugt og skabe faktisk værdi. I denne optik måles der altså fremdrift, når vi bliver klogere, hvilket betyder, at det også er fremdrift, når vi bliver så kloge, at vi tør fravælge en feature, der umiddelbart virkede som en god idé.  

Vi skaber løbende læring gennem korte feedback loops

Inkrementel udvikling er trinvis udvikling. Et trin ad gangen - en feature ad gangen. Så frem for at nedbryde og udvikle scope ud fra de tekniske lag (først datagrundlag / funktionalitetslag / præsentationslag), så nedbryder vi hele tiden i fulde funktioner, små prioritérbare bidder, der giver værdi i sig selv. Det, vi tager ind i sprintet bør altså være så afgrænsede features, at de kan færdiggøres og være klar til produktion ved sprintets ende. Således at de kan komme ud og generere faktisk værdi, mens vi udvikler på de næste. 
 

Færdiggørelse er jo så et elastisk begreb i denne sammenhæng, og det er her, at det iterative og udnyttelse af feedback loops kommer ind i billedet. Vi anbefaler altid, at første version af en ny feature er så skrabet som overhovedet muligt, men aldrig mere skrabet, end at vi (hvis den er færdig) vil kunne lukke den ud i produktion, som den er. 

Ofte er dette også måden, vi styrer budgettet på. Typisk er det de færreste behov og features, vi helt kan undvære at komme omkring, men ofte kan vi vælge at gøre mere eller mindre ud af en given feature. Både fordi vi gerne vil have feedback og lære, før vi udvikler den dyre løsning, og fordi vi vil være sikre på, at vi kommer hele vejen rundt, er fokus i udviklingen af en ny løsning altså altid på, hvor simpelt vi kan skære den. Når vi så først er hele vejen rundt, kan vi arbejde mere iterativt og backloggen kommer i højere grad til at bestå af forbedringer til eksisterende features frem for nye features. 

Ved sprintets afslutning præsenterer vi de færdige løsninger. Vi får jeres umiddelbare feedback, og I får adgang til at prøve jeres nye løsning. Så vurderer vi endeligt, om den er klar til produktion, eller om den skal have en iteration mere først.