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 Produktejeren 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!

1. Det rigtige produkt
I IT projekter ser vi ofte, at mange features aldrig eller sjældent bruges. Med agil udvikling er der fokus på at bygge det rigtige produkt frem for det “aftalte produkt”.

2. Udnyttelse af reel feedback
Fordi vi leverer fungerende software tidligt, så kan vi nå at få feedback fra projektorganisation, ressourcepersoner, pilot/beta-brugere eller rigtige brugere, og prioritere videreudvikling herudfra.  

3. Time-to-Market
80% af alle market leaders har været først på markedet med deres produkt. Med agil udvikling, leveres der løbende - så snart, vi mener at have noget, der er bedre end, hvad vi har i dag. Fungerende leverancer giver desuden muligheden for at teste integreret hele vejen igennem udviklingsprocessen og arbejde med produktions(nær) data tidligt.

4. Kvalitet 
Kvalitet er svært at beskrive up-front . Men det er vigtigt at forstå, at hvis vi binder os til en “fixed scope + fixed price” leverance, er det typisk kun kvaliteten, der kan skrues på - og sjældent til det bedre.  

5. Fleksibilitet 
Ændringer i (eller ny viden om) markedet / konkurrenter / egen organisation / teknologisk udvikling kan trigge naturlige scope-ændringer, som den agile proces giver mulighed for rent faktisk at realisere.

6. Gennemsigtighed 
Meget involvering og tæt samarbejde med kunden skaber gennemsigtighed i processen og gennemtvinger en stærk forventningsafstemning, hvor evt. uoverensstemmelser tages med det samme, frem for at samle sig til bunke.

7. Bedre Risk Management
Før vi faktisk udvikler noget, når vi at tale funktionalitet og diverse edge-usecases meget bedre igennem end, hvad en typisk kravspecifikation dækker. Det skaber klarhed og bevidsthed om hvad og hvordan tiden bruges, og det betyder at vi løbende kan justere fokus, ift. ny viden og/eller ændrede forudsætninger i projektet. Man kan sige, at der er større risiko for ikke at imødekomme organisationens initielle forventninger, hvilket kræver ekstra fokus på løbende forventningsafstemning, men der er en mindre risiko for at udvikle et produkt der ikke har reel forretningsværdi. 

8. Budget kontrol
Fordi vi har fleksibilitet i scope og styrer mod et fast budget, vil der ikke komme uforudsete ekstraudgifter i form af et change budget, der løber løbsk.

9. Indbygget medejerskab 
Den aktive involvering af organisation, redaktion, ressourcepersoner og andre interessenter, betyder at de gennem hele processen kan komme med input og prøve dele af det færdige produkt af. Det fører automatisk til et medejerskab. De, der skal bruge systemet, føler ikke de får trukket noget ned over hovedet, og produktet fungerer, når det lanceres.  

10. Vi er i samme båd
Fordi aftalen er skruet sådan sammen, at vores kunder køber tid frem for funktionalitet, er vi sammen om at udnytte den tid, vi har til rådighed bedst muligt. I modsætning til en fixed scope kontrakt med et indbygget modsætningsforhold ift. hvad der skal læses ud af en given kravspecifikation.

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 jeres virke, og hvordan I 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 skitsere overordnede koncepttanker. 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 “discovery opgaver”.

Discovery: Byg de rigtige ting

Med discovery-opgaver 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 sender de gode videre som velspecificerede user stories med validerede bagvedliggende antagelser.

Delivery: Byg tingene rigtigt

Med delivery-opgaver fokuseres på kvalitet, performance, scalability og lign. User stories fungerer som udviklings-specifikationer, og leverancen er produktionsklare features klar til at blive deployet (udrullet) og taget i brug. 

Ét team

At der er to typer af opgaver er dog ikke at forveksle med to separate teams. Det er ét team, alle dem der arbejder sammen om jeres nye løsning, og de arbejder sammen i én proces, den har bare to typer af opgaver. Det er vigtigt, at alle så vidt muligt inddrages i, hvad der arbejdes på på tværs af opgaver. Det er vores erfaring, at det er en nøglefaktor i forhold til at skabe den gensidige team-ansvarsfølelse der er et af elementerne, hvis man vil opnå et high performance team.

Design foregår hele tiden

Designarbejdet i traditionel forstand (som i “vi laver noget i form og farver”) har en vigtig rolle at spille i begge typer af opgaver. 

I discovery-opgaver 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 delivery-opgaver 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.

Inden et sprint 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 eller 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 afklarende arbejde er, at man aldrig kan blive færdig. Du kan altid sikre sig lidt bedre, undersøge lidt mere, prøve lidt flere visuelle muligheder osv. af inden du føler dig klar til udvikling. Så ligesom du skal være knivskarp på ikke at agere efter antagelser, der burde valideres bedre, skal du den anden vej rundt være lige så skarp på, at den tid du bruger her, går fra tid du kunne bruge til udvikling og læring deraf. Du skal altså kun undersøge forhold, I ikke ved nok om, og hvor det er tiden værd.

Udgangspunktet er igen, at I diskuterer behov og relevant viden ift. den givne feature, og 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.

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å skal du nedbryde i fulde funktioner, små prioritérbare bidder, der giver værdi i sig selv. Det, du 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. På den måde kan de komme ud og generere faktisk værdi, mens I udvikler på de næste.

Værdi er ikke nødvendigvis produktion. Oftest skal der en del sprints til, før man er nået til et produkt der kan publiceres. Men det skal ud og prøves af, om ikke andet hos interessenter i organisationen. Således skaber du feedback og dermed viden. Og det er værdifuldt!

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. 

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 forme og 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. 

Lille og lækker

Hellere bygge en funktionelt lille, men virkelig velfungerende løsning og siden bygge på derfra. Så får brugerne en god oplevelse, og du får gang i et rigtigt sundt feedback-loop, som kan hjælpe dig med at prioritere det videre arbejde. 

Grundtanken er, at vi undgår at bygge én stor lagdelt kage, der først er spændende, når den står færdig med glasur og det hele. I stedet bygger vi en lille, men perfekt lækker kage. En fuldendt cupcake. Er dine brugere begejstrede for den, jamen så kan du bygge den videre til en stor kage. Måske kan de ende med at få en bryllupskage. Men går du efter bryllupskagen fra starten af, kan det være, at den er så dyr eller kompleks, at du aldrig bliver færdig med den. Eller også ser den flot ud, men falder ikke i nogens smag.

Vi kalder det nogle gange for “cupcake modellen”, tyvstjålet fra denne blogpost.