Vores procesmodel forklaret til kunder og samarbejdspartnere

Vores agile proces

Softwareudvikling er ofte komplekst. Økonomi og tidsplaner skrider ofte i IT projekter, fordi der viser sig en masse behov undervejs, eller der bliver udvikles features der ikke er brug for. Enten fordi de er alt for svære at bruge, eller også eksisterende behovet slet ikke i virkeligheden. 
Der er også mange andre faktorer som gør det komplekst. Rammerne for projekterne ændres nemlig altid. Hver gang vi kaster os ud i skulle lave en ny digital løsning, så der er nye funktionalitetskrav, nye mennesker, en ny forretningssituation, ny teknologi, nye prioriteter og afhængigheder og i det hele taget andre omstændigheder. Derfor to IT-projekter aldrig være ens - og derfor er det pr. definition komplekst. Denne usikkerhed skal omfavnes for at komme sikkert i havn.

Når vi i Reload indgår i udviklingen af et digitalt produkt, vil vi være med til at sikre, at det bliver en succes. Vi har set og udviklet en lang række løsninger, og vi har et ret godt begreb om, hvad vi kan og ikke kan med teknologi til trods for, at den udvikler sig med lynets hast. 
 

Alice og Mads i aktion for et større agilt projekt for Region Sjælland.

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!

Men hvordan gør vi så?

Hvordan sikrer vi en succes, hvor forventninger mødes? Vi har ikke en “one size fits all proces”, men vi ved godt, hvad der skal til, og vi har gjort det mange gange. Når vi indgår i et sådant samarbejde, er vi ved jeres side, rådgiver og guider jer igennem forløbet. Vi vil hive jer ud af jeres comfort zone, men vil også tage ansvar for, at I får værdi for pengene, og at vores samarbejde bliver en succes.

10 gode grunde til at vælge en agil tilgang

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.

Målstyring som grundlæggende koncept

I vores perspektiv styrer vi produktudvikling. Det, at vi pakker det ind i en række mere eller mindre arbitrært afgrænsede projekter må ikke styre vores beslutninger om produktet, og at projektet i sig selv lykkes giver ingen garanti for succes samlet set - tværtimod kan det komme til at skabe et alt for kortsigtet fokus. 

Vi anerkender selvfølgelig, at vi har en projektøkonomi at rapportere op imod og styre indenfor, men fokus er på løsningens fulde levetid og total cost of ownership. Vi tilrettelægger derfor ikke vores proces rundt om det enkelte projekt og taler ikke om “projektfaser”. I stedet giver det mening for os at organisere arbejdet i to spor, et “Discoveryspor” og et “Deliveryspor”. Dette er en kontinuerlig proces, som der kan skrues op og ned for, alt efter behov og økonomi.

Dette har vi forklaret nærmere i “Reloads samarbejdsmodel”. Her beskriver vi helt overordnet hvordan og hvorfor vi arbejder som vi gør, og vi eksemplificerer vores grundlæggende tilgang og mindset. 

Resten af dette dokument beskriver lidt mere jordnært hvordan en typisk agil proces fungerer i praksis og i hverdagen hos os. Dvs. lige fra møderytmer og nogle af de mange styringsredskaber vi bruger for at komme sikkert frem til målet.

OBS

Hvis du ikke har læst om vores samarbejdsmodel, så start med at læse den nu.
Den er grundlaget for at forstå processen og nogle af metoderne som er beskrevet herunder.

Vores agile proces i praksis

Fokusområder inden vi for alvor går i gang

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.

Dual Track - discovery og delivery

Når først hele teamet har god forståelse for jer og jeres behov, går vi ind i et udviklingsforløb som i princippet er struktureret til at køre kontinuerligt, også selvom vi i praksis kommer til at skrue op og ned afhængigt af budget og behov. 

Som vi indledningsvist har beskrevet bliver et udviklingsforløb med os ikke et gammeldags projekt opdelt i faser, hvor alting specificeres og designes, før udviklingen sættes i gang. Vi arbejder ud fra det som kaldes Dual Track princippet. Her har vi to kontinuerlige sprint-spor kørende: Et Discoveryspor og et Deliveryspor. Deliverysporet er en traditionel SCRUM-proces med leverancer i færdig kode, mens Discoverysporet oftest er en mere flydende proces, idet vi kan være afhængige af udefrakommende kilder, fx interviewpersoner. Det bliver dog stadig struktureret som opgaver i en backlog.

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.
 

Discoveryspor

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é.  

The most expensive way to test your idea is to build production quality software Jeff Patton

Spørgsmål

Typiske aktiviteter (og altså måder at besvare spørgsmål på) kunne eksempelvis være: 

  • “Hvad er brugernes behov?”
    • Eksplorativ analyse via fokusgruppe interviews og feltundersøgelser, der kan afdække behov vi selv og vores brugere ikke ved, vi har. 
       
  • “Kan det teknisk lade sig gøre?”
    • Teknisk prototyping der kan verificere, om formodede teknologier og 3. parts moduler kan bruges i et specifikt scenarie. 
       
  • “Kan vi skabe den ønskede adfærd hos brugeren?”
    • Iterative designprocesser, baseret på visuelle prototyper, hurtige brugertests og feedback.

Deliveryspor

Deliverysporet lægger sig typisk op af en traditionel SCRUM proces. Det betyder, at vi har en backlog (opgavelisten) som er en løst struktureret opgaveliste af “user stories” med de specifikationer, vi former og validerer i Discoverysporet. Det er altså at betragte som en dynamisk kravspecifikation, selvom det er også er vigtigt at forstå, at det ikke er meningen (eller opnåeligt) at alt i backloggen skal laves. Derimod skal den løbende prioriteres, forfines og justeres efterhånden som tiden skrider frem. Vi vælger løbende en håndfuld opgaver, og implementerer dem i et sprint, hvorefter de færdige funktionaliteter kan demonstreres (og er produktionsklar).

Scrum processen kort forklaret

Et udviklingssprint varer typisk 2 uger og inkluderer forberedelse til kommende sprint samt til leveranceafprøvning. I Reload tror vi fast på at det er essentielt, at vi bruger tid sammen som samlet team og har mulighed for at træffe hurtige beslutninger sammen. Reload stiller lokaler til rådighed, så vi kan sidde fysisk sammen minimum én gang om ugen udover de faste møder.
 

Herover: Eksempel på et sprintforløb, hvor der arbejdes mod et MVP - Minimal Viable Product

Møde: Sprintplanning (Hver sprint)
Vi gennemgår de estimerede udviklingsopgaver og prioriterer, hvilke opgaver der har højest værdi/prioritet, og dermed skal i scopet for udviklingssprintet.

Forløb: Udvikling og test (2 uger)
Vi arbejder på én opgave ad gangen per udvikler og færdiggør en ny version af løsningen, der kan afprøves ved sprintets afslutning.

Møde: Demo, retrospektiv, og rapportering (Hver sprint)
Vi demonstrerer sprintleverancen samt vender processen og evt. forbedringer hertil. Vi leverer også en sprintrapport, der opsummerer status på fremdrift, økonomi, scope, risici, og vigtige beslutninger.

Møde: Daily scrum / standup (Hver dag i sprint)
En kort, stående, gennemgang af dagens opgaver, og status på hvad der blev lavet siden i går. Bruges til at vidensdele og identificere roadblocks. Alle er velkomne på mødet. 

Møde: Backlog grooming (Hver sprint)
Her forbereder vi opgaver til næste sprint. Dvs. vi snakker dem igennem, finder ud af hvilke opgaver der kræver yderligere afklaring, og estimerer de opgaver vi forventer skal med i næste sprint. I veletablerede teams kan dette også ske løbende. 

Forløb: Afprøvning og feedback (1 uge)
Vi forventer, at I umiddelbart efter et sprint afprøver leverancen, bliver fortrolige med den nye version af jeres løsning, og giver feedback vi kan tænke ind i de kommende leverancer.
 

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. 
 

Byg kagen i vertikale stykker

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. 

Rapportering

Eksempel på Reloads sprintrapport

Efter hvert sprint rapporterer vi om status og fremdrift. Her kigger vi på, hvordan estimater udvikler sig efterhånden, som vi udspecificerer, og sikrer, at vi holder os indenfor budget. Sprintrapporterne er brutalt ærlige, også når det er svært. I så fald vil vi hellere finde en løsning på en sådan situation sammen end at forsøge at negligere det. Overskrifterne i en typisk sprintrapport er:

  • Opsummeret status beskrevet med ord
  • Punkter som er værd at bemærke (typisk showstoppers og centrale beslutninger)
  • Vurdering af risici med konkrete anbefalinger
  • Resumé af sprintets resultat
  • Status på fremdrift (på tværs af spor)
  • Overblik over prioriterede indsatser / epics
  • Status på budget forbrug 
  • Oversigt over sprints og allokering fremadrettet
     

Kundens roller og ansvar

Vi forventer, at I som kunde er en aktiv del af hele processen. Idet vi ikke har endeligt specificerede krav fra start, og forventer at de ændrer sig løbende, så er det nødvendigt, at vi specificerer kravene og tænker løsningerne sammen i løbet af processen.

I hverdagen forventer vi at arbejde tæt sammen. Vi forventer, at jeres projektteam kan allokere minimum 1 dag per uge og i perioder endnu mere, op til fuld tid. Vi forventer ligeledes, at I kan stille med en Produktejer, som har mandat til at tage alle beslutninger inden for projektrammerne. 

Tak fordi du har læst så langt

Hvis du synes sådan noget her er interessant, så skriv dig op på vores nyhedsbrev. Her skriver vi løbende om relaterede emner, deler viden og konkrete erfaringer.

Og så vil du også blive inviteret til vores gå-hjem-møder, hvor vi og vores kunder deler rundhåndet ud af vores erfaringer.

Og ellers skal du være meget velkommen til bare at kontakte os med det samme :)